Some months ago, I bought a 4DSystem’s µDRIVE-uSD-G1 (microDRIVE) from Sparkfun. It’s basically a serial module which let you access a microSD memory card (from 512Mb to 2Gig). You may wonder why use an external module as SD cards have a SPI interface? The main reason is … laziness. All file-system operations are performed by the module. So why bother coding fat16 support or whatever? Unfortunately, the current microDRIVE firmware only supports raw access.
Anyway, I wrote a small module for the current firmware. It was implemented as a template in order to support various serial implementations. The serial class must provide the following methods :
- uint8_t read()
- void print(uint8_t)
- int available()
It’d have been better if all the serial implementations derived from a same interface. But as I didn’t want to modify the base Arduino code (and as i said earlier, because I’m lazy), I went for the easy/brutal way. And you’d probably never have more than one microDRIVE. At least you want raid 😀
I tested Arduino‘s HardwareSerial and SoftwareSerial, as long as ladyada’s AFSoftSerial. None of the software implementations work 😐 Only soft read is working (hardware tx was used). As software serial is working for the serial LCD, I think the problem might be the autobaud detection during microDRIVE initialization… Or not…
Be careful! There’s a bug in the rev1 firmware. The internal memory address is not incremented to the next sector block after a write operation. It was corrected in the rev2.
I’m thinking of using the microdrive, and would appreciate an update on how well it has worked for you. Did you get softSerial to work for you? Have you measured thruput (max data rate reading or writing)? And finally, does the microDRIVE controller take care of erasing blocks on the SD card so they can be reused reliably?
Thanks,
jeff
Back then, I didn’t manage to get sofSerial working. My guess was that the auto baud detection failed due to timing issues. Unfortunately I don’t have the tools to check if it’s true.
I didn’t make any thruput measure.
No idea. But I think it doesn’t.
And to be honest, unless 4dsystems release a new firmware with fat support, it’d recommend accessing the SD card via SPI.
I’ve looked at a lot of SD and microSD solutions. Most get as far as writing a page of data to an SD card and calling a success. But a practical SD solution is a lot more complex. Here are a couple of FAT solutions I’ve found: The DOSonCHIP breakout board at Sparkfun (and elsewhere) and the uALFAT-TF board at GHI electronics. I haven’t used either one, but I did see on one forum a user say that DOSonCHIP was giving him problems and he was switching to uALFAT-TF.
For my project, I’m thinking of going even simpler — just using a flash memory chip via SPI. No fat, or course, but the datasheets give me everything I need to manage the flash memory. Sparkfun and Futurlec both have a breakout board for a 16Mbit flash chip.
uDrive just got updated so it can now read and write FAT files. And the update is free too, for anyone who already has a uDrive.
I’ve just written up some experiments at http://www.instructables.com/id/Simple-mass-storage-for-your-microcontroller-proje/
It is nifty to write tiny little files of 10 to 20 (or even 1) character and then save them and then see them on a PC.
I tried to update the firmware with an µUSB-MB5. But it didn’t work. The activity led didn’t even blink… I’ll pick up a ftdi based board like the µUSB-CE5.