Advertisement

ASOS: A new RTOS paradigm for the Internet of Things – Part 2: Building a project file

Bob Zeidman, Zeidman Technologies

June 29, 2014

Bob Zeidman, Zeidman TechnologiesJune 29, 2014

Entry. This parameter gives the name of the C function that is the entry point for the task.
Period. This parameter tells how many loops of the main polling loop in the task management code result in a single execution of the task. For example, a value of 3 means the task executes once every 3 loops. This field is only meaningful when the round robin scheduler has been specified and is ignored when the priority scheduler has been specified.

Priority. This parameter is a number from 0 to 31 that gives the relative priority of the task with regard to other tasks. A higher number represents a higher priority. This field is only meaningful when the priority scheduler has been specified and is ignored when the round robin scheduler has been specified.

TCBQ_depth.
This represents the maximum number of instances of the task that can be executing simultaneously. This field is only meaningful for Call tasks.

Type. This parameter specifies the task type. The following types are valid: call, init, or loop.

Lowering power with SynthOS task switching
A synthesized RTOS creates OS data structures for each task in software, rather than relying on built-in hardware structures for accomplishing such things as task switching and memory management. Many high-end processors have such built-in hardware to assist the operating system and can be much faster than software for complex systems operating under worst-case conditions. For many embedded systems operating in normal conditions, the advantages of this hardware can be minimal or disappear altogether, as described below. Yet the hardware has a cost in terms of silicon area (and thus dollar cost) and power consumption, both of which are reduced using RTOS synthesis.

Hardware assists on complex processors. Complex processors include large register sets. An off-the-shelf or homegrown RTOS is written without knowledge of how many tasks may be running or how much memory, stack space, or the number of registers each task requires. Therefore, the RTOS must save the entire stack and all registers to memory during a task switch. Then the RTOS must restore the stack and registers required by the next task to run. This is a time-consuming process. To speed it up, most complex processors have specialized hardware to accomplish the task swap.

This requires the RTOS to be aware of the hardware in order to use it, complicating the process of porting it to different processors. With regard to power consumption, extra hardware means extra power consumption. Typical RTOSes also require memory management hardware that is used to protect one task from overwriting data used by another task. Again, this means more complex hardware, which translates to difficulty porting the RTOS and still more power consumption.

Software task switching on simple processors. An RTOS synthesis tool is aware before compile time exactly which tasks will be running on the system and how much memory and how many registers each task will use. The RTOS synthesis tool creates data structures in software for storing task states. Software saving and restoring of task states is generally slower than hardware-assisted context swapping, but most tasks in a typical embedded system use a small number of registers and stack space.

RTOS synthesis optimizes software task swap space for each individual task and usually requires only a few registers and memory locations to be swapped out compared to a hardware-assisted task swap that stores every possible register because the hardware and the RTOS do not know how much is actually being used by any given task. In most cases, the optimized software task switching provided by RTOS synthesis will be faster than hardware-assisted task switching. RTOS synthesis also allows the use of a processor that does not have hardware for context swapping, thus conserving power.

The same is true for memory management hardware. The RTOS synthesis tool can create separate locations in memory for each task and ensure that there is no overlap by generating the C code to ensure this. Thus for most embedded systems, processors without memory management hardware can be used, again reducing power consumption.

Finally, since RTOS synthesis allows 8-bit processors to support an RTOS that could not otherwise do so, designers will find that many applications can be run on these smaller processors without needing larger 16-bit, 32-bit, and 64-bit processors. Task latency is still low for these smaller processors because of the optimizations that the RTOS synthesis tool performs. These smaller processors are much less power hungry, resulting in further savings in power consumption. They are also cheaper. When considering placing processors in low-cost consumer devices like light bulbs, every 10 cent saving is significant.

