1 Embedded Development and the SOS Operating System (a users perspective) Naim Busek CENS Systems Lab

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 Particulate Filter Pump Sensor Expel to outside NaOH Reservoir Pump From Soil Screen collection 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 DI-water Reservoir From Soil Screen collection area

Sensing system (pass 2) Tubing with dirty water Large Area Particulate Filter Pump Soil water chamber DI water chamber Membrane Sensor Expel to outside NaOH Reservoir Pump From Soil Pump DI water Reservoir Coupled to ensure precise ratio. De- bubbler Screen Large collection area Valve

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-Amp 1var 1 fixed ADC (8 single 4 diff chan) Ref Volt Extern Pwr Reg Extern Digital Switching

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 You Questions? 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 Developers Simon Han – Ram Kumar Rengaswamy – Roy Shea –