Multitasking in Modern Embedded System Designs

On Feb 9, Electronic Design published an article titled “Multitasking – Essential to Any RTOS” by John Carbone. This article was based on an article published 17 years ago. The processor used in the examples in the original article was a Motorola 68000, and the fact that I am very familiar with the command set for this processor and its predecessor the 6800 shows my age (some people will call it experience). However, on a more serious side, I think that the concepts and the Ideas presented in the article, regarding the use of an RTOS, and moreover a multitasking architecture in the embedded system is even more relevant today.

In this blog, I would like to reflect on some of the comments in the original article, especially as it applies to the application specific operating system (ASOS), generated by our tool SynthOS. When you look at the history of embedded development—at some level it is the same today—the market was divided among the companies making embedded real-time systems without an OS and those relying on a real-time OS. The typical solution of the first group is the “big loop,” which will cycle between tasks that make up the system, and will wait for events and I/O exchange before it moves to the next task. The main benefit of the “big loop” approach is its simplicity, in development and moreover in debugging and maintenance.

On the other side of the spectrum are the companies that use a multi-tasking RTOS. Those systems are designed using a number of tasks for controlling different aspects of the system; those tasks are activated by the scheduler of the RTOS in a very efficient way to maximize the performance. The main system tasks can also spawn other tasks for handling specific “slower” activities. Those tasks will run in parallel as background tasks, with the RTOS scheduling other higher-priority activities, to achieve very high efficiency of the CPU and resource utilization.

When evaluating an RTOS, according to John Carbone’s article, some of the benefits you should look for are responsiveness (definitely compared to the big loop), ease of development, and portability and maintenance. However, at the same time, you should also be careful to look for a number of pitfalls that relate to memory requirement and access, priority, and excessive overhead. When I think of the ASOS in light of those comments, it is interesting to point out that the SynthOS tool can provide all of those benefits while limiting exposure to the pitfalls, with the added benefit of supporting the old “big loop” simplicity.

SynthOS supports two basic architectures for the creation the ASOS. The first architecture is the round robin scheduler. This is in fact the same concept as the “big loop” with the added benefit of a multitasking capability. In this architecture, the system will go through the list of tasks, but those tasks will release the CPU if it is not used, thus enabling the system to increase its efficiency. Those tasks can also spawn ad-hoc tasks for specific operations that will terminate once they complete. The other architecture is the priority scheduler. This is the typical RTOS approach of running tasks based on their priorities, switching between them to get optimal performers out of the system.

When you look at the benefits an RTOS or an ASOS brings to the users, the system generated by SynthOS will provide all of them and more:

  • Responsiveness: the ASOS supports interrupts with almost zero latency. Moreover, the system is a cooperative OS, giving the user complete control over the context switching.
  • Ease of Development: the SynthOS system uses only five primitives to manage the ASOS and the system. SynthOS will generate reliable and commented C code that is bug free (at the OS level).
  • Portability and Maintenance: SynthOS will generate new application C code for you, which is clearly commented, thus effectively supporting any processor with a C compiler.

As for the potential pitfalls, SynthOS will generate very efficient code in terms of memory usage (improvements of up to 30% on ROM and 50% on flash compared to the market-leading RTOS). SynthOS-synthesized code is correct by design, so the likelihood priority-related deadlocks are greatly diminished, and given that the ASOS generated is a cooperative RTOS and not a preemptive one, the overhead in code and CPU time for context switching is minimal.

In summary, I definitely agree with the article’s point that an RTOS today, maybe even more than in the past, is a critical part of a successful embedded system design, especially given the connected world in which we are living and the massive amounts of data being transferred and processed. The level of complexity for embedded systems is only going to grow. SynthOS presents a unique solution that retains the simplicity and ease of use, while at the same time provides some very powerful capabilities that enable the development of even the most complicated and demanding embedded systems.

Jacob Harel
VP of Product Management
Zeidman Technologies