Are there any alternatives for SD.h library for Nano 33 BLE Sense Rev2 ? SdFat.h lib doesn't support this board. I want to achieve fast data logging (28 letter string every 250ms) but the SD.h lib isn't efficient in doing this and at times freezes the board.
Most likely, there are one or more problems with the code you forgot to post.
the SD.h lib isn't efficient
It is very efficient, if used correctly.
The code is 600 lines long, that's why I didn't post it.
You can't possibly frighten us with a mere 600 lines of code. Post it using code tags.
Rarely needed, and waste considerable time if used when not needed.
SD cards ain't fast to begin with. The overhead is the DOS emulation. That also makes it a blocking device (nothing else gets done until SD finishes.)
Your data rate isn't bad. Are you closing & reopening or running with the file open?
Close/reopen kills a lot of time but is safer in the event of random power off.
As I suspected, that is where a lot of time is going. flush() is NOT required here.
Pointless usage of Strings, which are never required, and lead to memory problems and program crashes.
Unnecessary SD open() and close() commands. Open a file when you start logging, and close it when you are done logging.
Why a "backup" file if you want fast logging?
Good luck with your project!
Each file requires a 512 byte buffer, which is allocated each time you open the file, and is written out each time you close it. So every time you open and close a file, you have to read or write an entire 512 byte block from or to the SD card.
That is extremely time consuming! Likewise, flush() has to write to the SD card to update the data block and file pointers. Otherwise, the memory buffer is only written out when full, then erased and refilled.
The only time I use flush() when logging is to update file pointers every 15 minutes to an hour, in case the power fails. That way, if power fails, you lose only the last data block.
Lastly, The Evils of Strings.
You're building a very long string there, that eats buffer. Finish a line before you get overflow issues.
An ounce of software optimization beats a pound of hardware ...
The issue is, if in any case a power failure occurs, I will loose 15 mins of data, but the entire mission time is less than 10 min once started. However, the system will sit on launch pad for 2 hrs and has to start data logging when commanded remotely.
In that case, collect data as fast as you can, without Strings, backup files, or any unnecessary flush, open or close commands. Small, efficient code has far less chance of failing.
You have a lot of code rewriting to do, so have fun.
if in any case a power failure occurs, I will loose 15 mins of data
Hint: please take a couple of minutes to think about what forum members write, and maybe do a bit of research before posting a silly objection like the above.