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

Developing ZigBee driver with SynthOS

Posted: 01 Jul 2015 ?? ?Print Version ?Bookmark and Share

Keywords:application specific operating system? ASOS? robot? ZigBee? SynthOS?

This particular autonomous version of the DFRobotShop Rover includes a an add-on Dagu module consisting of a PCB controlled by a mini servo-based pan/tilt system for object tracking, an infrared "compound eye" for distance sensing comprising four infrared LEDs and six infrared sensors, and an ultrasound sensor for distance sensing consisting of dual ultrasonic transducers.

The main control board of the robot uses an Arduino UNO architecture with an Atmel ATmega328p microprocessor. To this platform we added a wireless capability for monitoring and debugging the robot and a wireless adapter to the PC to communicate with the robot. On the robot we used an XBee and an embedded XBee ZB module. On the PC we used an XStick, a USB peripheral adapter from Digi International that provides short-range wireless ZigBee connectivity. The XStick contains an XBee module and plugs into the USB port of a PC.

How does SynthOS work?
Our SynthOS tool allowed us to develop the system while writing it in C. SynthOS defines 5 types of tasks.
???Init Task. Runs once when system is initialized.
???Loop Task. Runs by the RTOS at regular intervals.
???Call Task. Runs when called by another task.

SynthOS uses special statements called "primitives" to describe the OS functionality. When one task needs to call another task or waits for another task to complete, we insert one of the special primitives that is recognised by SynthOS. The SynthOS primitives are:
???SynthOS_call(). Call a task to run concurrently with the current task. This is a non-blocking call.
???SynthOS_check(). Check whether a task is currently running.
???SynthOS_sleep(). Suspend the current task.
???SynthOS_start(). Suspend the current task and start the new task. This is a blocking call.
???SynthOS_wait(). Suspend the current task until a specified task ends or until a specific condition is met.

To define the project and the OS high-level behaviour, we created a simple project file to specify the parameters of each task such as the task's priority and its frequency. SynthOS was then run on all of the system and library source code. SynthOS creates the appropriate semaphores and flags for each task and inserts the appropriate code at the appropriate points in the task code. SynthOS also creates task management code to manage the tasks and their associated flags and semaphoresa micro kernel that we call an application specific operating system (ASOS). A generic diagram of the resulting code is given in figure 4. Note that each task is mostly written by us, but SynthOS inserts the code required by the ASOS into each task, and generates the ASOS that controls execution of each task.

Here is a sample of a section of the project.sop file specifying a Loop Task and the XBee Call Tasks:

# Each task has an associated [task] section.
entry = test
type = loop

entry = xbee_request
type = call

entry = xbee_receive
type = call

Figure 4: SynthOS code generation.

SynthOS has a built-in capability to support drivers for hardware peripherals. Its inherent capability to run multiple tasks in parallel enables a user to build a system that monitors multiple devices and activate the appropriate tasks in response to inputs. SynthOS supports two basic schedulers for the system kernel, round robin and the priority-based, as illustrated in figure 4. The definition of the architecture is static and cannot be changed at runtime, and at this time we can support only one of them and not a combination of them. It is defined using the scheduler directive in the configuration file. SynthOS internal inter-task communication will activate the appropriate task to service the request. In general for embedded systems, interrupt mechanisms are the preferred method for monitoring external sensors and inputs, but a timer interrupt with polling can often be as effective.

The software solution
First we needed to define three required routines to deal with interrupts. In the SynthOS project file (project.sop), we set the following parameters to define the user-created interrupt functions that SynthOS would need to utilise when it synthesised interrupt service routines:

enable = ON
getMask = get_mask
setMask = set_mask
enableAll = enable_ints

Then we added the actual code for the relevant interrupt routines to the application to support the interrupt functionality:

int get_mask (void) {
????int mask = SREG;
????cli ();
????return mask;

void set_mask (int mask) {
????SREG = (uint8_t) mask;

void enable_ints (void) {
????sei ();

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

Article Comments - Developing ZigBee driver with SynthO...
*? 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