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

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

Using the building blocks described in Part 1 in this series, we are now ready to go on to creating the SynthOS project file, which is a text file defined by the user and has the name project.sop. Each field within the file assumes a default value if you do not specify an explicit value, so you need only specify those fields that are relevant to your application. Each project has its own unique SynthOS project file, an example of which, illustrating all possible fields, is shown below.

# SynthOS Project File
[tool]
version = 1.00

# This is the start of the project section.
[project]
project_name = Project X
target = 68HC05
processor_size = 32
language = C
scheduler = round_robin
contact = Vladimir Nabokov
company = PaleFire Corporation
website = www.palefire.com
email = vlad@palefire.com
# Description of the project. Use a “” to continue on the next line.
description = Mobile Phone Prototype
This is the first version.
I hope you'll like it.
# The compiler directives. These are used to specify DEFINEs and include paths needed by
# your application. Use a “” to continue on the next line.
compiler_directives = -D FOO
-I /usr/local/include
-D DUMMY=5

# The source code files are listed in the source section
[source]
file = ConfirmDialog.c
file = AboutDialog.c
file = ../BigTask.c
file = F:/SynthOS/Code Development/SmallTask.c

# The global interrupt routines are listed in the interrupt_global section

[interrupt_global]
enable = ON
getMask = intGetIntMask
setMask = setIntMask
enableAll = intEnableAll

# Each task has an associated [task] section.
#Task1
[task]
entry = Task1_routine
period = 1 # Used by the Round Robin Scheduler, ignored by the Priority Scheduler
priority = 0 # Used by the Priority Scheduler, ignored for the Round Robin Scheduler
TCBQ_depth = 10
type = call

# Task2
[task]
entry = Task2_routine
period = 3 # Used by the Round Robin Scheduler, ignored by the Priority Scheduler
priority = 2 # Used by the Priority Scheduler, ignored for the Round Robin Scheduler
TCBQ_depth = 3
type = loop

