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
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
Compiler optimization
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.
RTOS configuration
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.
Runtime library
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.
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
Compiler optimization
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.
RTOS configuration
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.
Sign up here with your email
ConversionConversion EmoticonEmoticon