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.
Nice one, I had similar issue while back so direct sector/track was fine for me then but, this looks better for some compatability issues, thanks for posting :-)
how about STANAG- 4575?
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.
Nice idea Nick :-)
Makes good sense from good management planning perspectives and removes some line of security flaws too, pre allocation in many environments can be a good discipline, thanks worth a look :-)
Absolutely awesome! Also following your blog/github, Jo. Looks like you have some really awesome projects on there. Do you have a Twitter account we can follow to?
This really has blossomed in the last 12 months. A while back I was looking for a storage solution on a SPI EEPROM… I found:
– eefs: https://github.com/nasa/eefs
– spiffs: https://github.com/pellepl/spiffs
Since then, I’ve learned about LittleFS (https://github.com/ARMmbed/littlefs), now we can add this to the collection.
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.
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. ;-;
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.
ESP8266 has SPIFFS if I recall, but I’ve never used it
I could see this being handy in those RIPE NCC probes.