Comments. All characters in a line after a pound character (“#”) are ignored as comments.

Tool selection. The project section is preceded by the statement [tool] as shown in the example below.

# SynthOS Version
[tool]
version = [0-9].[0-9][0-9]

This tool parameter specifies the version of SynthOS that is to be used with this project file. It is specified by the keyword version followed by a version number. This allows users to specify a specific version to use if they do not want to upgrade to a new version in the middle of a project.

Project section
The project section is preceded by [project] as shown in the example below. All of the items in this section define the user’s project.

# This is the start of the project section.
[project]
project_name = Project X
target = 68HC05
language = C
scheduler = round_robin
contact = Vladimir Nabokov
company = PaleFire Corporation
website = www.palefire.com
email = vlad@palefire.com

Project name. This parameter defines the name of the user’s project. This simply becomes a comment in the synthesized code for documentation purposes.

Target. This parameter defines the processor that is to be targeted by SynthOS. This currently becomes a comment in the synthesized code for documentation purposes. In the future it may change the synthesis process to take advantage of processor hardware resources.

Processor size. This parameter defines the bit-size (e.g. 8, 16, 32, 64) of the processor that is to be targeted by SynthOS. This currently becomes a comment in the synthesized code for documentation purposes. In the future it may change the synthesis process to take advantage of processor hardware resources.

Language. This parameter defines the computer programming language of the input source code and output source code. This currently becomes a comment in the synthesized code because C is the only programming language supported.

Scheduler. This parameter defines the task scheduling algorithm used for this project. The supported options are currently round_robin and priority.

Contact. This parameter defines the person responsible for the project. This simply becomes a comment in the synthesized code for documentation purposes.

Company. This parameter defines name of the company that is creating the project. This simply becomes a comment in the synthesized code for documentation purposes.

Email. This parameter defines the email for the person responsible for the project. This simply becomes a comment in the synthesized code for documentation purposes.

Description. This parameter gives a multi-line description of the project. This simply becomes a comment in the synthesized code for documentation purposes.

Compiler directives. This parameter gives a list of any compiler specific directives that need to be used to compile the code that is output from SynthOS. For example: -D DEBUG.

Source section
The source code files are listed in the source section.

[source]
file = ConfirmDialog.c
file = AboutDialog.c
file = ../BigTask.c
file = F:/SynthOS/Code Development/SmallTask.c

File. This parameter lists a source code file used in the system. The file can be listed with an absolute path or a path that is relative to the user’s current working directory.

Global interrupt section
This section defines global interrupt options for the system. This section is determined by lifting the appropriate section for the target processor from the Interrupt Definition File. The user then must fill in the specifics for each setting.

# The global interrupt routines are listed in the interrupt_global section
[interrupt_global]
Enable = ON
getMask = intGetIntMask
setMask = setIntMask
enableAll = intEnableAll

If your system uses interrupts (specified by “enable = ON”) then you must write three routines for your processor and specify them in these fields:

enableAll: a routine that enables all interrupts. This is called by the system only once after all Init tasks have executed. This routine must have this signature: void intEnableAll(void) ;

getMask: a routine that disables all interrupts and returns the previous state of the interrupt system just prior to this call. This routine must have this signature: int intGetIntMask(void) ;

setMask: a routine that restores the interrupt system to the state specified in the parameter. The parameter value is normally the value returned by getIntMask . This routine must have this signature: void setIntMask(int Mask) ;

Task section
Each task in the project must have its own section in the project file.

# Task1
[task]
entry = Task1_routine
period = 1
priority = 1
TCBQ_depth = 10
type = init

# Task2
[task]
entry = Task2_routine
period = 3
priority = 2
TCBQ_depth = 3
type = loop
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 thetask management code result in a single execution of the task. Forexample, a value of 3 means the task executes once every 3 loops. Thisfield is only meaningful when the round robin scheduler has beenspecified and is ignored when the priority scheduler has been specified.

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

TCBQ_depth.
Thisrepresents the maximum number of instances of the task that can beexecuting 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
Asynthesized RTOS creates OS data structures for each task in software,rather than relying on built-in hardware structures for accomplishingsuch things as task switching and memory management. Many high-endprocessors have such built-in hardware to assist the operating systemand can be much faster than software for complex systems operating underworst-case conditions. For many embedded systems operating in normalconditions, the advantages of this hardware can be minimal or disappearaltogether, as described below. Yet the hardware has a cost in terms ofsilicon area (and thus dollar cost) and power consumption, both of whichare reduced using RTOS synthesis.

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

This requiresthe RTOS to be aware of the hardware in order to use it, complicatingthe process of porting it to different processors. With regard to powerconsumption, extra hardware means extra power consumption. TypicalRTOSes also require memory management hardware that is used to protectone task from overwriting data used by another task. Again, this meansmore complex hardware, which translates to difficulty porting the RTOSand still more power consumption.

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

RTOS synthesisoptimizes software task swap space for each individual task and usuallyrequires only a few registers and memory locations to be swapped outcompared to a hardware-assisted task swap that stores every possibleregister because the hardware and the RTOS do not know how much isactually being used by any given task. In most cases, the optimizedsoftware task switching provided by RTOS synthesis will be faster thanhardware-assisted task switching. RTOS synthesis also allows the use of aprocessor that does not have hardware for context swapping, thusconserving power.

The same is true for memory managementhardware. The RTOS synthesis tool can create separate locations inmemory for each task and ensure that there is no overlap by generatingthe C code to ensure this. Thus for most embedded systems, processorswithout memory management hardware can be used, again reducing powerconsumption.

Finally, since RTOS synthesis allows 8-bitprocessors to support an RTOS that could not otherwise do so, designerswill find that many applications can be run on these smaller processorswithout needing larger 16-bit, 32-bit, and 64-bit processors. Tasklatency is still low for these smaller processors because of theoptimizations that the RTOS synthesis tool performs. These smallerprocessors are much less power hungry, resulting in further savings inpower consumption. They are also cheaper. When considering placingprocessors in low-cost consumer devices like light bulbs, every 10 centsaving is significant.

SynthOS at work
SynthOS has beenused to synthesize embedded software for a number of embedded systemsincluding a multitasking webserver, a Lego Mindstorms robot, and aheterogeneous multiprocessing robot arm. The webserver ran on an AlteraCyclone EP1C20 FPGA with an embedded NIOS 32-bit soft processor. Thedevelopment for this very first application of SynthOS took severalweeks, and the resulting RTOS kernel was about 3K bytes. This same codewas re-synthesized and compiled for an 8-bit Cypress PSoC resulting inan RTOS of about 1.2K bytes.

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

The heterogeneousmultiprocessing robot arm was controlled by a Xilinx Virtex II-Pro FPGAcontaining an embedded 32-bit PowerPC hard processor controlling aserial mouse and an embedded 32-bit MicroBlaze soft processorcontrolling a 5-joint robot arm. The resulting RTOS for the PowerPC was1.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 .

Softwaresynthesis allows programs to be written at a much higher level whilehiding the implementation details from the programmer. Softwaresynthesis can perform many kinds of analysis and insert many kinds ofdata structures to allow complex testing and debugging beforecompilation rather than relying on testing at run-time as is requiredfor traditional bring-up of embedded systems. Many embedded systems arebeing forced onto overly complex, power-hungry, expensive processors.

Whileit is never ideal to have too much processing power, too high cost, ortoo high power consumption, this can kill a device intended for theInternet of Things. With the advent of RTOS synthesis, many embeddedsystems can be designed for simple processors, resulting in fasterdevelopment times, better code optimization, easier ability to debug,lower hardware costs, and much less power consumption.

Acknowledgements
Iwould like to thank Igor Serikov of Zeidman Technologies for his helpgetting SynthOS off the ground, for helping debug the demo software, andfor 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 .

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.

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

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.