- Tue Dec 22, 2020 8:20 pm
#47230
As the title suggest a post on sd card logging for speeduino.
I have been working on the sd-card logging functionality for some time now. But I hit a snag that is not easily worked around I think. It is not impossible but a lot more work to fix! So I thought let me share this with everyone. Use this post as a reference to know what you can expect. I have been trying this on an Ebay STM32 board. But the main problem/snag remains the same for all boards.
There are some good things also . The following things are working in tests I have done..
1. I suspect the interrupts of speeduino create problems with the SDIO interface. Sdlogging works for a while but it flunks out after some random time. This can be solved and is more an issue with the STM32 and not in general.
2. It blows the rest of the real-timeliness of the board till the point is starts missing ignition pulses. (This is most likely a general sdcard/FatFs problem)
The second point is likely a sdcard interface limitations in combination with the FatFs library write function being blocking. It must be asynchronous or DMA based to work.
95% of the time a write of 512 bytes (secotr size) to the sdcard FAT file system takes 1.5 milliseconds. That is long but hopefully ok, I do not expect big problems with that. But when hitting some physical bound of the sdcard (In my case every ~265kb) the sdcard reports it is busy and the write function waits until sdcard is ready. This can take >100ms. During this time the main loop of speeduino would be blocked creating all sorts of problems.
The solution in my opinion is an asynchronous (or DMA) version of the FatFs file system library. Where a write to the file system that waits on the sdcard returns with a “waiting on sdcard” flag. So that the main loop can continue and writing the same info can be tried a next loop. This solution also needs a asynchronous Sdcard I/O layer that is not there yet.
Because sdcard logging function is not strictly needed with data logging using phones or other devices i stop working on it for the moment. Or until i have a very bright light bulb to fix it . (Or someone here on the forum knows a good solution for this of-course ).
I have been working on the sd-card logging functionality for some time now. But I hit a snag that is not easily worked around I think. It is not impossible but a lot more work to fix! So I thought let me share this with everyone. Use this post as a reference to know what you can expect. I have been trying this on an Ebay STM32 board. But the main problem/snag remains the same for all boards.
There are some good things also . The following things are working in tests I have done..
- Setting the Realt-time clock with Tuner studio to current computer time.
- Using the Realt-time clock for timestamp of the file name
- Using the real-time clock for file creation time and date.
- Datalogging in CSV format of most currentstatus struct variables. (Partly working, with crippling limitations)
- FatFs from elm-chan.org/fsw/ff slightly adapted by ST for use with the STM32 MCU series
- STM32duino STM32SD (that dependents on the library mention above)
- STM32duino RTC (Used for time stamping and file creating time/date)
1. I suspect the interrupts of speeduino create problems with the SDIO interface. Sdlogging works for a while but it flunks out after some random time. This can be solved and is more an issue with the STM32 and not in general.
2. It blows the rest of the real-timeliness of the board till the point is starts missing ignition pulses. (This is most likely a general sdcard/FatFs problem)
The second point is likely a sdcard interface limitations in combination with the FatFs library write function being blocking. It must be asynchronous or DMA based to work.
95% of the time a write of 512 bytes (secotr size) to the sdcard FAT file system takes 1.5 milliseconds. That is long but hopefully ok, I do not expect big problems with that. But when hitting some physical bound of the sdcard (In my case every ~265kb) the sdcard reports it is busy and the write function waits until sdcard is ready. This can take >100ms. During this time the main loop of speeduino would be blocked creating all sorts of problems.
The solution in my opinion is an asynchronous (or DMA) version of the FatFs file system library. Where a write to the file system that waits on the sdcard returns with a “waiting on sdcard” flag. So that the main loop can continue and writing the same info can be tried a next loop. This solution also needs a asynchronous Sdcard I/O layer that is not there yet.
Because sdcard logging function is not strictly needed with data logging using phones or other devices i stop working on it for the moment. Or until i have a very bright light bulb to fix it . (Or someone here on the forum knows a good solution for this of-course ).