Here is a sample sketch for Teensy 3.5 / 3.6 logging using the SDIO SD card slot:
https://github.com/tni/teensy-samples/blob/master/SdFatSDIO_low_latency_logger.ino
It uses SdFat beta. Data is acquired in an ISR (ensuring stable capture timing) and passed to the main loop using an interrupt-safe queue.
The main loop is responsible for writing to SD. A pre-allocated, pre-erased file is used. This drastically cuts down worst case SD write latency from potentially >850ms to 40ms (so a much smaller write buffer can be used). It also eliminates file system corruption issues, when Teensy is rebooted / power cycled during logging, since no FAT updates are performed while logging.
If the logging is interrupted, the log file will contain the logged records and pre-erased content (typically all bytes set to 0 - depends on SD card). If the log is properly closed, it will get truncated to the amount of data that was logged.
Records are written back-to-back. There is no need for using a special block with padding. (A write buffer is used for partial sectors.)
https://github.com/tni/teensy-samples/blob/master/SdFatSDIO_low_latency_logger.ino
It uses SdFat beta. Data is acquired in an ISR (ensuring stable capture timing) and passed to the main loop using an interrupt-safe queue.
The main loop is responsible for writing to SD. A pre-allocated, pre-erased file is used. This drastically cuts down worst case SD write latency from potentially >850ms to 40ms (so a much smaller write buffer can be used). It also eliminates file system corruption issues, when Teensy is rebooted / power cycled during logging, since no FAT updates are performed while logging.
If the logging is interrupted, the log file will contain the logged records and pre-erased content (typically all bytes set to 0 - depends on SD card). If the log is properly closed, it will get truncated to the amount of data that was logged.
Records are written back-to-back. There is no need for using a special block with padding. (A write buffer is used for partial sectors.)