P029_NELE_AUG14_Layout 1 09/08/2012 09:39 Page 29 Embedded Design Operating Systems What’s your rtos’ footprint? Verifying performance metrics for embedded real time operating systems. By Colin Walls. ll embedded systems have some • Performance of kernel services. How long does limitations on the amount of memory it take to perform specific actions? Awhich can be included, which means the requirements of the system’s real time operating Dependencies system – on a given cpu – need to be There are a number of factors that understood. affect the memory footprint of an Normally, an operating system will use both rtos and the cpu architecture is rom and ram. ROM, usually in the form of flash key. The number of instructions can also be affected by memory, will store the kernel code, code for the can vary drastically from one optimisation, as data structures runtime library and any middleware components. processor to another, so looking may need to be packed or unpacked. RAM, meanwhile, will be used for kernel data at figures for, say, a PowerPC Again, both rom and structures, including some or all of the kernel based device, will give no ram can be affected. object information. There will also be some global indication of what the ARM Packing data has an variables stored. version might be like. adverse effect on When you are looking at the performance and Embedded compilers generally have performance. usage characteristics of an rtos, there are three a large number of optimisation Most rtos main areas of interest: settings. While these can be used to products have a • Memory. How much rom and ram does the reduce code size, that will most number of optional kernel need and how is this affected by options likely be at the expense of components. and configuration? performance. Data size Obviously, the choice of • Latency. Broadly the delay between something those components will happening and the response to that occurrence, have a very significant effect latency is a particular minefield of terminology upon memory footprint. Most rtos and misinformation. However, there are two kernels are scalable, which means that, all essential latencies to consider: interrupt being well, only the code to support required response; and task scheduling. functionality is included in the memory image. Fig 1: The components of interrupt latency Measurement Although an rtos vendor may provide or publish memory usage information, this data might be OS INT shell ISR particularly hard to interpret and, hence, misleading. Vendors do not mislead their Interrupt customers intentionally; it is simply that there response are a lot of variables and assumptions may be Interrupt Interrupt made. That means you may wish to make your CPU source controller own measurements in order to ensure the figures are representative of the type of application that you are designing. Interrupt latency Taking these measurements is not difficult. Normally, the map file – generated by the linker – gives the necessary memory utilisation data. Remember that different linkers will produce www.newelectronics.co.uk 14 August 2012 29 P029_NELE_AUG14_Layout 1 09/08/2012 09:39 Page 30 Embedded Design Operating Systems Measurements may be made in a similar way to the interrupt latency timings. The key stumbling block when it comes to looking at scheduling latency is ignoring the starting point. From system idle, there is only the time to set up a task’s context, there is no time the timer is also relevant, as its taken to save context. When trying to interpret interrupt ‘tick’ is competing with other interrupts quoted scheduling latency, the key hardware and for attention. software factors to verify are exactly the same as It is also important to know what kind of with interrupt latency. memory from which the code is running and how the kernel was built. For example, was the Timing kernel services different kinds of map files, each with varying code optimised for speed? Knowing which An rtos is likely to have a great many API calls, amounts of information provided in a variety of interrupt is in use is also important, as different probably numbering into the hundreds. To assess formats. Some specialised tools can extract interrupts may be handled in different ways on timing, it is not useful to try to analyse every memory usage information from executable files: different devices. single call; it makes more sense to focus solely on an example is objdump. Lastly, you need to know whether the supplied the frequently used services. figure is the best or the average. Quoted timing figures for kernel services need Interrupt latency to be read with the same care as the other The time related performance measurements are Scheduling latency numbers that have been reviewed above. Again, probably of most concern to developers using an A key part of the functionality of an rtos is its attention must be paid to the configuration of the rtos. A key characteristic of a real time system is ability to support a multithreading execution hardware and the software used to perform the its timely response to external events. An environment. Being real time, the efficiency at measurements. embedded system is typically notified of an event which threads or tasks are scheduled is of some A particular point to note is the usage of kernel by an interrupt, so the delay between the interrupt importance. error checking. Many rtos can be built with occurring and the response to that interrupt – the The scheduling latency is the maximum of two varying degrees of error checking included. This interrupt latency – is critical (see fig 1). times: checking is likely to have an effect on the timing Interrupt response is the sum of two times: tSL = max(tSO, tCS) characteristics of API calls. tIL = tH + tOS where: where: tSO is the scheduling overhead; the end of the ISR Conclusions tH is the hardware dependent time, which to the start of task schedule, and All rtos vendors provide performance data for their depends on the interrupt controller on the board tCS is the time taken to save and restore thread products. This information may be very useful, but as well as the type of the interrupt, and context. can also be misleading if interpreted incorrectly. tOS is the overhead induced by the operating It is important to understand the techniques system. used to make measurements and the terminology To measure a time interval, like interrupt used to describe the results. There are also trade latency, with any accuracy, requires a suitable offs – generally size against speed – and these instrument. The best tool to use is an oscilloscope. also need to be thoroughly understood. Without One approach is to use one pin on a GPIO interface this understanding, a fair comparison is not to generate the interrupt. This pin can be possible. monitored on the ‘scope. At the start of the If timing is critical to your application, it is interrupt service routine, another pin, which is strongly recommended that you perform your also being monitored, is toggled. The interval own measurements. This enables you to be sure between the two signals may be easily read from the hardware and software environment is the instrument. correct and the figures are directly relevant to The main problem with interrupt latency is the your application. interpretation of published figures. For hardware, you need to know precisely which platform and Author profile: interrupt controller is being used for Colin Walls is an embedded software technologist measurement, along with such factors as clock Walls: “The main problem with interrupt latency is the with Mentor Embedded interpretation of published figures.” speed and cache configuration. The frequency of (http://blogs.mentor.com/colinwalls). 30 14 August 2012 www.newelectronics.co.uk.