File Systems For Tiny Devices

Sometimes you build a computer and use it every day. Sometimes you build a different type of computer and it sits alone on a mountaintop for years. The design considerations for these two setups are remarkably different, right down to the type of file system used. For small computers like [Jo] is using, and for the amount of time they sit alone in remote locations, he decided to build his own file system for them.

Known as JesFs ([Jo]’s embedded serial File system), the file system is for SPI Flash and intended for use in scientific data logging. It can be used on the chip-scale processors found in many development boards, and is robust enough to use in applications where remoteness is a concern. It has a small RAM footprint, is completely open source, includes wear leveling, and has a number of security features built-in as well.

Some of the benefits of using a file system on such a tiny chip aren’t immediately obvious unless you’re doing a lot of data logging, but it does allow you to change virtually any aspect of the firmware much more easily if everything is accessible as a file, and not something you would have to change by reflashing the whole chip, for example. There are also a number of traps that you can easily fall into when working with file systems for tiny devices.

11 thoughts on “File Systems For Tiny Devices

  1. I solved a similar problem with PetitFFS. The advantage is that it uses normal FAT filesystems that interoperate with damn near everything. The disadvantage is that it can only write to existing files (so you have to preallocate them). I use it for read-only applications, and for that it’s excellent.

    1. I did some tests of various flash filesystems, performing millions of writes and erases on a simulated flash device. SPIFFS crapped out and corrupted part of a test file after a few hundred thousand writes, while LittleFS never failed.

      Obviously, that number of writes would very rarely be reached in practice, but results are results and I prefer LittleFS.

  2. Science data-logging in particular should favor data redundancy as well, I’d say.
    Even if god forbid your device failed, in various ways, or maybe one-off glitches, it should be fairly easy to get reliable data off the device.
    If you have absolute control over the File System, you can do this much easier than fairly typical generic FSes that aim to scale to anything.
    The redundancy can also apply to the hardware features in general. Multiple sensors for example.
    Or, since these systems can easily be produced cheaply, just distribute a bunch of them over an area. They can’t all die right? Unless it was a systemic flaw. ;-;

  3. There are two good options too: LittleFS from MBED and SmartFS from NuttX. Samsung added Journalling support to SmartFS, but they changed its license from BSD to Apache. Ironically now NuttX is going to be incubated under Apache Foundation and will change its license to Apache.

Leave a Reply to DanjovicCancel 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.