Computer Science

Share this article:

Computer Science

  • Join our comunity:

RTOS Memory Footprint

By: , Posted on: January 18, 2018

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 one CPU type is likely to be very different from another. Even different CPUs in the same family may yield very different code sizes.
  • 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 a typical embedded CPU 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.”

Read more from Colin about embedded software on SciTech Connect

Colin’s most recent publication, Embedded Software: The Works is available now on the Elsevier Store and on ScienceDirectEmbedded Software The Works new cover

Save 30% on his book and other Newnes Press and embedded systems books. Use discount code “STC317″ at checkout. 

About the Author

Colin WallsColin Walls (@Colin_Walls) is an embedded software technologist at Mentor Graphics (@mentor_graphics), the leading EDA software company.

You can read more about Colin and his work on embedded systems at The Colin Walls Blog at Mentor Graphics here. Connect with Colin online here:

facebook google plus linkedin slideshare twitter wordpress

Connect with us on social media and stay up to date on new articles

Computer Science

Computing functionality is ubiquitous. Today this logic is built into almost any machine you can think of, from home electronics and appliances to motor vehicles, and it governs the infrastructures we depend on daily — telecommunication, public utilities, transportation. Maintaining it all and driving it forward are professionals and researchers in computer science, across disciplines including:

  • Computer Architecture and Computer Organization and Design
  • Data Management, Big Data, Data Warehousing, Data Mining, and Business Intelligence (BI)
  • Human Computer Interaction (HCI), User Experience (UX), User Interface (UI), Interaction Design and Usability
  • Artificial intelligence (AI)
Morgan Kaufmann companion resources can be found here You can also access companion materials and instructor’s resources for all our new books on the Elsevier Store. Search by author, title or ISBN, then look for the “Resources” tab on any book page. Looking for companion materials or instructor’s resources for these titles? Connect below: