TinyOS and nesC III: Using EmTOS

1
TinyOS and nesC III Using EmTOS

• Thanos Stathopoulos
• CS 113
• February 2004

2
Application development on motes

• Previous lectures discussed mote programming in
  detail
• In this lecture we will focus on more complex
  tasks
• Tools for building distributed protocols on motes
• How to integrate a stargate and a mote network

From this
to this
3
How can it be done?

• Use LED debugging
• Possible for up to 2-3 motes (max)
• How many pairs of eyes do we need for a network
  of 50 motes?
• Be smart and use a simulation tool
• TOSSIM
• or, something else (like EmTOS)

Blink
Blink
4
TOSSIM

• TOSSIM is the first TinyOS simulator
• You write the code in nesC then use TOSSIM by
  typing make pc inside the application directory
• A virtual clock simulator
• Has its own notion of time, i.e. not real-time
• Which system that we know is real-time?
• Simulation can be slowed down, paused or sped up
  (assuming the hardware can handle it)
• Single-process, multi-threaded
• Has a few threads (not many) that are responsible
  for the event loop, external messages etc
• TOSSIM simulates all the way down to the hardware
• Bit-level
• Interrupt driven
• One can simulate low-level hardware behavior
  (like UART register interrupts or bit-level
  radios) in TOSSIM

5
Limitations of TOSSIM

• TOSSIM cannot
• Simulate different binaries running on different
  motes
• Remember, TOSSIM is built (together with the
  application) on a single binary when you type
  make pc.
• One CANNOT run CntToLedsAndRfm and RfmToLeds
  in TOSSIM and see how they interact
• Simulate non-mote devices or networks
• Doesnt do stargates, or anything else thats not
  a mote
• So, TOSSIM is good when you want to
• Simulate low level behavior (like a MAC protocol)
• Have fine-grained timing
• Simulate very large number of motes (10.000 or
  so)
• But what about all the other cases ???

6
EmStar vs TOSSIM

• From what we already know, the four main
  differences between EmStar and TOSSIM are
• Emstar is hardware agnostic so it can
  simulate/emulate microservers
• Emstar is a real-time system while TOSSIM uses a
  virtual clock
• Emstar is language-independent (and POSIX
  compliant) while TOSSIM requires code to be
  written in nesC
• Emstar uses multiple processes per node and thus
  can support multiple (and different) applications
  while TOSSIM cannot
• So how can we use the EmStar framework to
  simulate mote networks?

7
How do we do this?

• Lets go back to the TinyOS basics
• The basic unit of computation is a task
• The interface to the hardware is accomplished via
  interrupts
• In general, any component that handles interrupts
  and posts tasks (or provides events from a task
  context) is interfacing the low-level hardware
  functionality with the higher-level system and
  application functionality
• So what we need to do is
• Simulate those components that handle interrupts
  and post tasks (or the hardware itself if
  possible)
• Leave everything else intact so that the same
  application code will work in simulation as well
  as in the real hardware (remember the EmStar
  approach)

8
EmTOS in a nutshell

• Mote side a virtual platform for TinyOS
• Similar to the PC platform (TOSSIM)
• Not a real piece of hardware
• Stub components like TimerM, BradioM etc that
  proxy commands to the PC side and signal events
  for input coming from the PC side
• PC side a library
• Wrapper layer bridges NesC/EmStar through library
  function calls and callbacks
• Uses EmStar devices and glib functionality to
  emulate hardware (e.g.)
• Radio
• Timers

9
EmTOS component interoperation
NesC code No changes to application required
Other components/app
AM
Leds
Timer
NesC/EmStar boundary
EmTOS wrapper layer
EmStar code
Library function call (Control passes from NesC
code to EmStar)
EmStar Framework
Library callback (Control passes from EmStar to
NesC)
Other EmStar devices (EmTOS nodes, microservers
etc)
10
EmTOS Wrapper Library
EmTOS Wrapper Library
Enables NesC applications to provide new EmStar
services
tos/leds
tos/eeprom
tos/tasks
User defined
User defined
EmStatusServer
EmPacketServer
TOS status
Unmodified NesC Application
Wraps an unmodified NesC app into an EmStar
module
SenseToRFM
TimerC
AM
Implements TinyOS API and low-level components
LEDs
EEPROM
UART
ADC
RadioCRCPacket
ClockC
Underlying EmStar Services
By connecting to existing EmStar services
link/mote0
motenic
This fairly small investment of effort -- the
wrapper library and some TinyOS components that
make up a new TinyOS platform -- simultaneously
addresses both goals of heterogeneous simulation
and integration!
Transceiver (Mote)
11
What has EmTOS done for us?

• EmTOS makes TinyOS look like an EmStar module
• Thus EmSim can simulate them like any other
  EmStar node!
• EmSim runs N EmStar nodes in parallel on a
  centralized server
• Simulated microservers run natively (runs real
  code)
