The Problem With One Giant Struct
Almost every embedded system needs to save data somewhere. Serial numbers, calibration values, feature settings, configuration parameters, and user preferences all need to survive a power cycle.
For many developers, the simplest solution is to define a large data structure and write it directly to EEPROM or flash memory. It works, but the approach comes with a long list of headaches. As products evolve, data structures grow, fields get renamed, and new features require additional storage. Before long, unrelated subsystems become tightly coupled to the same block of memory.
A small change in one area of the firmware can have consequences elsewhere. Even worse, maintaining compatibility with older data layouts becomes increasingly difficult.
CLI Systems believes there is a better way.
Borrowing an Idea From Tape Drives
UTFS, short for micro TAR File System, is an open-source storage layer designed for resource-constrained embedded systems. Rather than treating EEPROM or flash as one large block of application data, UTFS organizes information as individual named files.
The inspiration comes from an unlikely source: magnetic tape archives.
Back in the 1970s, the TAR format was created to store multiple files on tape drives, which provided little more than a flat stream of storage. Files were written sequentially, each with a header describing the data that followed.
UTFS applies a similar concept to modern embedded systems. Instead of the 512-byte headers used by TAR, UTFS uses a 24-byte header containing a file identifier, signature value, size information, and a short filename. Data blocks are then stored one after another in memory.
The result is a lightweight structure that can organize data without requiring a full file system.
Built for Microcontrollers
Unlike FAT, EXT4, and other file systems designed for desktop computers, UTFS focuses on the needs of embedded firmware.
There are no directories, permissions, ownership settings, or complex metadata structures. The entire library consists of two source files written in C99 and requires no dynamic memory allocation.
Porting it to new hardware is straightforward. Developers only need to provide two functions: one for reading data from storage and one for writing it back.
UTFS can operate on EEPROM, internal flash, external SPI flash, I²C memory devices, or virtually any storage medium that presents a flat address space.
Designed for Change
One of the more interesting aspects of UTFS is how it handles evolving data structures.
Embedded products rarely remain unchanged throughout their lifetime. A serial number field that originally required eight characters may later need sixteen. New configuration values may be added years after a product has shipped.
Traditional approaches often force developers to rearrange structures, reserve unused memory, or create complicated migration code.
UTFS takes a different approach. Since data is stored as separate named files, changes to one subsystem do not require unrelated parts of the firmware to understand the new layout. File sizes can grow or shrink, and the storage layout automatically adjusts the next time data is saved.
The system also includes a built-in signature field that can be used for version management, data validation, or migration logic.
Less About Files, More About Organization
UTFS is not trying to compete with desktop file systems. It doesn't include journaling, wear leveling, atomic commits, or other advanced features.
Instead, it focuses on a much narrower goal: giving embedded developers a simple way to organize persistent data without building a custom storage format for every project.
For developers working with small microcontrollers and limited memory resources, that may be exactly what is needed. Sometimes the best solution isn't adding another layer of complexity. It's finding a cleaner way to manage the data that was already there.