Required reading: TinyOS
The paper's argument is that because sensor devices are resource
constrained, and always will be, particular attention should be paid
to the design of the operating system. The resource constraints for a
single sensor are:
There are other constraints such bandwidth consumption etc., but the
design of new network protocols falls outside of the scope of this paper.
- Battery: sensor should be able to run for a long time unattended,
without a power grid.
- Size and cost: sensors should be small and cheap so that they can be
- Robustness: nobody present to reboot the operating system.
How real are these constraints? In ten years does a sensor contain
an ARM processor with 128 Kbytes of RAM running with low power
consumption? Such a hardware environment would be good enough to boot
v6. But, perhaps a sensor that cannot boot v6 might be smaller and
A second argument in the paper is that conventional operating
systems (e.g., v6) are not suitable for sensors, because sensors are
devices that are data-oriented instead of computation-oriented (as
desktops are). Sensors collect data from their enviroment (or other
sensors), do some processing, and forward it. Data comes in from
multiple sources with limited amount of buffering, resulting
potentionally in rapid context switching.
A third argument in the paper is that conventional operating
systems are too complex, and a simple, highly-modular operating system
is needed for sensors. Simple so that the system is robust.
Highly-modular so that the operating system can be configured easily
for different sensors.
Case study: Sensor and TinyOS
- MCU ATMEL x8535 (Figure 1)
- 8-bit architecture with 16-bit addresses
- 4-Mhz clock
- 8 Kbyte of flash (program memory)
- 512 bytes of SRAM (data memory)
- Program counter
- Instruction registers
- 32 8-bit Registers and ALU
- Coprocessor with 2Kbyte flash, 128 bytes of SRAM.
- Serial port
- Light Sensor
- RFM radio
- 19.2 Kbs
- No buffering
- Minimum pulse is 52 usec.
It is important to switch components off to save energy (see Table
- How do you calculate 1uJ for transmitting a single bit? (3V x 12
mA x 52 usec = 1.872uJ, and see footnote).
- How do you get 208 cycles? (52 usec x 4 Mhz)
- How do you get .8uJ? (3V x 5mA x 52usec = 780uJ)
Tiny OS. Consist of a collection of components. Each component has:
- Command handlers: called by high-level components
- Event handlers: called by lower-level components
- frame: storage
- Tasks: to multiplex computation within a component. Tasks are
atomic with respect to other tasks. They run to completion (and
should be nonblocking, etc.), but can be interrupted by events
handlers. Because all tasks run to completion they can share a single stack.
- What is the difference between a task and a thread (as we
discussed it)? (Threads can put themselves to sleep and be resumed
- What is the disadvantage of an architecture that has a thread per
event waiting? (One stack per thread; one stack shared by all tasks,
context switching between threads is more expensive than context
switching between tasks; in later case, no saving and restoring of
- What is the difference between a command handler and an event
handler? (None---just convention?)
- What is the difference between a handler and a task? (Tasks have
their own stack, handlers don't.) The convention is that handlers are
usd to set state within a component, while tasks perform all
computation. Since OS should be able to process many interrupts,
handlers should be short.
- What stack does an event handler run on? (On the stack of the
invoking task, or the interrupt stack)
- What stack does a command handler run on? (On the stack of the
invoking task, or the interrupt stack)
- When an interrupt completes, the task scheduler resumes the
interrupt task; if none; it schedules the next task; if none, it puts
the processor into idle mode
- How do tasks come into existence? They are added to the task
queue by handlers, or by another task.
- How is information between handlers and tasks in a single component
communicated? (store in frame)
- How is information between components communicated? (by calling a
event or command handler, and passing arguments.)
- What is the cost of invoking a handler? (A function call)
- What is the cost of invoking a task? (A function call)
- What is the cost of taking an interrupt? (hardware switch cost plus
a potential task switch, which involves saving and restoring registers
of the current active task.)
An example: the messaging component:
An example application: it collects sensor data (temparature) and
sends it (see figure 3). Here is the calling graph in terms of tasks
and functions. The scheduler calls the tasks. The scheduler runs
after an interrupt or task completes:
- What are the event handlers?
- What are the command handlers?
- Why is there a message task? (To perform the computation
associated with a message (e.g., to initiate a message transmission))
- What is in the internal state? (Whether there is a message in
- app task: send_message
- transmit task: compose packet, tx_packet, tx_byte, set_trans_mode
- encoding task: encode data, tx_bit
- clock interrupt: tx_bit_evt, tx_bit, tx_byte_send, tx_packet_done,
tx_msg_done (if last bit of message)
It is unclear radio generates interrupt when transmission completes
or if clock interrupt checks for transmission completion. It appears
to be the clock because in figure 1 there is no wire for
How is coordination enforced? To first order, the application
programmer is responsible that coordination is correct (in terms of
handlers and tasks not interfering). It appears that the only device
that generates interrupts is the clock, which polls devices. (The RX
wire is there only to put the processor into active mode when it
sleeps and a bit arrives.) The components presumably also perform
coordination: for example, the message component probably doesn't send
another message until the first one has been sent. all works out.
- Table 2: what is data size? What does the number 8 for RADIO_byte
- Figure 3: what is context switch overhead? does it include saving
and restoring of registers? what is software cost for interrupt?
- Figure 4: why is RFM line up longer than application? why does
preparing a message take more than 50usec?
- What do we learn from table 4?