Sign In
Forgot Password?
Sign In | | Create Account

Embedded file systems

Colin Walls

Colin Walls

Posted Sep 30, 2013
2 Comments

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.

file system, Linux, RTOS, Nucleus

More Blog Posts

About Colin Walls Follow on Twitter

Colin WallsI have over twenty-five years experience in the electronics industry, largely dedicated to embedded software. A frequent presenter at conferences and seminars and author of numerous technical articles and two books on embedded software, I am a member of the marketing team of the Mentor Graphics Embedded Systems Division, and am based in the UK. Away from work, I have a wide range of interests including photography and trying to point my two daughters in the right direction in life. Learn more about Colin, including his go-to karaoke song and the best parts of being British: http://go.mentor.com/3_acv Visit The Colin Walls Blog

More Posts by Colin Walls

Comments 2

Post a Comment
Completely agree about using a file system designed for an embedded environment. Mentor's Nucleus RTOS does a great job with multithreaded and multicore environments - while performance can drop a bit in individual threads, the writes and reads across all threads have great throughput!

Thom Denholm
3:45 PM Oct 25, 2013

Nice, thanks for your posting we are also in the same field and welcome to visit our website.

Marina Yana
4:35 AM Jul 21, 2014

Add Your Comment

Please complete the following information to comment or sign in.

(Your email will not be published)

Archives

 
Online Chat