File_loadfunction and address trap error

[Franck P.]

HI
First, please excuse my English. I'm French.

I'm working with Diablo16 display mainly in Visi. The issue I discribe here is not specific to a display but to all Diablo16 (I guess).

I'm preparing myself to run some of the code functions from SD card as I will run out of code space while still have lot of ram spaces. I will use file_loadfunction as loaded function can be use like any "normal" function.
the goal then is to load the function at the beginning of Main, and never "free" it as it will be used all the time.

I have read a lot of info from the forum and was not able to found clear tips to guide me to solve my issue:

I decide to test this "function export thing" with an I2C general function that have 5 parameters (address / sub-address / nbr of byte to write or read / pointer to buffer / flags)
When Inside the code, this function works perfectly and forever.
FYI this function is not recursive

I then exported this function into a 4FN file, load it at the beginning of main, AND BEFORE to initialize any timer (this is known to cause problem)
After being loaded, the function is supposed to behave as "normal"

However, the display crash with an address trap error, erratically between 1 second and 1 minute. during this delay the function is called many times (at least 3 times per seconds) and behave as expected.

What should I take care using file_loadfunction as the loaded function itself is good and work.
What can create this erratic fault?

is my understanding with the timer is corrects? should I stop the timers before each call of the function or the timer issue is known to be only with file_loadfunction?

I don't get the point yet. I would need some help here.

Many thanks

Franck.

[sherwin4D]

Hello Franck,

Can you post snippet of your code here?

From the Diablo16 Internal Functions Reference Manual section 2.14.25 file_LoadFunction(fname.4XE) (page 324), it says that "any pointer references passed to the child function may not include references to the parents DATA statements or any static string references. Any string or array information must be in the parents global or local memory space. The reason for this is that DATA statements and static strings are contained in the parents CODE segment, and cannot be accessed by the child process."

Does the function conform to the conditions mentioned above? There's a possibility that one of your parameters is causing this.

Furthermore, have you tried file_Run() and file_Exec() functions?

Thanks and best regards,
Sherwin

[Franck P.]

Hi
The function parameters are all "direct" values except 1 that is the base address of an array. If the issue would be located here then the fucntion would fail immediately at its first run, while it can run several times, erratically, during 1 to 60 seconds.

I have continued my research on the forum and found a useful information. Loaded function run in a separate code space, and if an event is raised while the function is executed, the display crash as it can't handle the situation.
This it is hardly understandable as event process, that we should consider as an interrupt, should save the display context before to execute the event handler, then restore the context to resume loaed function operation.

Yesterday I did a try by using sys_eventspostpone() before to call the function and sys-eventsresume() after its return and the display is not crashing anymore.

HOWEVER, this introduce other issues inside my app so this workaround is not suitable. This is due that Sys_Eventspostpone only keeps in memory 16 events and as the loaded function could be quite long (it is i2c routines for me), the systems is missing some events.

I would really suggest 4D to increase this 16 limit to 64 even more if possible.

Not being able to handle events while using loaded function is a big lack to the solution for me. It is really unfortunate for my project as the display is supposed to control a lot of external resources using pin events, timers and so on, to synchronize everything together. (the project is 3 x com port + 1 x i2c port + 1 x analog input + 3 pins in i/o for synchro. I have only 3 pins left!!).

The only advise I could give here for potential users is to load only "quickly executed" function to prevent the sys_eventspostpone (that SHOULD be used before the call to the function) to miss events.
This exclude relative long process like I did in my example, but long "display drawing" function should be avoided too.

This point leads me to ask another question. I found nowhere how to calculate the execution time of diablo16 functions, specifically when drawing thing to the screen.
When delays are critical, those information’s are crucial for the developers

best regards
Franck

[sherwin4D]

Hello Franck,

Thank you for the very detailed feedback.

This point leads me to ask another question. I found nowhere how to calculate the execution time of diablo16 functions, specifically when drawing thing to the screen.

You can calculate the execution time with this code:

var tst_start;
var tst_stop;

tst_start := sys_T();
// ACTION TO MEASURE //
// put function here
tst_stop := sys_T();

putstrXY(0,0,"Time elapsed: ");
putnumXY(30,0, DEC, tst_stop-tst_start);

BR,
Sherwin