Sensor OS

Required reading: TinyOS

Overview

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:

• 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 sprinkled everywhere
• 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 less expensive.

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

Sensor

• 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
  • Decoder
  • 32 8-bit Registers and ALU
• Coprocessor with 2Kbyte flash, 128 bytes of SRAM.
• Serial port
• Light Sensor
• Temp
• LEDs
• RFM radio
  • 19.2 Kbs
  • No buffering
  • Minimum pulse is 52 usec.

It is important to switch components off to save energy (see Table 1).

• 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 later.)
• 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 registers needed.)
• 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:

• 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 progress, etc.)