Logomatic and Loginator with SDHC and Fat32

Your Logomatic probably doesn't need fat32. It probably doesn't need more than 2GiB files or 2GiB of storage total. It probably doesn't have the battery life to support writing 2GiB.

But microSD cards that aren't SDHC are becoming hard to find. The hardware needed to interface SDHC is no different than normal microSD. It's just software. Your Logomatic (or mine for that matter, constructed in 2009) just needs a mind transplant, a simple firmware upgrade. Well, not so simple, because that firmware doesn't exist yet.

That's where I come in. I am back in the Logomatic (and Loginator, which is substantially the same) business, for the while until my attention drifts elsewhere. Hope I finish, or hope that you or someone reading can pick up where I leave off.

So, a word about the SD card software currently in the Logomatic and USB bootloader code. You can find the USB bootloader code on the Sparkfun USB bootloader tutorial, and the Logomatic firmware also on the Sparkfun site.

Remember that both of these programs are installed at the factory on each Logomatic, so you already have these in compiled form. They share no memory, but have much identical code. See, the USB bootloader needs to access the SD card, both to do the USB mass storage thing, and to check if your firmware FW.SFE file is there and read it and install it if necessary. It also has a USB driver to convert USB signals into microSD commands and vice versa. The Logomatic main firmware needs much of the same code (except for the USB part) to read its configuration files and write data to the card.

This code comes in the form of some .c files, along with supporting .h files. These files were the work of Roland Riegel, and through the magic of open source, we get to read and modify them as we see fit. As it turns out, Roland has already modified his code to handle SDHC cards, and as a logical extension, the fat32 file system. So what is left to us? Modifying this code to handle the LPC2148 chip instead of the ATmega32 that he uses. Yes, I just saw you Arduino users' ears perk up. Sorry to dissapoint, but I am not going to do anything with either Arduino or ATmega, but that doesn't mean that you can't.

So, here is how the sd-reader (as Roland calls his whole work) is structured. At its lowest level is sd_raw.c . This file is used to control the card and read and write blocks of it. This code can be used directly if you want to use the sd card without worrying about unnecessary bloatware like file systems. It also is used by the USB mass memory driver. In this case, the USB host (probably your desktop computer) sees the USB device (the Logomatic and its SD card) as a featureless sea of blocks. The USB wire protocol just concerns itself with reading and writing those blocks, along with such bookkeeping things as determining how many blocks there are. The USB driver in the LPC2148 mostly just interprets USB commands and uses the sd_raw library to fulfill these commands. The LPC2148 in this case doesn't care about filesystems. The host sees the raw blocks and it interprets them as a filesystem. In principle, this allows the host to use any filesystem it wants, without the Logomatic caring. If you wanted to, you could format the card in a Logomatic as fat16, fat32, ext4, whatever Mac uses this week, etc. We will see why this is not a good idea later.

On top of this low-level interface, we have

• fat16.c, which knows about directories and files 
• rootdir.c which sits on top of fat16 and makes it so that your code doesn't have to worry about directories 
• partition.c which reads the partition table on the sd card and finds the partitions so that fat16 knows where to start.

The file reader in the USB bootloader and the file reader and writer in the Logomatic main firmware are both based upon this code. This code specifically assumes that the card is formatted as FAT, FAT16 to be specific. If your card is not formatted as FAT16, then the USB bootloader will not be able to find and load FW.SFE. In this case, the code is running free, without the guidance of the USB host to interpret things. It needs to interpret the data on the card as a filesystem all by itself. If the filesystem is not FAT16, fat16.c will detect and complain about this, and the files will not be read nor written.

So how are we going to use all this code which was written for an ATmega on an LPC? That's the magic of C code and compilers. 99+% of the C code in these files will compile without change. This includes all of fat16, rootdir, and partition. These use sd_raw. Sd_raw in turn is about 99% portable as well. It knows the SD wire protocol, and how it sits on top o the SPI protocol. All it needs to know about the hardware is what registers control the SPI protocol and how to use them. This knowledge is isolated into a couple of functions, and we need only change these functions to port the code from ATmega to LPC. Almost all this code is already well-isolated, there is just one bit left that can be broken out.

More on this as I actually do it...