I have done a great deal of learning with SD cards recently, so much so I'd like to say Iv become a bit of a pro with understanding the nitty gritty of them.
The easier connection to them is using SPI, this does not get you crazy fast speeds like you see with dedicated SDCard readers, but with the correct memory management and block sizes, you can still get very decent speeds.
The last couple days have been going over some basic libraries to see how people currently handle using SDCards along with the common formatting for handling creating documents/files/ect.
When first using off the shelf libraries, writing a 4mega byte file (MB) took around 30seconds, this equated to about 130KB/s.
After some modifications with optimizing block sizes, clock speeds and transfer protocol, we do a 4MB file in 2.3seconds. This still equates to a little under 2megabytes per second, which isnt crazy large in terms of file transferring speeds that we see on computers, but in the world of microcontrollers, this is moving. Whats crazy, is this was the result of saving a millisecond between every operation which gave a huge boost in speed.
The reason for spending time on this is purely due to the reason of needing to be able to save or read files from an SDCard over a wireless connection (WIFI and Bluetooth). This comes more into play when reading the file off the SdCard when pulling something like a CSV log which could be many megabytes long.
This leads us to then optimizing how logs are saved, where by a simple 4byte timestamp and then a full CAN frame is used, all saved in raw byte form.
If logging at 60hz with 24PIDs, this would be 60x24x 16 = 23k bytes per second, which is 1.38MB per minute.
This is very much possible since CANbus is 500kbits/s which equates to a max bus load of about 62500bytes per second, so only 1/3rd of the network is still being used with the above figures.
Assuming someone logs for 15minutes, that will be roughly 20.7MB.
Still, not a big file, but that will be roughly 11.5seconds just to read the file via USB directly. Doesnt sound that bad right? Well.. the point of this is for wireless since everyone has a smartphone these days, but not a PC.
Our wireless module runs at 921600baud, which is roughly 155200 bytes per second, so assuming we could even maximise that throughput, transferring that file would take a minimum of 133seconds which is 2minutes 13sec for that 20.7MB file. Realistically, this is likely going to be more like 4minutes+ as have to account for the time it takes for each chunk of data to send plus the latency between each packet ect.
We have never needed to be faster then the 921600 serial baud rate for our wireless, since we have never needed to send large files in a short time span. But in this circumstance, we would actually benefit from migrating to a SPI connection so we can go to something like 50MHZ which would significantly speed up that transfer rate between the wireless to processor, that way the limiting factor is just the wireless protocol itself.
Anyways, Im rambling on a bit now here, but its just a bit of insite to how far we think ahead to identify our limitations to better design our hardware.
