If you’ve decided that your upcoming embedded project can’t afford a real-time operating system (RTOS), maybe you should think again. With an “always-on connectivity” requirement from the Internet of Things (IoT), it’s key for the RTOS to execute communication protocol stack(s). GUI design, a common IoT requirement, and runtime software from third parties typically rely on RTOS services such as processor cycles, memory, peripherals, and interrupts. Even a 32-kbyte, dedicated-purpose device could benefit from an RTOS simply so that it can isolate foreground and background processing into two separate threads. However, misconceptions about an RTOS’ costs—both the purchase price and the memory and processing cycle requirements, learning curve, etc.—can actually hit your project below the belt.

An RTOS requires instruction memory (usually flash) and RAM for its operation. However, a good commercial RTOS requires very little of either— typically around 2 kbytes of instruction area memory and 1 kbyte of RAM. Of course, application needs in these areas also must be met, making it even more beneficial if the RTOS uses small amounts of memory for its operation.

An RTOS requires processing cycles for performing context switches, executing API calls, etc. However, processing cycles are directly related to what the application uses. For example, if an existing polling loop was executed as-is from a single thread in an RTOS, there would be no additional overhead. The polling loop would execute just as before. RTOS processing overhead only happens when RTOS services are used. Without an RTOS, the application is responsible for all required processing, including the cycles used in polling, function calling, and interrupt servicing. Other than the simplest applications, it’s likely that the RTOS cycles will turn out to be fewer than what the application would consume if it had to do all the work.

Minimal learning curve, easier development
While using an RTOS does require some learning, this is proportional to what the application uses. For instance, to place a legacy polling loop inside a single thread requires almost no learning. And with all the pitfalls associated with using a polling loop architecture, the amount of time studying and re-studying the entire firmware’s performance will quickly dwarf any time spent learning how to use an RTOS, especially for a non-author of the original code. In fact, as device functionality increases, an RTOS actually eases development by eliminating the need to fully understand the processing requirements of every firmware component.

With an RTOS, firmware developers can concentrate on their specific piece of the firmware and not have to worry about the processing requirements of the other firmware in the device. Moreover, they have inter-thread communication services (such as messaging and semaphores) that are efficient, consistent, and well defined. And comprehensive commercial RTOSs also integrate an extensive set of middleware that makes it easy to add networking, file systems, USB, and GUIs.

The starting point for most commercial RTOS licenses is on the order of $10,000 for a non-royalty license, with full source code and support. This one-time purchase for a license—which can be used forever—is equivalent to just a month or two of a single embedded firmware developer’s salary. In contrast, free or open source RTOSs typically have little reason to be small, efficient, and easy to use—which often creates even costlier problems.

What else do you get with an RTOS?
Many legacy 8- and 16-bit devices employ a polling-loop software architecture to distribute processing time among its various threads. Although easy to understand and appropriate in simple devices, this approach suffers greatly when used in more complex devices. The worst-case responsiveness is effectively the worst case processing through the polling loop. In contrast, the response time using an RTOS is constant and invisible to the application software.

An RTOS invisibly handles the processor allocation logic to guarantee the real-time performance of a high-priority thread, whether the firmware is 32 kbytes or 1 Mbyte, and regardless of the number of threads. This alone makes it easier to maintain the application and add new features to a device.

Applications that use an RTOS access its service functions through an API that makes the RTOS platform-independent. That makes it easier to switch among virtually any 32-bit processor architecture, since none of the application’s service references have to be changed. This gives developers the benefit of application portability with minimal changes to their code.

Finally, many commercial RTOSs are pre-certified by regulatory authorities, which can speed the system certification process. Without using a pre-certified RTOS, developers must either qualify their own scheduling code, or provide artifacts for the RTOS they’re using—often at a cost or additional time.

---

Bill Lamie is a co-founder and CEO of Express Logic, and is the author of the ThreadX RTOS. Prior to founding Express Logic, Bill was the author of the Nucleus RTOS and co-founder of Accelerated Technology,. Bill has over 20 years of experience in embedded systems development, particularly in the development of RTOSs for embedded applications.