Sign In
Forgot Password?
Sign In | | Create Account

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.”

memory footprint, Nucleus, RTOS

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

No one has commented yet on this post. Be the first to comment below.

Add Your Comment

Please complete the following information to comment or sign in.

(Your email will not be published)

Archives

 
Online Chat