Tutorial Tuesday: SD Cards and Writing Images
This tutorial will give you the tools you need to write different images to SD cards.
Today on "Tutorial Tuesday" (is that a thing? I think I just made it a thing), we are talking about SD cards. What could you possibly want to know about SD cards? Read on...
SD (secure digital) cards are just about everywhere -- from digital cameras to cell phones -- and they are an easy way to store all kinds of useful information. They are also used in many single-board computers (like the Raspberry Pi to store the operating system.
But sometimes using SD cards can be a bit tricky. Which is why we created this tutorial called "SD Cards and Writing Images -- where we talk about different types of SD cards and readers, formatting your card to erase any data that may be lurking around, installing your image, and how to use any left over space on the card.
Give it a read and feel free to leave any comments or questions below!
I found other SD card drivers obfuscated so I went to grass roots and wrote my own documented SD Card driver using SPI:
I hope another view helps to illuminate the subject.
Enjoy!
The tutorial materials pertaining to formatting SD Cards are naive, wrong, and potentially damaging. The One Laptop Per Child organization did intensive investigation into the performance of SD cards, because their installed base depended on them. Please see this document they posted on the matter, and conduct a proper investigation on how to correct your tutorial accordingly. I would start with contacting the SD Card Association, and the major manufacturers, and asking them what their preferred formatting procedures and tools are. You will no doubt be shocked at the differences from the ham-fisted approaches currently implemented in the Mac, Windows, and even Linux utilities you are currently recommending.
This tool appears on the SD Card Association's website, probably for damn good reason; asking the SD Card Association should tell you when and where you should and shouldn't use it.
One thing to keep in mind is some devboards (phones and tablets) require specific classes and size limits. As an example, some phones/tablets don't work with anything over 64GB.
This concept is the same with devboards. Don't use an SD Card that is too big or requires too fast of a clock that the processor can't handle.
I haven't looked at the SD spec since right around when SDXC was introduced, but IMHO the most important thing to pay attention to is the classification (i.e. SD Spec version). There is the original v1.x just called SD, then there was v2.x called SDHC (SD High Capacity), and finally v3.x called SDXC (SD eXtreme Capacity?). There is actually more difference between SD and SDHC (as the addressing is completely different) than between SDHC and SDXC. This is true at least from the SPI interface (which is how Arduinos communicate to the SD cards).
I was (at the time) writing assembler code to access SD cards at the byte/block level, similar to how EEPROMs are accessed. The application collected data into a 1Mb (megabit) FIFO and when the half-full interrupt was triggered I would dump 512bytes to the SD card. I had to have two different routines selectable by a flag that I would set when initializing the card. If SD the addressing was by byte number so I would have to increment my write counter by the size of the block (block sizes were variable, but I used 512bytes in my implementation). But for SDHC and higher I would only need to increment my write counter by one for the block number (blocks were fixed at 512bytes). My initialization routine was able to take note of an SDXC card, but I didn't have to handle them differently than an SDHC. Another part of the initialization determined the card size based on data encoded in one of the card's registers. (It's been several years so I don't remember which one.)
Almost forgot to mention. The SD cards that I was using didn't have integral clocks. So if I wasn't toggling the SCLK line of the SPI interface, no time passed for the SD card. And the only time the SCLK line was toggled was during an actual SPI data transfer, which even for multi-byte transfer occured at short bursts of 8 cycles. At that time I didn't run across an SD card that was adversely affected by trying to run it too slow. That may have changed with modern high-specification cards. But why would you pay the extra money for an SD card that can run 10 times the speed of the SPI bus on your target microcontroller? The max speed of the SPI bus (or even target speed) is the limiting factor in how fast you can access it.
Do SD cards really require 'too fast' of a clock frequency? I was always under the impression that the speed of the card was a potential of the card, not necessarily a requirement of how fast it needs to work.
And yes, the size of cards is pretty important.
This goes into the classes of SD Cards. Some instances, processors are limited on what Classes they support. I've had an issue with an old phone in the past were a Class 10 SDCard was never read properly, but when I got a Class 4/6 card, it worked perfectly.
It's probably a null-point now with the newer tech.
Here's some info on the classes/speeds of SD cards: https://www.sdcard.org/developers/overview/speed_class/
Hum, I wonder if there was an issue with the Class 10. I see this a lot in photography and there are a lot of mislabeled and counterfeit cards out there.
A class 10 card should be able to read at speeds equivalent to a 4 or 6. Or else you'd have to specifically match the card to the device.
It is possible that the SDCard has an Serial Presence Detect (SPD) system on it to determine speed. It's been years removed since doing detailed work on SDCards.