With the right file system, the designer of an embedded IoT device can save on time and bill of materials (BOM) costs – thanks to features that improve design flexibility and resource efficiency.

So you are designing an embedded device, probably at the edge of the Internet of Things. A question you may be asking yourself is, “Do I need a file system?”

While the device’s existing driver or firmware can handle a lot of memory management needs, a number of important questions may be left unanswered. What about the routines you will need to test these functions? And what if the data you are logging overruns the amount of space you have allocated? Now you need to write routines to handle expanding the allocation. Maybe you can just create two separate areas and switch to the second when the first fills up – the list goes on.

A further issue is that not all file systems are created equal. A boundary you don’t want to cross (or be pushed over) is the one keeping BOM expenses in line. These could rise if you are constrained by a file system package you cannot alter or tailor to fit your design requirements.

It is quite the puzzle – but let’s dive in.

Dealing with flash media

Let’s focus on flash media for now, as that is the most common storage for embedded systems. This sort of media can be in a raw format (NAND or NOR flash) or packaged in some form, such as eMMC, SD media, or CompactFlash. Flash media drivers will need to take care of error detection, error correction, and bad block management, resulting in a simple block-based storage.

As a start, this storage media can be thought of as a memory pool. The flash media driver or firmware will handle the wear leveling, meaning the media can be addressed directly (write to block 1, read from block 2, etc.) without exceeding the erase limits in a particular section. Early implementations of PC BIOS actually used CMOS SRAM to store the BIOS settings, though it was not directly accessible as a memory pool. Later BIOS implementations used flash media as a standard storage for both the BIOS settings and the BIOS code itself.

Message logging, either debug or runtime, is a common use for storage media. An application can write to a log area by keeping track of a current log pointer and wrapping when it reaches the end. These routines should be as solidly tested as the rest of the embedded device, of course.

Related content:

Read our tips on choosing between NAND and NOR flash.

Complexity considerations

If more than one log area needs to be written, two pointers could be maintained, with a corresponding increase in testing complexity. If each log area will be written from a different thread, even more overhead code will have to be added, because most flash memory doesn’t allow for two simultaneous writes.

Another use for storage media in an embedded device is to keep configuration settings. Assuming these can be changed at runtime, the added complexity of handling a power interruption is introduced. Two copies of the settings can be kept, with a runtime update overwriting the older copy. This code also needs to be tested thoroughly – a failure here can result in lost settings or even a bricked device.

The case for a file system

Anything more complex than the examples cited earlier are probably best handled through a file system. File systems can handle multiple files, multiple threads and power interruption. And using a file system gives access to added information from metadata – file creation and/or access date and time, file size, and attributes.

File attributes allow some control over who has access to a file, allowing a device to have multiple users and some basic security. Beyond the basic FAT file system are options such as Tuxera Reliance family, with full OEM attributes and support for Linux style groups and permissions.

Finally, a file system is pretty much required if your embedded device can be connected to a desktop or workstation. These larger machines access all their data through file systems or abstractions. The alternative is a custom driver to both copy down a media image and parse it into meaningful data packets. These could subsequently be stored in files or inserted into a local database.

Avoiding higher BOM costs with the right file system

More important than the addition of all these features, however, is the ability to offload the additional testing to a third party. The file system developer can test more thoroughly and provide a solid base, allowing your testing crew to stick to what they know – testing your particular design and application.

Of course, file system functionality also takes additional resources from your design. Working with a file system package that can’t be modified may push your resources over a boundary and increase your bill of materials cost.

A better alternative is an off-the-shelf file system that can be easily modified or adapted to get just what you need for the design, and no more. Tuxera Reliance Edge^TM provides developers with the flexibility and deterministic control to keep unnecessary resource costs at a minimum, while cutting down on testing-related time expenses.

Final thoughts

So do you need a file system? The short answer is that if you are going to store data on the media, you either have to write a primitive file system yourself (and all which that entails) or use one that is already precision-engineered for resource efficiency and customizability. The latter option allows you to reduce your software testing needs, with the possible cost of unused functionality.

The ability to modify a file system to suit your needs – for size, performance, and reliability – can be critical, potentially saving you more time and effort than even writing a basic logging alternative to a file system.