Embedded Development and the

1
Embedded Development and the SOS Operating
System (a users perspective)
Naim Busek CENS Systems Lab ndbusek_at_lecs.cs.ucla.e
du
2
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

3
Basic sensing system (Contam)
Sensor
10 Feet
4
System Details (pass 0)
From Soil
Sample Segregation
collection area
Pump
Screen
Tubing with dirty water
Particulate Filter
Expel to outside
Sensor
Pump
NaOH Reservoir
5
Sensing System (pass 1)
From Soil
collection area
Pump
Screen
Tubing with dirty water
Membrane
Expel to outside
Soil-water chamber
Sensor
Pump
DI-water chamber
Pump
Chemical, or Calibration Sample Reservoir
DI-water Reservoir
6
Sensing system (pass 2)
Coupled to ensure precise ratio.
From Soil
Large Area Particulate Filter
De- bubbler
Large collection area
Tubing with dirty water
Screen
Pump
Valve
Membrane
Soil water chamber
Expel to outside
Sensor
Pump
DI water chamber
Valve
Pump
NaOH Reservoir
DI water Reservoir
7
Pumps and Valves
Instech P625 Peristaltic Pumps(25 mA, 4.5 V)
ASCO Solenoid Valve (2.5 W, 6V)
8
Basic Sensor Boards

• Basic Sensor Board
• Light
• Temperature
• Raw Outputs
• MicaSB
• Light
• Temperature
• Sound
• Buzzer
• 2D Accelerometer
• 2D Magnetometer

9
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

10
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)

11
Block Diagram
Ref Volt
Micro Controller
Pre-Amp 1var 1 fixed
ADC (8 single 4 diff chan)
Extern Pwr Reg
Extern Digital Switching
12
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

13
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

14
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

15
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

16
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

17
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

18
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

19
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

20
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

21
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

22
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

23
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

24
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.

25

• Thank You
• Questions?
• Naim Busek

26
JTAG Debugging

• Prepare module for testing
• CFLAGS-g ./wrap_module.pl uart_speed
• make mica2 install ADDRESS3 PROGavarice
  PORT/dev/ttyUSB2
• Compile program with -g flag
• CFLAGS-g make mica2 ADDRESS5
• Run ice-gdb
• AVARICE_ARGS-j /dev/ttyUSB2 ice-gdb app.elf
• Enjoy gdb as usual
• break i2c.c293
• display/x (char)0x800071 (TWSR)
• profiling with avrora
• avr-objdump -zhD test_module_app.elf gt
  test_module_app.od

27
Acknowledgments

• SOS Developers
• Simon Han simonhan_at_cs.ucla.edu
• Ram Kumar Rengaswamy ram_at_ee.ucla.edu
• Roy Shea roy_at_cs.ucla.edu