I have posted a new version of SdFat that has CRC support for SD cards. Enabling CRC checking increases reliability
at the cost of speed.
I have implemented two options, a faster larger table driven CRC-CCITT version and a smaller slower version.
Here are benchmarks with the new SdFat:
No CRC:
Write 192.6 KB/sec
Read 296.2 KB/sec
Lookup table CRC (total cost about 800 bytes of flash):
Write 135.1 KB/sec
Read 184.6 KB/sec
Non-lookup CRC (total cost about 300 bytes of flash):
Write 92.9 KB/sec
Read 116.4 KB/sec
I also have made changes to support alternative serial libraries like my SerialPort library.
Error messages and output from programs are now sent to a stdOut Print
stream.
The default stdOut is a small non-interrupt driven class that outputs messages
to serial port zero. This allows an alternative Serial library like SerialPort
to be used with SdFat.
You can redirect stdOut with SdFat::setStdOut(Print* stream) and
get the current stdOut stream with SdFat::stdOut().
If USE_SERIAL_FOR_STD_OUT in SdFatConfig.h is nonzero, the Arduino Serial
object will be used as the default for stdOut.
Without CRC there is no error detection on the SPI bus. Read/write data errors will not be detected if the SPI signals are marginal. Here is an example of what can happen:
Enabling CRC will cause the SD card to check the CRC on commands and write data. The SdFat library will check the CRC on read data. This dramatically reduces the possibility of undetected errors.
I have an application where I need a relatively fast 16 bit CRC. I may or may not also be using SDfat. It would be great to have a single CRC function for both standalone use, and for SDfat use, especially given the size of the lookup table.
Is there any chance of having the CRC function and table moved into a separate library, which can be used independently without pulling in SDFat overhead if it's not otherwise needed - and which SDfat will use if needed (rather than having two implementations loaded)?
Or is there a good way for me to do this? Can I use just the CRC functionality without pulling in more code or using more RAM from the SDfat functionality?
Yes, I figured that I could and probably will lift the CRC code for standalone use.
Some versions of my code will also use the SDfat library tho, which means that in those versions I'll have two copies of essentially the same CRC code and table loaded in memory, right? (my own lifted copy, and the copy built into SDfat).
What I was wondering was whether SDfat could be refactored so that the CRC code was separate, but used by SDfat, like SPI.
Case 1: using standalone CRC library only, no SDFat loaded
Case 2: using standalone CRC library and SDfat, latter of which also (potentially) uses the same standalone CRC library code & table
Case 3: using SDfat only without CRC support - no CRC code & table loaded (maybe)
Almost no one uses CRC with SdFat so the table and function are not loaded by default.
If you want to use CRC with SdFat and in your app, do what I told you above - remove the static declaration and share the table and function.
You can easily do this and since there is no other user interest, it's not worth making sharing CRC a feature of SdFat. I get almost daily requests like this and I just can't add bloat for every user's request.
