# Deterministic Systems: TinyOS

Alex Egg,

This paper is part three in a study of deterministic operating systems. The previous study focused on a non-RTOS system, Linux, while this part will highlight some of the features of a real RTOS system, tinyos. Click here to read part 2: http://www.eggie5.com/87-deterministic-systems-semaphore

We were able to create a point-to-point network between n tinyos powered mote devices. The message received by a mote is then sent back to the host via serial interface. Each mote can send data over the radio to all the listening motes via the serial-to-radio interface also.

#Introduction
The goal of this lab is to study tinyos as an embedded operating system and build a simple point to point network between two desktop computers.

We created a point to point communication network by using 2 tinyos motes connected to two hosts (PC, Workstations). A message (up to 100 characters) typed at the keyboard of one of the hosts is communicated to the second host over the point to point wireless network between two tinyos nodes. A message typed at the keyboard of one of the hosts is written to the serial port to which telosb mote is attached by either a program you develop or a tool available to you. The telosb connected to the host when it receives a message over serial port should communicate the message to other tinyos motes over the radio interface (simple broadcast message. Upon receiving a message over the radio interface a telosb mote sends the message to the serial port and thus to the host it is connected to. The message received by the host is displayed on the host monitor via serial interface.

#Background (Tinyos)

Tinyos Programs are built out of components. Libraries and components are written in nesC. Applications are too – just additional components composed with the OS components. Each component is specified by an interface that provides “hooks” for wiring components together. Components are statically wired together based on their interfaces which increases runtime efficiency components. A component provides and uses interfaces. A interface defines a logically related set of commands and events. A component does not care if another component is a module or configuration. A component may be composed of other components via configurations.

TinyOS executes only one program consisting of a set of components. Two type threads: Task
and Hardware event handler.

## TOS Active Messages

ActiveMessage is the TOS built-in message protocol. ActiveMessage is “active” because it is a protocal and contains the destination address, group ID, and type. group: group IDs create a virtual network an 8 bit value specified in /apps/Makelocal. The address is a 16-bit value specified by “make” make install. tolosb. ᾿length’ specifies the size of the message .᾿crc῀ is the check sum.

Any messages using the active message apis must fit the above protocol. We were having trouble conforming to this protocol when using hyperterminal over serial (documented in the issues section below).

# Experiment

The application architecture is very simple: a radio component and a serial component. When data is received on serial it is sent over radio. When data is received over radio it is sent to serial. When this is installed on n motes we have a network in which we can transmit out messages.

To send a AM packet:

 call AMRadioSend.send(AM_BROADCAST_ADDR, &serialpkt, sizeof(BlinkToRadioMsg));


To send a serial message:

call UartStream.send(mydata, 28);


You will notice the serial writes do not use the AM packet, this is explored more in the Issues/Workarounds section.

The program works as expected: When a mote is connected to a host over serial, any input that is entered on the terminal is sent over serial to the mote and then it is transmitted over radio. Any other motes running will receive the message and then write it to it’s serial uart stream. A simple way to test this is to connect a mote to 2 different computers with a hyperterminal serial session.

See the full source code here: https://github.com/eggie5/SDSU-COMPE571-FALL13/tree/master/hmwk3

## Issues/Workarounds

The most difficult part of the project was working with the active message serial api. It expects messages in a certain protocol and this wasn’t obvious at first and caused a lot of problems and prevented us from using hyperterminal. The work around I find was to not use the ActiveMessage serial interface and use the native UART interface. The UART interface is lower level and will take a raw byte stream which work out-of-the box.

# Conclusion

In the end we were able to get a bare-bones tinyos program up and running on the mote. Then we were able to progressively enhance it to blink a led and then to receive serial input. Then we were able to enhance the program to transmit and receive over the radio. We then linked it all together to make a full-duplex messaging network between motes. We also had to overcome issues w/ the serial AM packet which we used the UART component instead as a workaround.

Tinyos is a novel embedded os where everything is a callback and timers are precise. It was a slight paradigm shift developing for this platform coming from a non-determinist unix background. However, I can see the use for real-time OSs in critical embedded system where determinism is required.