SynthOS at work
SynthOS has been used to synthesize embedded software for a number of embedded systems including a multitasking webserver, a Lego Mindstorms robot, and a heterogeneous multiprocessing robot arm. The webserver ran on an Altera Cyclone EP1C20 FPGA with an embedded NIOS 32-bit soft processor. The development for this very first application of SynthOS took several weeks, and the resulting RTOS kernel was about 3K bytes. This same code was re-synthesized and compiled for an 8-bit Cypress PSoC resulting in an RTOS of about 1.2K bytes.

The Lego Mindstorms robot is shipped with 26 Kbytes of total memory. The operating system shipped with the robot uses about 22K bytes, leaving the user with only 4K bytes for applications. Many users substitute the widely available brickOS, which uses only about 11K bytes, leaving the user with 15K bytes for applications. SynthOS was synthesized for a Mindstorms robot with the resulting RTOS using only 2K bytes, leaving 24K bytes for user applications. SynthOS increased the user space by a factor of 6 and also supported more tasks and more global variables, allowing much more complexity for the applications.

The heterogeneous multiprocessing robot arm was controlled by a Xilinx Virtex II-Pro FPGA containing an embedded 32-bit PowerPC hard processor controlling a serial mouse and an embedded 32-bit MicroBlaze soft processor controlling a 5-joint robot arm. The resulting RTOS for the PowerPC was 1.2K bytes while the RTOS for the MicroBlaze was less than 900 bytes. The robot arm is shown in Figure 5. Click on the picture to see the arm in action.



Figure 5: Click to view Robot arm demo

The code for this robot demo can be downloaded from the Zeidman Technologies Site.

Software synthesis allows programs to be written at a much higher level while hiding the implementation details from the programmer. Software synthesis can perform many kinds of analysis and insert many kinds of data structures to allow complex testing and debugging before compilation rather than relying on testing at run-time as is required for traditional bring-up of embedded systems. Many embedded systems are being forced onto overly complex, power-hungry, expensive processors.

While it is never ideal to have too much processing power, too high cost, or too high power consumption, this can kill a device intended for the Internet of Things. With the advent of RTOS synthesis, many embedded systems can be designed for simple processors, resulting in faster development times, better code optimization, easier ability to debug, lower hardware costs, and much less power consumption.

Acknowledgements
I would like to thank Igor Serikov of Zeidman Technologies for his help getting SynthOS off the ground, for helping debug the demo software, and for reviewing this article.

Read Part 1: Building blocks

Bob Zeidman is the president and founder of Zeidman Technologies that develops software tools for hardware/software codesign. He is the author of the books Designing with FPGAs and CPLDs, Verilog Designer's Library, Introduction to Verilog, and Just Enough Electronics to Impress Your Friends and Colleagues. Bob holds an MSEE degree from Stanford and a BSEE and BA in physics from Cornell. His e-mail address is bob@zeidman.biz.

References
Michael Barr, Programming Embedded Systems in C and C++, Sebastopol, CA: O’Reilly and Associates, 1999.

Anthony Cataldo, 8-bit MCUs chase high-end features, Embedded.com, Dec 2 2003.

Jack Ganssle and Michael Barr, Embedded Systems Dictionary, San Francisco, CA: CMP Books, 2003.

Isaac Leung, MCUs face price pressures, migration to 32-bit and ARM, Electronics News, April 26, 2013, retrieved May 31, 2014.

Brian Proffitt, How Big The Internet Of Things Could Become, September 30, 2013, retrieved May 31, 2014.

Brian Proffitt, The Internet Of Things In 2014 - Steady As It Goes, December 27, 2013, retrieved May 31, 2014.

Sanjeev Sardana, Is There An App For That? How The 'Internet Of Things' Is Changing The Consumer Device Landscape, Forbes, May 29, 2014, retrieved May 31, 2014.

Bill Wong, Development Tools Move To The Cloud, Electronic Design, , January 24, 2014.

SynthOS Users Guide, Cupertino, CA: Zeidman Technologies, Inc., 2014.

< Previous
Page 2 of 2
Next >

Loading comments...