SD CARD

Hello RAG,

The SD Card implementation on the TM4C uses the SPI interface to communicate. You may want to

1. On your existing device try configuring the SPI with a higher interface clock as permitted
2. Switch to a TM4C129 to use the Serial SPI Flash and Advanced Mode of SSI to transfer data with a higher throughput.

Regards
Amit

Also note that the cards themselves have a finite write time, they are flash devices after all. This delay is manufacturer, not necessarily brand, dependent and may vary from model to model.

This delay is also longer if the card has to do a copy and erase cycle, which may happen if your writes do not match the writable size.

Besides Amit's suggestion you should also make sure you are properly buffering and that the SD write takes place in a separate thread.

Robert

Hello RAG,

 To add to what has been said already.....Also look at pre-erasing the card to attempt to take away some of the latency. I've never actually tried this and there seems to be some debate if it'll make any difference. Also is software FIFO buffering the data in RAM an option? If the latency is there every cycle it'll catch up with the process anyway depending on speed. But if your speed is high but duration short it might be an option.

Another is to look at the Class number of cards. The better classes do run faster, upto a nominal SPI specification of 25Mhz but some are reputed to run faster. The 1mS latency is good compared to some, some go AWOL at times for quite a long time if they're doing house keeping. 

Amit's suggestion of using SDbus mode for greater speed is good in principle, but the driver to do it is much more complicated, especially in 4bit mode, in which I think you HAVE to use CRC16. The Quad SSI hardware looks like it'll be great at doing the SDbusmode but the overhead of computing 4 threads of CRC16 makes it debatable that even on the TM4C1294 that has a hardware CRC engine (the TM4C123GH6PM does not)  if there'll be any speed advantage. Maybe Amit knows of a library to do it and take the pain away for that? He manages to conjure up virtually everything else!

Have you thought about CF cards?

My sense is that poster has presented conflicting goals - has supplied inadequate detail - and the "effort-lite" subject line: "SD Card" should discourage serious response.   (I break my firm's "response rule" due to efforts of: Robert, Pete & Amit.)

What's in conflict?

• poster reports, "Losing many data"
• employs an undescribed SD card
• desires (only) to write into (again) an unknown SD card
• employs this vendor's "bottom of barrel" MCU
• data is collected via a UART (blistering speed, there)

Should not the (real) issue have been framed as, "How may data be securely logged at the fastest, most error-free rate?   Instead - the poster (who clearly does not know) has dictated the, "field of battle, the armaments etc." can this be good?   Bravo to Pete & Robert for, "widening a too narrow field."

In answer - would it not prove "normal/customary" to first determine:

• best MCU for this purpose
• best storage media (not limited to SD card)
• eliminate the UART bottleneck

Do we not, "Fall into a trap" when we enable posters' "Proposed methods of attack" to dictate - and too often overwhelm - a more thoughtful and experienced - response?   Poster Guidelines have been proposed for many years - never adopted - and (quite predictably) such inefficiencies result.

Posters would do far better to fully/properly describe their "end goal" - and avoid "coloring and/or priming" the response of (experienced) responders.   Poster's imposition of, "not well thought" limitations (in the guise of a "solution") may confound free thought - and steer far from the correct course...

Thanks a lot for your suggestion sir.