FAT Support For Any Microcontroller

[Rahul Sapre] sent us a guide to porting EFSL to any microcontroller (PDF). The Embedded Filesystems Library adds FAT support to C compiled microcontrollers. It is targeted at the AVR line of chips but can be adapted to any architecture that works with a C compiler. [Rahul’s] guide will take you through the process of adapting the latest stable 0.2.8 version to new hardware by using a PIC uC as the working example. The non-stable development branch of EFSL is working toward multiple-platform support so consider lending a hand if this interests you.

24 thoughts on “FAT Support For Any Microcontroller

  1. sigh.

    Besides what I’ve been doing at my site above,

    http://github.com/sparkfun
    fat32lib is still a WiP, but fits in 10K with everything and usually doesn’t need it.

    Arduino and Linux tested, but should be endian agnostic. High speed SDHC, uses under 600 bytes.

    Used to get the jpeg trigger and and eye-fi upload a series of jpegs (dcimmer at the above site) which worked.

    Find something with a FAT12 other than a floppy. And FAT16 is also legacy.

  2. Is there any way to have a uC present itself as a FAT formatted block device (preferably via USB)?

    Basically a “fake” memory card that is readable and writable by a computer.

  3. I’ve been thinking for a while to build a programmer which presents itself as a mass storage device to the computer, and to program your chip you just drag & drop the .hex to the drive. A few vitual files could be used to access fuses, eeprom, etc.

    However I’ve been too lazy to actually do it so I hope it inspires someone else.

  4. Ready-to-use solutions seldom appeal to me. In this case, I would more benefit from a concise documentation of the expected disk format. Of course, various bits about de oldie FAT can be found online, or deduced from some existing source code — but that’s the point: a knowledge in universal form (not bound to a specific language) and proven by its recent use is no less useful. What if I haven’t these 1K of RAM and 10K of code at hand – but I’m willing to sacrifice large chunks of functionality or even write in assembly?

    Though I have to admit, my own software written for own needs does not always start with clear guidelines which are subsequently updated.

  5. “vic: I’ve been thinking for a while to build a programmer which presents itself as a mass storage device to the computer, and to program your chip you just drag & drop the .hex to the drive. A few vitual files could be used to access fuses, eeprom, etc.”

    @vic it exists, and #sparkfun sells it.

    Further, I own one, and it blows.

  6. Perhaps it’s time for me to look at a FAT driver. Fixed allocation and fixed card size sucks.
    But since I already have a SD lib with write buffering, command queuing and streaming, I would only need the FAT layer. I guess I could use any FS and just transfer files with ethernet. Heck, the remote app could manage the filesystem if you normally only need read-access. Log files can be fix-size sequential system files.
    It’s really too bad the SPI h/w of AVRs has such a shallow FIFO.

  7. @vic:

    “I’ve been thinking for a while to build a programmer which presents itself as a mass storage device to the computer, and to program your chip you just drag & drop the .hex to the drive.”

    This is exactly how the NXP LPC134x / LPC17xx USB boot loader works. If you pull the right pins up/down during reset, these Cortex-M3 devices will enumerate as USB mass storage class devices and you can copy ‘firmware.bin’ to/from the uC’s flash ROM. Very cool idea.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.