Utilising ASOS for the Internet of Things (Part 1)
One solution is software synthesis that can take software written at a high level of abstraction and create lower-level software code that is optimised for cost and power consumption. The SynthOS tool is one such example and it is now available completely free, for all uses, noncommercial and commercial.
In this article, I discuss the general concepts of real-time operating system (RTOS) synthesis as implemented in SynthOS, and I also give information about how to create C code at a high level for input to SynthOS. Synthesis is the process of taking a high-level description and turning it into a lower-level description that, in the case of software, can be compiled directly. By working at a higher level, the user does not need to be involved with implementation details.
In particular, this article deals with synthesis of an RTOS that is used to control multiple tasks running on an embedded system. We call the resulting synthesised RTOS an application specific operating system or ASOS. In particular, I want to focus on the low power optimisation that can be achieved through RTOS synthesis.
Matching RTOSes to design needs
Before RTOS synthesis, an embedded system designer had two options when it comes to an RTOS–purchase an off-the-shelf system from an RTOS vendor or write a custom one. Writing an RTOS, even a simple scheduler, requires operating system expertise in such things as multi-tasking, mutexes, and interrupt handling.
The designer must be aware of conditions like race conditions, deadlock situations, and priority inversion. Writing and debugging an RTOS requires effort that could be better spent on the core technologies of the embedded system–the proprietary drivers for custom hardware and proprietary algorithms and application tasks running on top of the RTOS.
Using an off-the-shelf RTOS from an RTOS vendor has its advantages, but also its disadvantages. Advantages include the fact that the RTOS is tested and supported by the vendor. Disadvantages include the fact that the system is difficult to debug because much is hidden from the user. It is also requires a large memory since it needs to support all possible users with various kinds of applications, and so it incorporates features that each particular system may not be using.
Although the RTOS is optimised for the particular processor to which it is ported, that is often not the processor that is ideal for the application and is probably not the most low-power processor for the application. This is because RTOS vendors have an interest in porting their RTOS only to high-end processors so that they can charge more for these tools. RTOS vendors, other than the very smallest ones, do not port tools to simple low-power processors. Despite this, systems using 8bit processors are far more abundant than those using 32bit or 64bit processors and the number of these small processor-based systems is growing fast, propelled by the IoT.
Another factor that discourages RTOS vendors from porting their RTOS to smaller processors is that these processors do not have the hardware necessary to assist with task management and task switching. In particular, off-the-shelf RTOSes need a memory manager to keep tasks from interfering with each other.
An off-the-shelf RTOS also relies on context switching hardware in the processor to allow the state of the machine to be swapped out and a new state swapped in during a task switch. Smaller processors do not incorporate these features.
So as an embedded developer you are caught in a dilemma: Writing your own RTOS is complex and time consuming while purchasing an off-the-shelf RTOS can require a processor that is more complex, costly, and power hungry than is otherwise necessary.
The RTOS synthesis solution
RTOS synthesis provides a good way to create an ASOS for these smaller processors even though they lack hardware support for an OS and have limited resources. RTOS synthesis can thought of like a compiler. In the old days, programmers needed to maintain stacks and heaps. Function calls required data to be pushed onto and off of the stack in the correct order or the system would break entirely. And forget about the complexity of trying to maintain a garbage collection mechanism, especially if it needed to be written in assembly language. These skills required a high level of expertise and experience.
|Related Articles||Editor's Choice|