Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > Embedded

Measuring RTOS performance

Posted: 18 Dec 2014 ?? ?Print Version ?Bookmark and Share

Keywords:Embedded systems? CPU? RTOS? ROM? RAM?

Desktop or laptop computers are tremendously powerful and amazingly low-cost. This means that developers of software for desktop systems assume that there is infinite CPU power, so they worry very little about the speed of their code. They also assume that indefinite amounts of memory are available, so they do not worry about code size either.

Embedded systems are different. Typically, there is enough CPU power to do the job, but only just enough C there is no excess. Memory size is limited. It is not normally unreasonably small, but there is unlikely to be any possibility of adding more. Power consumption is usually an issue and the software C its size and efficiency C can have a significant bearing on the number of Watts burned by the embedded device. It is clear that, with an embedded system, it is vital that the RTOS has the smallest possible impact on memory footprint and makes very efficient use of the CPU.

Selecting an RTOS for an embedded system is quite a complex process and making the right decision is critical. There are broadly three approaches:
???You can develop your own kernel, though this is rarely a financially sensible choice.
???The world of open source software provides some options, although, if you need real time performance, you are somewhat restricted.
???You can choose a commercial product.

There are of the order of 200 RTOS products on the market and choosing the right one for a given application is tough. The parameters that drive the choice are varied and to guide you down that path would take a complete paper in itself.

A key problem is that there is no real standardisation. One possibility would be the Embedded Microprocessor Benchmark Consortium, but that is not widely adopted and, anyway, it is more oriented towards CPU benchmarking.

However, one aspect to focus on is the performance of the RTOS. All vendors publish figures and will answer questions. The skill that the potential RTOS user needs to develop is the ability to ask the right questions and to understand the answers. Comparing like with like is a challenge.

RTOS Metrics. There are three areas of interest if you are looking at the performance and usage characteristics of an RTOS:
???Memory C how much ROM and RAM does the kernel need and how is this affected by options and configuration.
???Latency, which is broadly the delay between something happening and the response to that occurrence. This is a particular minefield of terminology and misinformation, but there are two essential latencies to consider: interrupt response and task scheduling.
???Performance of kernel services. How long does it take to perform specific actions?

Each of these measurements will be addressed in turn in terms of 1) the metrics to be used, 2) dependencies to watch out for, 3) importance in your design and 4) pitfalls to avoid.

Memory footprint
As all embedded systems have some limitations on available memory, the requirements of an RTOS, on a given CPU, need to be understood. An OS will use both ROM and RAM.

ROM, which is normally flash memory, is used to store the kernel code, along with the code for the runtime library and any middleware components. This code C or parts of it C may be copied to RAM on boot up, as this can offer improved performance. There is also likely to be some read only data. If the kernel is statically configured, this data will include extensive information about kernel objects. However, nowadays, most kernels are dynamically configured.

RAM space will be used for kernel data structures, including some or all of the kernel object information, again depending upon whether the kernel is statically or dynamically configured. There will also be some global variables.

If code is copied from flash to RAM, that space must also be accounted for.

Dependencies. There are a number of factors that affect the memory footprint of an RTOS. The CPU architecture is key. The number of instructions can vary drastically from one processor to another, so looking at size figures for, say, PowerPC give no indication of what the ARM version might be like.

Embedded compilers generally have a large number of optimisation settings. These can be used to reduce code size, but that will most likely affect performance. Optimisations affect ROM footprint, but also RAM if the code is copied. Data size can also be affected by optimisation, as data structures can be packed or unpacked. Again both ROM and RAM can be affected. Packing data has an adverse effect on performance.

Most RTOS products have a number of optional components. Obviously, the choice of those components will have a very significant effect upon memory footprint.

1???2???3???4?Next Page?Last Page

Article Comments - Measuring RTOS performance
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top