Operating Systems

Software Operating Systems

The Operating System is the core Software Architecture component that determines how the overall system task execution happens. Over time, a number of Operating System types have been developed. For this post, we will focus on Embedded Software Operating System types. The primary ones are:


  • Round-robin Scheduler
  • Round-robin Scheduler with Interrupts
  • Function Queue Scheduler
  • Real Time Operating SystemRTOS


Round-robin Scheduler

The Loop or Round-Robin Scheduler is a single execution thread that runs repeatedly. Systems that run in loops can be either simple or large, but the key feature is that there are no context switches or background tasks that can alter the flow of execution. As a result, these are best suited to simpler tasks that do not require fast response to external stimuli, or which can focus on that stimuli only. Some DSP systems work this way because the execution time will be exactly known.


An example of a recent project we did that that used a single loop was a protocol converter that read a weigand data stream and passed it off to a main processor using a handshaked bit pipe. This was done because the main processor had a latency conflict and could not guarantee to handle the weigand minimum data pulse width and 2 other time critical communications tasks at the same time. So one System Architecture decision was to separate this into 2 microcontrollers to manage the required response time. A small 8 bit processor (8 pins too) was used to buffer the incoming weigand stream. Each time a new byte was collected it would reflect the first bit to an output and raise a synchronisation pin. The main processor would raise a read pin after collecting the bit and the slave processor would release its synchronisation pin then the main processor would release the read pin. This allowed very fast data transfer to the main processor at a time of the main processors choosing with a simple and deterministic process in the slave processor.


Systems like this are referred to as Asymmetrical Multiprocessing systems.


A Round-robin Scheduler loop processing system looks like this:


Type 1 Loop

Type 1 Loop

Round-robin Scheduler with Interrupts

The Round-robin Scheduler with Interrupts is the most common form of small operating system. It is enormously flexible and provides fast response to external hardware signals with guaranteed internal time management. It is very common to use interrupts for:


  • Time ticks to maintain a precise sense of elapsed time
  • Communications, especially UARTs
  • Specialised output controls such as PWM, motor control and waveform generation
  • ADC collection and digital filtering
  • Input monitoring and debouncing


For small systems up to 10K lines of code this format of operating system is our usual starting point because there is almost nothing it won’t handle if designed correctly.


The primary advantage is guaranteed response for high priority events via Interrupt.


The primary disadvantages are that in a worst case scenario every task could fully execute in the same pass and that care must be taken to manage data that is used by both the main loop and interrupt service routines.


Quite large systems can be handled using this style of Operating System and it is also easy to run in a fully simulate environment without hardware. In 2011 we received the Electronics News Future Award for Industrial Electronics for a capacitor bank power factor correction controller which uses a Round-Robin Scheduler with Interrupts Operating System.


Type 2 Operating System

Operating System – Loop with Interrupts

Function Queue Scheduler

A Function Queue Scheduler is where a list of function pointers is pushed to an execution queue. The Function Queue also contains priority information so that very high priority tasks can be pushed to the front of the queue. The tasks are executed by calling the function pointers. This type of Operating System is best suited to heavily event driven systems. Each time an event occurs the event handler, usually an interrupt, pushes a new task to the Function Queue.


The primary advantage is that only the code required to handle the current events needs to execute whereas in a Round-robin Scheduler all the modules execute at least a minimal set of decisions to determine if there is anything to be done on this pass.


The primary disadvantage is that a very low priority task might never execute if enough high priority tasks are pushed to the queue ahead of it. This is referred to as ‘starving’.


We have used a variant on the Function Queue Scheduler for handling user configured accessories and user selected program tasks. These were managed by building a token queue rather than a function queue and operated like an interpreted language.


This style of Operating System is probably the least well understood and so the least used. The diagram below shows the basic operation ignoring the use of priority to alter the insertion point in the Function Queue.


Function Queue

Function Queue


Real Time Operating System

The Real Time Operating System or RTOS is the “all singing all dancing” Operating System that allows different threads of execution to operating asynchronously and independently. A great benefit of this is that separate modules or even programs can run on the same computer without the writers having to know anything about the other modules. It is the most flexible of the architectures and also the most difficult to predict precise results for any given system. Problems like priority inversion and task interdependency can lead to system lockups so careful design is still required.


