2014-07-15 05:29 PM
Hi!
I have a small rtos and I have to write a string every 5 ms to a sdcard. This (pseudo)Code works fine:void SDTask(...){
// some init
for( ;; ){
SDopen(&File);
SDWriteString(&File,SDstring);
SDclose(&File);
// leave the task here
}
}
Due to the long time for opening and closing the filepointer I did the following:
void SDTask(...){
// some init
SDopen(&File);
for( ;; ){
SDWriteString(&File,SDstring);
// leave the task here
}
}
But this code isnt working! My file is empty, but in the filepointer the filesize is increasing and there is also no error while ''writing'' the data. But it seems as if the data goes everywhere else but in the file.. :(
what could be wrong? Not closing the file is intentionally.
2014-07-15 05:36 PM
The file doesn't really exists until the directory entry is updated and flushed to the media, until then it's and empty placeholder.
2014-07-16 05:33 AM
Oh thanks! Let me guess: the flashing and updating happens with closing the filepointer?
Do you know a fast implementation of a sdcard driver for the stm32f4?2014-07-16 06:02 AM
The trick with file systems and mass storage devices is NOT to write small bits of data. You should try not to write anything smaller than a cluster, and something like 32KB is about optimum (speed/resources). So suggest you have a buffer, and accumulate enough data before doing a write. To have the file data be valid on the media you should probably flush or close periodically.
2014-07-16 06:04 AM
OK, I found the flush function. but flushing is slow so I have to find another solution..
2014-07-16 06:27 AM
Well you probably wouldn't want to flush every 5 ms. You need to think harder about what you are writing, how often, and if you can control the removal of the media.
But define ''slow'', an STM32F4 4-bit SDIO implementation on to a MicroSD card should be able to deliver >7MBps writes You could also implement a lazy writer caching mechanism.2014-07-16 07:50 AM
Now I am caching some data and I am writing only if x bytes of data are in the buffer. Thats ok.
With slow I mean that open - write - close takes about 15ms. Thats too much for a 4ms cycle :)2014-07-16 09:27 AM
Yeah, I wouldn't have the collection task doing the writing. Have the acquisition occurring in a high priority task, buffering to some lower priority worker task to commit to the media. At a minimum I'd suggest 8K writes, and then decide at what frequency you want to flush/sync the card content. Ideally you'd stop the acquisition and close the file before permitting it to be removed. Or have some threshold for data loss if the card is randomly removed. If you permit the card to be randomly removed you run the risk of data loss or card corruption anyway.