1

Embedded Development and theSOS Operating System

(a users perspective)

Naim BusekCENS Systems Lab

ndbusek@lecs.cs.ucla.edu

Outline

• New directions in sensing methods• Motivation for a new sensing platform• Operating System Selection• SOS Overview• SOS Development• Conclusion• Questions

• JTAG demo/tutorial and question session

Basic sensing system (Contam)

~10

Feet

Sensor

System Details (pass 0)

Tubing with dirty water

ParticulateFilter

Pump

Sensor

Expel to outside

NaOH Reservoir

Pump

From Soil

Scr

eencollection

area

Sample Segregation

Tubing with dirty water

Sensing System (pass 1)

Pump

Soil-water chamber

DI-water chamber

Membrane

Sensor

Expel to outside

Chemical, or Calibration Sample

Reservoir

Pump

Pump

DI-water Reservoir

From SoilS

cree

ncollectionarea

Sensing system (pass 2)

Tubing with dirty waterLarge AreaParticulate

Filter Pump

Soil water chamber

DI water chamber

Membrane

Sensor

Expel to outside

NaOH Reservoir

Pump

From Soil

Pump

DI water Reservoir

Coupled to ensureprecise ratio.

De-bubblerS

cree

nLarge collectionarea

Valve

Val

ve

Pumps and Valves

Instech P625 Peristaltic Pumps(25 mA, 4.5 V) ASCO Solenoid Valve (2.5 W, 6V)

Basic Sensor Boards

• Basic Sensor Board– Light– Temperature– Raw Outputs

• MicaSB– Light– Temperature– Sound– Buzzer– 2D Accelerometer– 2D Magnetometer

Sensor Interface Boards

• MDA300CA– 4 channel input MUX– 8 channel 12 bit ADC – Pulse Counter– 2 relays– EEPROM– Selectable Sensor

Excitation of 2.5, 3, 5V– Temp/Humidity sensor

• I2C slave to system master

Hardware Design Goals

• Precision ADC– 16 bit– 100k sample rate– Max communication speed with controller

• Preamp– Dynamically adjustable to meet sensing needs

• Power supplies for some peripheral components• Digital Control

– GPIO and switches to run sampling sequences• Sampling process compatible with existing computing ability

– Separate micro-controller (not planned but necessary)

Block Diagram

Micro Controller

Pre-Amp1var

1 fixed

ADC(8 single

4 diff chan)

Ref Volt

Extern Pwr RegExtern DigitalSwitching

Sensing Systems

• ProtoSB– 4 channel input MUX– Variable gain amp (1-

128)– 1 basic inst. amp– 4 channel 16 bit ADC– 4 relays– Selectable Sensor

Excitations– Independent

μController

Software Requirements

• Portable to new platform• Meet the demands of the system

– handle sequential timed events– event handlers for failure in sampling procedure– re-define sensing procedure

• Adaptable to new components/sensors• Preferably driver support for peripheral devices• Support from existing user community

Operating System Selections

TinyOS• Compiles components

written in nesC into a static binary image

• Uses external tools such as MOAP or Deluge to load updated images on remote nodes

• Legacy Complexity• Custom toolchain

SOS• Supports dynamic system

updating via. modules• Uses standard C• Use standard development

tools– GDB– Avarice– Avrora

• Tools direct from open sources feeds not custom/hacked software tools

SOS Operating Options

Problem With Sensor Networks

Require uninterrupted operation indefinitely

Post-deployment software updates are common

Customizing the system to the environment

Feature upgrades Bug removal Re-tasking of the system

Re-programming a deployed system is hard

Remote reprogramming is essential for sustainability

The SOS Solution•Remotely insert binary modules into running kernel

• Software reconfiguration without interrupting system operation

• No stop and re-boot unlike differential patching

Superior performance over virtual machines

Basic Services

SOS provides the basic services expected in a sensor operating system

Hardware Abstraction Layer (HAL) Clock, UART, ADC, SPI, etc.

Low layer device drivers interface with HAL

Timer, serial framer, communications stack, etc.

Core kernel services Dynamic memory management Scheduling Function control blocks

Development

• SOS as advertised (with disclaimer)– HAL

• UART• SPI• I2C (multi master)

– Hardware Drivers• Framed UART• Communication Stack

• SOS design assumptions– radio enabled device– Device has LEDs

Things not as Advertised

• SPI driver in SOS (and TinyOS) is not a SPI driver– custom driver for radio– will not work with other SPI devices

• UART framing– had persistent failure modes– did not recover well from corrupted length field

• I2C– multi master not supported– master/slave supported with the ability to switch modes

• Implicit design assumptions– Comm stack required a radio enabled device– Device has LEDs

Helping reality catch up

• Re-implement UART driver– RFC 1662

• PPP in HDLC-like Framing

– Reduced to minimum of state– Fast recovery from packet failure– Arbitrary length packets– Comparable to existing TinyOS implemention

• ~160 cycles/byte vs. ~250 cycles/byte

• UART as comm channel– Enable UART as a target for broadcast communication

SPI and supported devices

• SPI– current driver incompatible with any other

implementation– Bus reservation and release

• Variable Gain amplifier– write command only

• ADC– write command and read back of data– independent clocking for high data rate applications

I2C Drivers

• Rewritten to take make use full use of device hardware support.

• MCU master communicating with slave devices working• Taking • Multi master is tricky to debug

Removing Implicit Assumptions

• Every embedded platform is not a Mica2• Impose clear separation of system components

– System (kernel) components– Micro controller specific components– Platform specific components

• Ensure components are in the correct location• Make it possible to disable all potentially device specific

components• Clear distinction between debugging and system

components– LEDs– UART– GPIO

Making Use of Development Tools

• avr-gdb– malloc– standardized naming scheme

• GDB/Avrice– Debug a running system– Step through error conditions and observe system

response– Save days of development time– Step through interrupt handlers to find system failures

• Avrora– Analyze system performance– Make comparisons to other software

Conclusion

• Increasing complexity of sensing methods necessitates additional control in the sensing system

• The task of sensing systems change over the lifetime of the system and dynamic updating is a necessity

• OS compatibility with standard development tools significantly eases the development process

• As sensing methods increase in complexity sensing node will spend a significant amount of resources handling the sensing process potentially interfering with their functioning.

Thank YouQuestions?

Naim Busek

JTAG Debugging

• Prepare module for testing– CFLAGS=”-g” ./wrap_module.pl uart_speed– make mica2 install ADDRESS=3 PROG=avarice

PORT=/dev/ttyUSB2

• Compile program with “-g” flag– CFLAGS=”-g” make mica2 ADDRESS=5

• Run ice-gdb– AVARICE_ARGS=”-j /dev/ttyUSB2” ice-gdb app.elf

• Enjoy gdb as usual– break i2c.c:293– display/x *(char*)0x800071 (TWSR)

• profiling with avrora– avr-objdump -zhD test_module_app.elf >

test_module_app.od

Acknowledgments

• SOS DevelopersSimon Han – simonhan@cs.ucla.eduRam Kumar Rengaswamy – ram@ee.ucla.eduRoy Shea – roy@cs.ucla.edu