RamFile and SDCard

[ATU]

In different parts of my program, I have several places where I want to log data to one log file. It could happen at random times. I use the Ramfile to store that file, because I am assuming that it is much faster than logging to the SD card. Since the Ramfile is not retentive, I will have another program that checks periodically in this file and will copy a record at a time into another file on the SD Card, then delete that record.
1. Is that the best way to do that? Should I just log to the SD card and don't worry. I don't want to hold up my sequence waiting for the FileLog function.
2. Is it interlocked? What happens if I try to access the log file when Filelog is accessing the file or vice versa? Does it just take longer for the function to complete? Does it error out?

[BobO]

Like every device instruction, the device is locked while working. While locked nothing else can access it.

Just log to the SDCard unless it isn?t fast enough.

[ATU]

It only logs if something fails, but when it fails it could write over 100 dwords of data in multiple log instructions and I want the operation to get back to the main sequence as fast as possible. Also, this  could occur, although somewhat unlikely in multiple programs simultaneously which might add to the cycle time and affect other operations. I have plenty of time outside those programs to get it to the SD card. I could do this with arrays, but the log instruction is so nice and simple.  I think when I tested this out last year,  there was a big difference speed between the Ramdrive and the SD card, 2-3x,  I just can't find it in my notes.

[BobO]

If memory serves, the SDCard  write time ~2 ms power 512 byte block. I would put the exception log operation in its own program block and spawn it on failure. Better yet, have it run continually, processing the log entries as they show up. Store new log content in a ring buffer, which the logger removes as it commits to file.

[ATU]

I could use an interlock with  a subroutine call to push the data into the buffer. That nice parameter table on the call instruction would do well for that.  Then as you say have a program running all the time waiting for data in the buffer to do the writing. Have 2 pointers, when they are unequal it writes to the SD card and when equal the buffer is empty.  Thanks!

[BobO]

If using a subroutine and a ring buffer,  interlocking isn't necessary.

[ATU]

Is that because subroutine calls suspend multi-tasking?

[BobO]

Yes and no. First, there really isn't any true multi-threaded execution, only multi-scan. Second, subroutines run fully within the call. Third, even if it were multi-threaded, ring buffers work regardless as long as you bump the head pointer after you have fully filled the new buffer content...the buffer data consumer doesn't 'see' the new buffer content until it is safe to access.

[ATU]

So the subroutine can't be called by another program while I am executing the first call? Since its not true multi-tasking, you don't create another instance of the subroutine? It has to complete? That is my worry.

[BobO]

So the subroutine can't be called by another program while I am executing the first call? Since its not true multi-tasking, you don't create another instance of the subroutine? It has to complete? That is my worry.

Subroutines fully complete before returning from the call. They cannot be multi-scan.