Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > Embedded

Utilising ASOS for the Internet of Things (Part 1)

Posted: 15 Jul 2014 ?? ?Print Version ?Bookmark and Share

Keywords:Internet of Things? IoT? RTOS? SynthOS? application specific operating system?

As the Internet grows, it has broadened its reach to include home alarm systems, thermostats, toasters, light bulbs, and other devices that are not normally considered 'intelligent' to create the Internet of Things (IoT). Engineers grapple with creating sustainable electronics while adding ever more functionality to devices that previously never needed them. From an economic point of view, we need to keep these things affordable. From an eco-friendly point of view, we need to keep power consumption down.

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 RTOSCpurchase 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 systemCthe 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.

1???2???3???4?Next Page?Last Page

Article Comments - Utilising ASOS for the Internet of T...
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top