• Simulated motes run TinyOS/NesC app in EmTOS
  wrapper

Example ESS
12
Tasks, interrupts and everything the EmTOS
scheduler

• Remember, in TinyOS, interrupts can preempt tasks
• When in the EmTOS environment, we dont have real
  interrupts anymore
• The EmStar radio simulator is packet based no
  need to handle individual bytes
• What all this means to you
• The EmTOS scheduler behaves exactly like the
  TinyOS scheduler
• The scheduler is completely non-preemptive
  nothing can preempt a running task

13
EmTOS scheduler

• You can see some scheduler statistics by catting
  the scheduler status device /dev/tos/status/sched
  uler
• If the scheduler queue overflows, the status
  device will display the address of the task(s)
  that failed to be posted. You can then use gdb to
  find that address in the code and perhaps solve
  the problem
• thanos_at_raven4 cat /dev/tos/status/scheduler
  
• Current Scheduler Status
• Maximum queue length 32
• Current queue length 0
• Highest queue length 1
• Posting failures 0

14
EmTOS components

• Implemented TinyOS components
• Timer Implemented using EmStar timers. Semantics
  are exactly the same as in TinyOS. Timing
  accuracy is 10ms. (Any ideas why?)
• Radio Implemented as a link device client. The
  radio needs to be connected to a link device
  (like the one provided by the EmStar simulator).
• EEPROM Implemented as a big chunk of memory
  (using malloc!)
• Leds Implemented as a status device that shows
  led state (0 is off, 1 is on)
• UART, I2C not implemented (but you probably
  dont need them anyway)

15
EmTOS components

• Provided TinyOS components
• EmPdServer A packet device provider (server)
• EmPdClient A packet device client
• EmLinkServer A link device provider
• EmLinkClient A link device client
• EmStatusServer A status device provider
• The above are TinyOS components written in nesC
  (in part) but they provide or connect to Emstar
  services! Therefore, they can be used to connect
  other applications (e.g. running on a stargate)
  to mote applications
• The server components provide the services
• The client components connect to existing
  services
• All those components provide parameterized
  interfaces, so you can have multiple status
  servers per application/module

16
Providing a link device EmLinkServerI

• 
  
• interface EmLinkServerI
  
• // This command initializes an instantiation of
  the component
• // the name is the link devices name, e.g
  /dev/link/foo
  
• command result_t Init(char name, char
  description,
• int mtu_adjust, int
  fixed_mtu)
• 
  
• / The nomenclature is based on the CLIENT's
  perspective.In other words, ReceiveMsg is a
  command calling it will cause the CLIENT to
  receive said message. And SendMsg is an event
  when it happens, the client has sent us a message
  /
• // We use this command when we want to send a
  message to the PC side
  
• command result_t ReceiveMsg(link_pkt_t msg,
  int16_t data_length)
• // This event gets triggered when the PC side
  has sent us a message
• event link_pkt_t SendMsg(link_pkt_t msg,
  int16_t data_length)
• event void UpdateStatus(link_status_t
  status)
• 
  
• / the link command interface /
  

17
Providing a status device EmStatusServerI

• interface EmStatusServerI
  
• // Init the instance of the component and also
  assign a name to the
• // status device, e.g. /dev/tos/status/foo
  
  
• command result_t Init(char name)
  
• // We call this command when we wish to tell the
  PC side that our status
• // device has new data. If some application had
  opened the status device
• // and was waiting, the PC side will send us an
  event
• 
  
• command void Notify()
  
• 
  
• event void Write(buf_t buf)
• // These events are triggered from the PC side
  based on whether the
• // status device client has opened the device as
  ASCII or binary
• // The status device reply text (or struct) is
  implemented inside those events
  
• event void Printable(buf_t buf)
  

18
The EmStatusServer sequence of events

• Create an instance of the EmStatusServer
  component in your application
• uses
  
• interface EmStatusServerI as EmStatus
  
• Initialize the component and give a name to the
  status device
• call EmStatus.Init(/dev/tos/status/count)
• When something interesting happens, call
  Notify()
• event result_t Timer.fired()
  
• 
  
• counter
  
• // call notify to trigger an update
  
• call EmStatus.Notify()
  
  
  
• return SUCCESS
  

19
EmStatusServer A live example

• Demo time(YAY!)
• Example code found at
• cvs/tos-contrib/EmTos/apps/StatusTest

20
Compiling a TinyOS application for EmTOS

• Read the instructions at http//cvs.cens.ucla.edu
  /emstar/install.html
• Remember to create the symbolic links and set
  BUILD_EMTOS to 1 in Make.conf
• To compile Blink for EmTOS
• cd into cvs/emstar/mote
• Edit the Build file. Look for lines saying build
  tos. E.g.
• build tos
  
• target RfmToLeds tinyos-1.x/apps/RfmToLeds
  
