RTOS memory footprint

Most of the time, I subscribe to the view that “the only stupid question is the one you did not ask”. However, I do have trouble with a question that I have been asked countless times at trade-shows, seminars etc. The question is “How much memory does Nucleus RTOS need?”

It is not that this is a stupid question. It is very sensible to be fully aware of resource utilization with deeply embedded systems. The problem is that I am rarely sure how to give a meaningful and useful answer, so I resort to generalities and this is often viewed with suspicion. The reason for this is that the answer is dependent upon a great many variables …

First, there is the question of what kind of memory we want to consider. Broadly speaking, there is ROM [nowadays that is usually flash memory] and 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 size of the code can vary for a selection of reasons:

• CPU architecture has a drastic influence. 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.
• Compiler optimization affects 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.
• The configuration of the RTOS can vary its size drastically. Most RTOSes are scalable, so the memory footprint is determined by the actual services used by the application. On a larger scale, other options, like networking, will affect the code size.
• Typically, a runtime library will be used alongside an RTOS; this code needs to be accommodated.

Apart from a baseline amount of storage for variables, the RAM requirements of an RTOS can similarly be affected by a number of factors:

• Compiler optimization also affects data size. Packed data is smaller, but takes more instructions to access.
• The number of RTOS objects [tasks, mailboxes, semaphores etc.] used by the application will affect the RTOS RAM usage – each object needs some RAM space.
• Normally, every task has its own stack, which must be stored in RAM. Allocation of this space may be done differently in a number of RTOSes, but it can never be ignored.
• If dynamic memory allocation is used by the application, space for memory pools needs to be accommodated.

Maybe it is clear why I rarely give a straight answer to this seemingly reasonable question. The nearest that I might get is to say something like: “Nucleus RTOS running on an ARM Cortex A8 in ARM mode yields a ROM size of 12-30 K and RAM of 500 bytes. The low end ROM size includes the essential services; the high value includes all services. The runtime library is excluded. Building the RTOS for Thumb-2 mode reduces the ROM size by more than a third.”