So which RTOS kernel do you choose? Zheng: "Look for a kernel that provides a board support package (BSP). The BSP sits between the RTOS and the hardware and is not trivial to create."
How hard is it to start from a kernel? Labrosse noted: "Many embedded programmers are reluctant to use a kernel because of the fear that it will add too much complexity to their application. However, it turns out that you only need a handful of services to get your project off the ground with a kernel. For example, with µC/OS-III, you can write a reasonably complex multitasking application using as few as five API functions."
Zheng pointed out that designers also need to think about the real time behaviour of their project. "The usual requirement is how quickly the application needs to complete a particular computation; if you break that down, it will tell you how fast your RTOS needs to respond. Then look for additional functionality; there'll be a display, networking, a file system and so on."
Carbone said some software components, such as file systems, have only 'trivial dependence' on an RTOS. "Others, like networking, have an intimate dependence. If you're designing for portabililty, you'll likely be sacrificing efficient connection in favour of standard interfaces. Standard interfaces, such as BSD sockets, kill performance, unlike native function calls."
Labrosse noted: "A kernel, such as µC/OS-III, provides many useful services to a programmer, such as multitasking, interrupt management, resource management and memory partition management. Most kernels used for embedded systems are 'preemptive', meaning they always execute the most important task that is ready to run. Preemptive kernels are also event driven, which means tasks are designed to wait for events to occur in order to execute."
Zheng believes a microkernel is a more elegant system design. "The microkernel runs by itself," she said. "Anything else is an application and resides in its own address space, with its own scheduling bandwidth, and cannot impact other areas. "You can also add to the system without impacting other aspects. You can add these new pieces without having to reconfigure your original design." She gave a railway application as an example. "A system might just detect the presence of a train and report that back. But if you then wanted to collect speed and direction, that's new functionality and this will need a new software component. How easy will it be to add this? It's a question relevant to the choice of kernel." While there are many real time kernels available, should you consider 'rolling your own'? "Kernels are complex," said Hughes, "and much depends on what you want to achieve. But there are lots of kernels available, with a range of features and platform support. It seems a bit unnecessary to create your own." Carbone agreed: "Kernels are extremely delicate; they're usually the result of a lot of tuning and are efficient and proven as a result. Kernels which achieve optimum performance are complex, but if performance is not critical – but I think it is – then kernels can be pretty simple and home grown 'executives' and 'big loop' schedulers might fall into this category. However, professional RTOSs benefit from billions of uses over many years." Microkernels use the least possible amount of code to implement the RTOS; monolithic kernels see the entire RTOS running in the kernel space. Zheng noted: "Users can choose between a microkernel and a monolithic approach; with monolithic, there will be more work, because what you add may impact the components which are already there." Labrosse continued the theme: "Having a kernel allows you to add other software components, such as a TCP/ IP stack, a USB stack, a file system or a GUI. Some of these software components might be easy to use, but are quite complex to develop. For example, while a TCP/IP stack can consist of more than 100,000 lines of C code, the application programmer needs only to understand and use around 30 API functions. In other words, they are far easier to use than to create." What are the pitfalls? "Always keep in mind your whole system," Hughes counselled, "your design goals and your possible roadmap. Will you need to switch MCU in future? Practically all embedded design is about trade offs and optimisation, so a system level approach with an eye on the future is essential." Zheng focused on security. "We're seeing more awareness of security in embedded devices because they're all connected. When choosing your real time kernel, select one with security capability. A microkernel is more secure than a monolithic one, but users will be looking at additional features." Concluding, Labrosse said: "Real time kernels are not limited to high end 32bit CPUs. A kernel such as µC/OS-III can run comfortably on many 8 and 16bit CPUs, as well as on DSPs." Read all about it The µC/OS-III real time kernel is described in a book called µC/OS-III: the real- time kernel. Seven versions of the book are available – addressing devices from Freescale, Infineon, NXP, Renesas, STMicrolectronics and TI – and each can be downloaded in PDF format free of change from Micrium's website (www.micrium.com). Each book describes what a real time kernel is and what you can do with them. Examples are provided which can be explored using a companion evaluation boards. The source code for µC/OS-III can also be downloaded from the Micrium website.
