Most embedded systems of non-trivial complexity employ an operating system of some kind – commonly an RTOS. Ultimately, the OS is an overhead, which uses time and memory that could otherwise have been used by the application code. As an embedded system has limited resources, this overhead needs to be carefully evaluated, which commonly leads to questions about RTOS memory footprint. This article looks at how memory is used by an RTOS and why the memory footprint question may be hard to answer.
How big is the RTOS?
If you were considering the purchase of a real time operating system (or, for that matter, any piece of software IP for an embedded application), you would probably like to get clear information on the amount of memory that it uses. It is very likely that an RTOS vendor will be unwilling – or actually, to be more precise – unable to provide you with such seemingly obvious information. The reason for this is that there are a huge number of variables.
What type of memory?
There is the question of what kind of memory we want to consider. Broadly speaking, there is read only memory (ROM – nowadays that is usually flash memory) and read/write memory (RAM). ROM is where the code and constant data is stored; RAM is used for variables. However, to improve performance, it is not uncommon to copy code/data from ROM to RAM on boot up and then use the RAM copy. This is effective because RAM is normally faster to access than ROM. So, when thinking about of RTOS footprint, you need to consider ROM and RAM size, including the RAM copy possibility.
The issue can become more complex. There may be on-chip RAM and external memory available. The on-chip storage is likely to be faster, so it may be advantageous to ensure that RTOS code/data is stored there, as its performance will affect the whole application. In a similar fashion, code/data may be locked into cache memory, which tends to offer even higher performance.
Code size issues
A wide variety of factors can affect the size of the code:
CPU architecture has a drastic influence on the RTOS memory footprint. Code size for PowerPC, for example, is likely to be very different from ARM. Code built for Thumb-2 is likely to be significantly smaller than ARM. The only figures to accept are those for code built for the specific CPU that you are planning to use
When building code, like an RTOS, the optimization setting applied to the compiler affect both size and execution speed. Most of the time, code built for highest performance (i.e. fastest) will be bigger; code optimized to be smaller will run slower. It is most likely that an RTOS would normally be built for performance, not size. Although an RTOS vendor, wanting to emphasize the small size of their product, might make a different choice.
Real time operating systems tend to be very configurable and that configuration can vary the RTOS size drastically. Most RTOS products are scalable, so the memory footprint is determined by the actual services used by the application. The granularity of such scalability varies from one product to another. In some cases, each individual service is optional; in others, whole service groups are included or excluded – i.e. if support for a particular type of RTOS object (e.g. semaphore) is required, all the relevant services are included. On a larger scale, other options, like graphics, networking and other connectivity, will affect the code size, as these options may or may not be needed/included.
Typically, a runtime library will be used alongside an RTOS; this code needs to be accommodated. Again, the code, being a library, may scale well according to the needs of a particular application.
Data size issues
Apart from a baseline amount ofstorage for variables, the RAM requirements of an RTOS can similarly beaffected by a number of factors:
Aswith code, compiler optimization affects data size. Packed (compressed)data is smaller, but takes more instructions, and hence more time, toaccess.
The number of RTOS objects (tasks,mailboxes, semaphores etc.) used by the application will affect the RTOSRAM usage, as each object needs some RAM space.
Normally, the operating system has a stackand every task has its own stack; these must all be stored in RAM.Allocation of this space may be done differently in each RTOS, but itcan never be ignored.
If dynamic (partition/block)memory allocation is available with an RTOS and used by the application,space for memory pools needs to be accommodated.
Static and dynamic RTOS configuration
Early RTOSproducts required configuration to be performed at build time – i.e.statically. As the technology progressed, the facility to create (anddestroy) RTOS objects dynamically became commonplace. It is now quiteuncommon to find an RTOS that permits static configuration. The impacton memory utilization of these options is interesting.
A statically configured RTOS holds most the data about RTOS objectsin ROM. Some information needs to be copied to RAM, as it will bechanged during execution, but needs to be initialized. Other objectsneed extra RAM space at run time.
A dynamically configured RTOS keeps all object data in RAM – none inROM at all. However, there is a significant hit on ROM space, as therewill be extra service calls to perform object creation and destruction.
It should now be clear why itis unreasonable to expect a straight and simple answer to the question“How big is the xyz RTOS?” Realistically, the best response that mightbe expected is something like this:
“Nucleus RTOS running on an ARM Cortex A8 in ARM modeyields a ROM size of 12-30 K and RAM of 500 bytes. The low end ROM sizeincludes the essential services; the high value includes all services.The runtime library is excluded. Building the RTOS for Thumb-2 modereduces the ROM size by more than a third.”
Colin Walls has over thirty years experience in theelectronics industry, largely dedicated to embedded software. A frequentpresenter at conferences and seminars and author of numerous technicalarticles and two books on embedded software, Colin is an embeddedsoftware technologist with Mentor Embedded [the Mentor Graphics EmbeddedSoftware Division], and is based in the UK. His regular blog is locatedat: http://blogs.mentor.com/colinwalls. He may be reached by email at firstname.lastname@example.org