Choosing the right Road TO Success

An RTOS provides the developer with a framework on which to build and organise the features of their system. The toolbox that accompanies the RTOS should also provide services such as inter-task communication and time management. Even for systems that have no need of real-time capability, the code can be clearer and better organised if based on an RTOS, partly because it promotes code reuse.

The integration of an RTOS can solve a variety of problems that can occur in application code, since it provides multitasking capability and allows the application to be broken down into smaller pieces. Each task is assigned its own priority based on its importance, and pre-emptive scheduling tries to ensure that the microcontroller (MCU) runs the task that has the highest priority among those that are ready-to-run. In most cases, adding a lower priority task will not affect the responsiveness of the system to high priority tasks.

A clear benefit of using an RTOS is that it reduces time to market, because it simplifies development without consuming a lot of CPU time and memory. An RTOS generally offers a deterministic response, making it possible for critical tasks to meet their deadlines. Polling is avoided because tasks only run when events occur, and tasks waiting for events do not consume CPU cycles.

Many programmers may not be familiar with RTOS constraints and requirements; an RTOS is often chosen based on its performance or one’s comfort and familiarity with the product. However, such a selection criteria is insufficient. To make matters worse, there is a wide variety of RTOSs ranging from commercial, open-source or internally developed to choose from; making it incumbent upon the programmers to exercise extra caution in the selection process.

Software component.

An RTOS needs to be seen as just one component of a complete development ecosystem, which includes the development tools suite (C/C++ compiler, debugger, state machine verification if used) and other middleware, such as communications stacks, as well as the processor itself. This means that the developer must consider not only which RTOS is right for the application, but also which best suits the device, as well as what development tools will make it simple to incorporate a particular RTOS and middleware selection. Additionally for a more complex application it will be necessary to work out how best to debug it when running under an RTOS.

Choosing a pre-integrated solution, with development tools optimised for both the microcontroller and the RTOS, with middleware designed to work with it, can provide a new user with an easier route than buying the individual components from different vendors.

The order in which tasks are performed and their timing are both determined by the scheduler or dispatcher. There are two types of scheduler: non pre-emptive and pre-emptive. Pre-emptive scheduling is the more sophisticated approach; when an event or Interrupt Service Routine (ISR) makes a higher priority task ready-to-run, the current task is immediately suspended and the higher priority task is given control of the CPU. Most real-time systems use pre-emptive schedulers because they are more responsive than non pre-emptive kernels.

Some companies use an in-house RTOS, but as well as consuming time that is better spent on developing the product, this approach can suffer due to the lack of both documentation and extensive testing. A proprietary RTOS is generally not portable to different CPUs, and code is rarely compatible. Additionally if the designer who created it leaves the company it may become impossible to support.

Open market

Assuming one has decided against writing one’s own RTOS, the choice is then between an open source or commercialised open source RTOS, or a fully commercial one which may be used in hundreds or even thousands of designs and based on proven code, thus giving confidence in its integrity.

Having decided on a RTOS, the next step is evaluation of the needs of the particular project. It is necessary for the developer to identify the individual components that will be required (build tools, RTOS, communication stacks). It is best to attempt to source a complete offering, rather than buying bits and pieces.

Evaluation is made much easier if a starter kit (STK), an Integrated Development Environment (IDE) and some debug task aware tools are used. It is worth beginning with sample projects and board support packages (BSP) supplied with the product for the specific target device in order to become rapidly acquainted with the product. RTOS support provision can also be tested out at this stage. Next comes implementation, again best achieved using the sample projects and BSP supplied with the product as a starting point.

The BSP should provide all the hardware specific drivers and routines that are needed to run the application on your target hardware. Task oriented design can then take place.

RTOS (kernel) awareness can be a great help while debugging the application and with a zero compile time configuration, the system is configurable only at run-time. A high performance compiler should also include a MISRA C checker.

Open source

Factors that should be considered when selecting an open source solution are many. Scalability — in terms of size or memory footprint — is an important consideration; most RTOSes are scalable, such that only the code required is included in the final memory footprint. Looking for granular scalability in an RTOS is a worthwhile endeavour, as it minimises memory usage.

Often, an application may outgrow the hardware it was originally designed for, as the requirements of the product increase. An RTOS designed to be portable can therefore migrate between processor architectures and between specific target systems. A standard Application Programming Interface (API), like POSIX, is also a major benefit to portability.

Run-time facilities refer to the services of the kernel (i.e. inter-task communication, task synchronisation, interrupts and events handling). Different application systems have different sets of requirements. RTOS comparisons are frequently based on the inclusion or provision of such kernel-level facilities.

The run-time performance of an RTOS is generally governed by the interrupt latency, context switching time and a few other metrics of kernel performance. This consideration is useful if the performance assessment of the application on a given RTOS is to prototype its performance-critical aspects on standard hardware. For embedded systems of course, code density can also become a major selection criterion.

Another, very important factor that should be taken in to consideration is suitability for the application, both in terms of power and resources. This extends to communications stacks (TCP/IP, USB) middleware and other package tools such as a file system and Flash file systems convertor. For graphic rich HMI based projects, availability of high quality rendering software and libraries can make or break a design.

A sufficient set of development tools including debugger, compiler and performance profiler might help in shortening the development and debugging time and improve the reliability of the code. The more tightly these are coupled to the RTOS the easier the development route will be. A comprehensive suite of starter kits and Advanced Development Kits should be available for the chosen MCU architecture to provide everything the developer needs to get started straight out of the box.

Assess the total cost of ownership, including any applicable licence fee, royalties or other payment models, as well as any maintenance subscription that might be incurred. In many cases the inclination may be to go for a ‘free’ RTOS, but when looking at the total cost of ownership license free may not be lower cost in the longer run. The engineer needs to look carefully at their in-house skills and the timescale needs of the project before committing to a system that relies on other users for support.

Future proofing

By way of example, for a project using a Freescale processor it makes sense to consider its MQX operating system; it’s a high quality RTOS that has been in use for 15 years, with excellent support packages producing tight code with low latencies and free integrated communications stacks (TCP/IP and USB). The ‘one stop shop’ approach makes absolute sense in this case. For another project where processors from multiple vendors may be in use, FreeRTOS may be more appealing; the main driver being its coverage of a wide variety of processors, allowing knowledge retention across projects, coupled with good library support and runtime features.

Development with an RTOS is not a problem-free process. Reliability and consistent support from a supplier is a critical factor in ensuring the prompt completion of a project. Supplier longevity thus helps to determine the availability of support.

This is something that may be overlooked if opting for an open source RTOS – although cost savings may be made on the licence fee, the total cost may be high if it takes a lot of the developer’s time to understand, or if consultants have to be employed to get it working properly.

Although using an RTOS for the first time can seem like a major step, the right choice of RTOS can make it reassuringly easy to get started. With a pre-integrated solution, familiar tools, an intuitive starter kit and the right level of high-quality technical support, even an RTOS beginner can reap the benefits and get the best from their system design with a minimum of either risk or hassle.