If you need to store some data on a resource-constrained embedded platform, the prospect of dragging in a dependency for something like FAT filesystem access to flash or other storage medium can seem rather daunting. Not only is your binary size now significantly larger, the overhead of these filesystems is also not insignificant as they were not really designed for this type of environment. Here [Drew Gaylo]’s UTFS format is an interesting alternative to just writing raw binary data to said storage medium.
As explained in the accompanying introduction article, the basic idea is similar in scope but very much slimmed down compared to the venerable Tape ARchive (TAR) format, hence the Micro (µ) Tar File System name. The provided UTFS implementation is quite small, spanning two source files in C99 with zero heap usage. Targeting a custom store medium requires implementing one read and one write function to match the underlying platform.
A couple of examples are also provided, covering using the built-in Flash of a SAMD20 MCU and the EEPROM of an ATmega328. Compared to raw binary data that’d have to be fully rewritten, UTFS allows for sections of the storage to be accessed as files and thus updated in-place.
I struggle to see where you would both want minimal FS and it wouldn’t make sense to just use a simple id + length style header for your file layout. This is only slightly more complex, but wastes space on magic headers, version, name, and CRC, that are all overkill for most embedded purposes. Anything that needs to allow dynamic writing would probably be better served with a more robust, existing system.
my thoughts exactly. there’s very little space between “too simple for FAT” and “too complicated for id+length”. mostly because reading FAT is so easy
I agree, “id+length” done in a class so it is transparent to my program is pretty much the way I go too – and if it is a lot of storage on a bigger processor you may as well go with an actual file system..
I didn’t anticipate that there could be a fully functional filesystem for even a 512 byte storage device. While I’ll still use raw packed structs for anything between 0.5KB to 32KB and LittleFS for anything above, it’s still great to see a neat option.
This fits exactly what I was looking for my bare metal macro and config storage for cross mcu protocol level stuff. I’m writing desktop app created macro/snippets to “Whatever mcu” is connected. I need a portable way to toss in some data (eeprom via i2c, flash, sd card?) where it doesn’t care if you’re too resource constrained. For my freertos and zephyr builds I have nvs built in. for some form of on the fly changeable storage on something like a ch552, this will fit the bill.
How does this compare against squashfs?
squashfs is even more complicated than FAT. it’s a full-featured (tho read-only) filesystem. symlinks and device nodes and everything. plus it’s compressed. it’s pretty simple for what it is, but it has a ton of features.