Why Use an RTOS?

Manuals

White Papers

	Home > Library > White Papers

Why Use an RTOS?

by David Moore, Director of Engineering

An RTOS makes development easier for many projects, and it makes them more expandable, maintainable, portable, and secure.

Multitasking

At the core of an RTOS is a multitasking kernel. Multitasking, alone, is enough reason to use an RTOS in many systems. It allows you to break a complex problem into simpler pieces (tasks) and focus on the development of each rather than on scheduling when things run. It also makes it easier to partition work among members of a team.

Automatic scheduling lifts a huge burden from you. You can write your tasks independently and leave it to the kernel to do the magic that makes them work together. There’s no superloop that degrades as features are added and no need to continually tweak the timing to make important things run and use spare time for background activities. Having a scheduler is especially important when you add complex communication protocols, such as TCP/IP, and when the application is more than trivial.

Often, what starts as a simple idea becomes more complex. Add to this new requests from marketing and customers. Quickly, your simple loop degenerates into spaghetti code that is difficult to modify and expand. With multitasking, new features are easily added as new tasks. The scheduler handles the rest. The kernel gives the application a simple but solid structure to build on.

Although designing a system on an RTOS from the start is best, it is also possible to migrate an existing system to multitasking using an evolutionary approach. This is the topic of our article Evolution Not Revolution! Making the Transition to Multitasking.

Efficiency

A related benefit of multitasking is it allows fuller use of the CPU. Waiting is intrinsic to embedded systems. During waits, the processor can be doing useful work rather than spinning in a loop. The technique used sans multitasking is to insert calls to background operations into these waiting spots within the main code. It is not only difficult to fully utilize the time gaps this way, but also such software is difficult to maintain. As more code is added, timing is altered, so further and repeated adjustment is needed. This can be a perpetual nuisance and produces less than optimal results. It is simpler and better to let an automatic scheduler handle it. All spare time can be utilized, and idle looping is done only when there is nothing to run. Also, idle time is collected into larger chunks, and during these, the processor can be put into a low power state, saving energy. The better efficiency may allow you to use a cheaper processor.

Services

Kernel services are typically provided for intertask communication, event handling, resource management, memory management, messaging, timing, interrupt handling, profiling, and error management. You avoid implementing similar services, so you can focus on application development. Also, well defined interfaces, designed with a great deal of care and fully documented, will not only offer good ways to do things but also lead to consistency in your application design. The kernel has been developed by people who have aptitude and interest in OS design, and the code has been proven in many systems before yours.

Structure

The foregoing features impose a structure on the application. This results in a desirable consistency of design.

It is a common misconception that all RTOSes are alike. In reality, each has been designed with its own principles that make it unique, and these will have a significant impact on the structure of the application. This is particularly true of the RTOS kernel, which is the key differentiator of each RTOS and the foundation upon which everything is built. For example, the smx kernel strives to minimize interrupt latency, so a key part of the design is the LSR. The LSR has a big influence on how interrupt handling is implemented in the application. For more about it, please see our article Link Service Routines. Also, some kernels offer simplistic services, while others’ are sophisticated, and these, too, impact the design of your application. For smx, some examples are messaging, mutexes, and event groups. You can learn more about these from the smx literature and manuals.

Diagnostics

Since an RTOS imposes a uniform system structure, it is possible to introduce sophisticated diagnostic tools, which further reduce development time, such as a kernel-aware debugger plugin, that helps you see overall system operation and internal details in a structured way. Good ones, such as smxAware, have graphical displays of execution timelines, profiling, resource usage, and memory layout, and textual displays of logged events and details of objects that are more informative than debugger watches.

Middleware

An RTOS is more than a kernel; it includes middleware such as file systems, USB, TCP/IP, WiFi, GUI, security options, and bootloader. These modules are already integrated with the kernel and each other and include the drivers for the target hardware.

Portability

A good RTOS abstracts hardware details through a consistent API that defines at least the services it relies on. Therefore, your application will run on any platform the RTOS runs on. This is true of SMX, and its structure makes it easy to build an application for multiple targets from the same codebase.

Security

An RTOS typically offers some security features, such as encryption of data in communication protocols. Also, the widespread testing of RTOS code by many people on many systems assures that the software has relatively few errors, and this offers a smaller attack surface, as the vendors of code analysis tools will tell you.

An RTOS may support the memory protection unit (MPU) of the processor to control access to code, data, and IO. SecureSMX goes beyond this, offering true partition isolation using portals, and with this foundation in place, other limitations can be applied (and enforced), such as runtime limiting, resource control via tokens, and moving ISR code into umode partitions. See our SecureSMX page and eBook there, Achieving Device Security.

Manpower

Adding an RTOS to your project is like adding several highly competent engineers, at a small fraction of the cost. A good RTOS has already solved many hidden problems that are difficult and time-consuming. Using proven solutions reduces risk and gives your team the best chance of success.

Use of an RTOS also gives you access to the expertise of the engineers who developed each module, and they can advise and support you on your project. We, at Micro Digital, view ourselves as more of a development partner than a software vendor.

Conclusion

We have briefly surveyed the main benefits of using an RTOS. The next step is choosing one. Please continue by reading our article How to Pick an RTOS. Also see the smx Datasheet, Special Features, and other documents at www.smxrtos.com/special for information about what makes the smx kernel special vs. others. Security has become especially important, and we have a strong solution for it, so see our SecureSMX page and eBook there.

David Moore
Director of Engineering

back to White Papers page

Home Sitemap Contact