Many commercial modules such as TCP/IP communications stacks assume you are running an RTOS.


The RTOS generally requires the most system resources for the operating system itself and most RTOS systems are sold under commercial licenses. Some include run time royalties. Free RTOS is an example of an open source RTOS that is becoming popular because it is free of royalties or annual support subscriptions.


The RTOS is considered the ultimate operating system and for large, complex or distributed team projects and has many advantages. It is also the most complex with the most disadvantages.


Real Time Operating System

RTOS Structure

Most modern general purpose computers and smart hand held devices use an RTOS including Windows, OS X, iOS, Android, Linux, Solaris, UNIX and many other variants. A useful list can be found at Operating System List.


Selecting an Operating System type

So in building a system, it is important to work out the level of complexity and the future expansion expected. We approach this by assuming that it is always best to use the simplest approach that gets the job done. This also eases support and maintenance which are software lifecycle costs often not considered up front but which are affected by you choice of Operating System.


So the process we use is:


  • Analyse the requirements to identify latency and response requirements
  • Look at the processor clock frequency and instruction execution rate
  • What is the simplest approach that can work
  • Does a more complex approach have enough advantages to justify using it
  • Select the Operating System type to use


Although this sounds simple enough, and analysis is not always straight forward and there can be surprises down the track that require the decision to be evaluated again.


Successful Endeavours specialise in Electronics Design and Embedded Software Development. Ray Keefe has developed market leading electronics products in Australia for nearly 30 years. This post is Copyright © 2011 Successful Endeavours Pty Ltd

Green Electronics Strategies – Sleep Saves Energy

How Does Sleep Save Energy?

For this post, we will look specifically at Embedded Software techniques to save power and energy. This is a well known Power Saving Strategy which doesn’t always get the recognition it deserves. It is also something you have to design into the Power Management Plan from the beginning.


For this example, we will use the MSP430 from TI which has some of the best Power Saving and Power Consumption figures in the industry. We have used them to create devices that run from a pair of AAA batteries for 2 years and which have time based control algorithms so that they can’t be used in a purely event driven mode. Here is how it works:

Low Power Sleep Mode

Low Power Sleep Mode

This shows the power consumption versus time. In Low Power Sleep Mode the consumption is close to zero. Almost no power consumed. Then depending on what is happening it wakes up to varying degrees.


Get the best Electronic Sleep

So this is how you take advantage of this:

  • make the time between wake ups as long as possible
  • make the time awake as short as possible
  • only turn on the peripherals needs for a particular wake period

Now if you system only has to wake once every minute then you can get low power operation from a lot of different processors. If it wakes many times a second then you need a processor that gives you lots of ways to reduce power during wake, reduce the time awake, and increase the interval between wakes.


MSP430 Sleep

So back to the MSP430. It has Power Conservation features that allow it to do all three better than most. Here is the list:

  • Digitally Controlled Oscillator DCO allows it to wake and run quickly
  • Can run a Timer from a 32KHz crystal making interval timing very low power
  • Can use the DCO to set the run speed and so shorten the wake time
  • Lot’s of Power Down Modes so you can always find one that suits your application
  • Peripherals can be Shut Down when not in use
  • Can run down to 1.8V – more on that later but it can also help here

Low Power System Architecture

To take advantage of all this, you have to develop the System Architecture so that takes advantage of this. An example from a very long life application we did runs like this:

  • 32Hz Oscillator runs a timer that generates a 1 second wake
  • User input keys set up to wake on change of state from high to low
  • Use DCO at 1MHz to quickly wake, execute & sleep again
  • Use State Machines to allow modules to execute predictably with eratic timing
  • Have early exit tests to prevent unnecessary Code Execution

The result is an application that runs a process with User Interaction, LED Indicators, and a 2 week cycle where the average Power Consumption is 20uA at 2.7V or 54uW. Of this, less than half is the processor executing the software and the single biggest energy use is the intermittently flashed LED Indicators.


Ray Keefe has been developing high quality and market leading electronics products in Australia for nearly 30 years. For more information go to his LinkedIn profile. This post is Copyright © Successful Endeavours Pty Ltd.