Embedded file systems

On desktop computers, data that you are working on right now, in an open application, is most likely just stored in RAM. When you are finished, the information is saved to disk for more permanent storage. That is the way it is for word processing, spreadsheets etc.; databases are bit different. The idea of having volatile memory for temporary use – where a power failure can cost you a morning’s work – and disks for persistent data is widely accepted. The only thing that is changing is the use of flash memory to build solid state drives [SSDs] instead of rotating magnetic disks.

Embedded systems seem to have similar needs, but there are key differences …

Traditionally, embedded systems have run code out of ROM or RAM and just kept data in RAM, with no persistent data retention. In some systems, non-volatile memory of some kind is fitted, which facilitates storage of set-up parameters or logging of data. A while ago, I discussed the broad topic of memory in embedded systems and later looked at some details of NVRAM utilization and this elicited some good reader response. However, modern systems are increasingly using something that looks like a file system.

Heavyweight embedded operating systems, that have their origins on the desktop, like Linux and Windows Embedded, need to have something which looks like a file system in order to run at all. Most real time operating systems [RTOSes] has a storage system as an option, as does Mentor Embedded’s Nucleus, which can be downloaded for free evaluation. Historically, such a storage system would most likely have been a disk drive and, indeed, it still can be. But flash storage is much more common.

Superficially, it might seem that a file system for an embedded device, that is part of an RTOS, is very similar to that used by a desktop operating system. In some respects, this is true, as compliance with standards is generally wise and interchange of data/media is an obvious requirement. However, additional functionality and specific characteristics are needed for an embedded file system. Most importantly, it must be thread friendly – it must allow multiple tasks to access the file system and not compromise their real time capabilities.

For some applications, greater resilience and security are needed and most RTOS vendors offer some additional options. Typically, developers are concerned with the possibility of data corruption resulting from power failure or media damage and this requires a specialized file system to guarantee integrity. Beyond RTOS vendors, other companies focus specifically on such technology. A good example is Datalight Inc., who recently announced support for Nucleus RTOS with their Reliance Nitro product.