• The build tos easybuild command instructs the
  build system to build for EmTOS. We need to add
  an entry for Blink. What should it look like?
• build tos
  
• target Blink tinyos-1.x/apps/Blink
  
• We then type make in the top-level Emstar
  directory. The new application, called Blink,
  should appear in the cvs/emstar/obj.i686-linux/mo
  te directory

21
EmTOS Running different binaries

• One EmTOS mote running CntToLedsAndRfm
• Another EmTOS mote running RfmToLeds
• Done using EmStar .run and .sim files
• cvs/emstar/mote/testtabs/Cnt.run
• cvs/emstar/mote/testtabs/Rfm.run
• cvs/emstar/mote/testtabs/Rfm.sim
• Visualised with Emview
• Demo time again!!!
• Looks much cooler with a stargate blinking its
  LEDs ?

22
EmTOS modes of operation

• EmTOS has three modes of operation that can help
  you in various stages of designing building and
  debugging your distributed application
• Simulation mode
• Everything runs in a single powerful machine
• The radio channel is simulated
• Emulation mode
• The code still runs in a single powerful machine
• The radio channel is now real and is provided by
  the motenic
• Real mode
• The code runs on real motes and stargates
• Only partial and compressed information is
  provided through the radio channel

23
Different modes at a glanceThe EmStar view of
the world
(Runs at scale of emulation array)
Pure Sim
Deployed
24
Pure Simulation Mode
Simulation Server

• Pure Simulation Mode
• All Application code runs on server
• Maximum Visibility
• Full logs and status
• Minimum Reality
• Modeled mote RF channel / MAC
• Emulated motes timing
• Initial debug and regression testing

Modeled Mote RF Channel

Motes
Microservers
25
Emulation Mode
Simulation Server
Serial MUX
HostMote Serial Protocol

• Emulation Mode
• All Application code runs on server
• Same visibility as simulation
• Real mote RF channel
• Motes run Transceiver packet proxy
• Packet timing

Motes
Microservers
26
Real Mode
Simulation Server
Serial MUX
HostMote Serial Protocol

• Real Mode
• Microserver code runs on server
• Mote code pushed to physical motes
• Full visibility for microservers
• Motes report only partial status info
• Stub applications gateway to tools

Dbg Stub
Dbg Stub
Dbg Stub

Motes
Microservers
27
An important tool the MoteNIC

• The motenic is an important tool that enables
  EmTOS emulation mode
• Also known as Transceiver from the name of the
  mote code
• Code runs on the PC (or stargate) side and the
  mote side
• Both sides are connected with a serial protocol
  called HostMote
• HostMote is a modular protocol with several
  clients
• Conf used to send and get configuration to and
  from the mote
• Data used to send data to and from the mote. The
  motenic is using the data protocol
• Debug used to send unstructured debugging
  information from the mote to the PC
• Remember CompressedBinary? This is where its
  used!
• More information on how to use the debug protocol
  can be found at
• http//lecs.cs.ucla.edu/thanos/hostmote/hmdebug.
  html

HostMote
28
More MoteNic fun

• The MoteNic on the PC side is a Link Provider
• What else is a link provider?
• Applications can use the motenics link device to
  send data
• The data is now sent over the mote radio
• If the application is in fact an EmTOS process,
  then we can have emulated code running on the PC
  (or the stargate) but use the real mote radio for
  communication
• Do you think that this mode makes communication
  faster, slower or as fast as native code running
  on the mote?

29
EmTOS timingDo the differences matter?

• EmTOS cant do precise timing and hardware
  interrupts
• e.g. EmTOS can emulate many network layer
  protocols
• EmTOS cant emulate the TinyOS MAC layer
• Validation is easy using EmTOS and an Emulation
  Array
• Compare runs in Emulation Mode and Real Mode
• Emulation Mode timing, interrupts by EmTOS
• Real Mode timing, interrupts by Mica2s in
  emulation array
• Validation catches design flaws masked by
  emulation mode
• e.g. Early version of ESS
• Interest messages were flooded too quickly
• Emulation delay improved performance
• But still caught pre-deployment!

30
Conclusion

• EmTOS is a simple, powerful technique for
  simulating, emulating, and deploying
  heterogeneous sensor systems
• EmTOS facilitates
• Integration of motes and microservers by enabling
  code to be shared across platforms
• Simulation of heterogeneous systems composed of
  motes and microservers within a single world
  model
• Debugging of large-scale distributed applications
• While EmTOS is not an accurate emulation of a
  Mica2
• Its close enough for development and integration
  of many application- and network-level components

31
The End

• EmTOS interface files
• cvs/tos-contrib/EmTos/apps
• EmTOS example applications
• cvs/tos-contrib/EmTos/apps
• EmTOS PC side library source code (if youre
  feeling bold!)
• cvs/emstar/mote/libmote
• For any questions on how to use EmTOS, bug
  reports or anything else
• thanos_at_cs.ucla.edu