Dia 1

1
6LoWPAN The Wireless Embedded Internet Companion
Exercise Slides Zach Shelby, Martti Huttunen
This work is licensed under the Creative Commons
Attribution-Noncommercial-Share Alike 3.0
Unported License. To view a copy of this license,
visit http//creativecommons.org/licenses/by-nc-sa
/3.0/ or send a letter to Creative Commons, 171
Second Street, Suite 300, San Francisco,
California, 94105, USA
Figures on slides with book symbol from 6LoWPAN
The Wireless Embedded Internet, Shelby Bormann,
ISBN 978-0-470-74799-5, (c) 2009 John Wiley
Sons Ltd
2
The Book

• 6LoWPAN The Wireless Embedded Internet
• by Zach Shelby, Carsten Bormann
• Length 254 pages
• Publisher John Wiley Sons
• http//www.6lowpan.net
• Companion web-site with blog, full companion
  course slides and exercises

3
Outline

• Introduction
• Embedded Devices
• Operating Systems
• Embedded Development
• 6LoWPAN Implementation Issues
• Exercise Hardware
• Contiki uIP
• Exercises

4
Introduction
5
Embedded Meets Wireless

• Microcontrollers are everywhere in embedded
  systems
• appliances, watches, toys, cameras, industrial
  control, mobile phones, sensors, cars, automation
• Microcontroller vs. microprocessor market
• 15 x more microcontroller units sold yearly (8
  billion)
• 20 billion vs 43 billion USD market by 2009
• Possibilities of wireless are endless
• 802.15.4 chips to 150 million unit sales by 2009
• Embedded systems have special characteristics
• Academic community very computer science and
  protocol driven, often ignoring
• Physical layer realities
• Embedded system operation
• Real-time capabilities

6
Embedded Devices
7
Device Architecture

• Microcontroller and program code
• Power supply
• Power management
• Renewable energy?
• Memory (RAM, FLASH)
• Sensors
• Actuators
• Communication
• Input/output
• Part of a larger system?

8
Microcontroller

• Main processing units of embedded devices
• Special purpose and highly integrated
• Integrated RAM, ROM, I/O, peripherals
• Extremely good power to performance ratio
• Cheap, typically 0.25 - 10.00 USD
• Executes programs including embedded system
  control, measurement communications
• Usually time-critical requiring guarantees
• Real-time performance a common requirement
• Pre-emptive scheduled tasks
• Queues and semaphores

9
Example MSP430

• Texas Instruments mixed-signal uC
• 16-bit RISC
• ROM 1-60 kB
• RAM Up to 10 kB
• Analogue
• 12 bit ADC DAC
• LCD driver
• Digital
• USART x 2
• DMA controller
• Timers

10
Example Atmel AVR

• Atmel AVR family
• 8-bit RISC
• RAM Up to 4 kB
• ROM Up to 128 kB
• Analogue
• ADC
• PWM
• Digital
• USARTs
• Timers

11
Memory

• Random access memory (RAM)
• Included on-board in microcontrollers
• Often the most valuable resource
• Read-only memory (ROM)
• Usually actually implemented with NOR flash
  memory
• Flash
• Eraseable programmable memory
• Can be read/written in blocks
• Slow during the write process
• Consumes power of course!
• External memory
• External memory supported by some
  microcontrollers
• Serial flash always supported

12
Common Bus Interfaces

• Digital and analogue I/O
• Accessed by port and pin number (e.g. P1.3)
• Some pins are also connected to interrupts
• UART
• Asynchronous serial bus
• After level translation it is an RS232 bus
• Usually kbps up to 1 mbps
• SPI (serial peripheral interface)
• Synchronous serial bus
• Reliable with speeds of several Mbps
• I2C (inter-integrated circuit) bus
• 2-wire bus with data and clock
• Parallel bus
• Implemented with X-bit width
• X-bit address and clock signals

13
Communications

• Embedded devices are autonomous but most often
  part of a larger system
• Thus communications interfaces are very important
  in the embedded world
• Wired interfaces
• Serial RS232, RS485
• LAN Ethernet
• Industrial Modbus, Profibus, Lontalk, CAN
• Wireless interfaces
• Low-power IEEE 802.15.4 (ZigBee, ISA100,
  Wireless HART)
• WLAN WiFi
• WAN GPRS, WiMax

14
Transceivers

• Modern embedded communications chips are
  transceivers they combine half-duplex
  transmission and reception.
• Transceivers integrate varying functionality,
  from a bare analogue interface to the whole
  digital baseband and key MAC functions.

15
Important Characteristics

• Level of digital integration
• Power consumption and efficiency
• Transition speeds and consumption
• Levels of sleep
• Carrier frequency and data rate
• Modulation
• Error coding capabilities
• Noise figure and receiver sensitivity
• Received signal strength indicator (RSSI)
• Support for upper layers
• Data and control interface characteristics

16
Example RFM TR1000

• Proprietary radio at 916 MHz
• OOK and ASK modulation
• 30 kbps (OOK) or 115.2 kbps (ASK) operation
• Signal strength indicator
• Provides bit interface
• Not included
• Synchronization
• Framing
• Encoding
• Decoding

17
Example CC2420

• IEEE 802.15.4 compliant radio
• 2.4 GHz band using DSSS at 250 kbps
• Integrated voltage regulator
• Integrated digital baseband and MAC functions
• Clear channel assessment
• Energy detection (RSSI)
• Synchronization
• Framing
• Encryption/authentication
• Retransmission (CSMA)

18
Example CC2430

• System-on-a-chip solution
• Integrated 8051 microcontroller
• 32 MHz Clock Speed
• ADC, DAC, IOs, 2 UARTs etc.
• 8 kB of RAM, up to 128 kB of ROM
• Integrated IEEE 802.15.4 radio, like the CC2420
• Power consumption 10-12 mA higher than the
  CC2420, coming from the 8051 microcontroller
• Saves cost, only about 1 EUR more expensive than
  the CC2420
• Internal DMA makes radio and UART performance
  better than with a uC CC2420 solution

19
Power Consumption

• Radio power consumption critical to consider
• Power output level
• Limited savings effect
• Optimal power difficult
• Must be considered globally
• Transition times
• Each transition costs
• Power equal to RX mode
• Should be accounted for

20
Power Consumption

• A simple approximation for power consumption
• Time that takes to go from sleep state to awake
  state
• Transmitter setup time, i.e. time it takes for
  the transmitter to be ready
• Time in the Tx state
• Receiver setup time, i.e. time it takes for the
  receiver to be ready
• Time in the Rx state
• Time in the idle state
• Time in the sleep state
• Average number of times per frame that the
  transmitter is used
• Average number of times per frame that the
  receiver is used
• Duration of the time frame
• Power used in the Tx state
• Power used in the Rx state
• Power used in the idle state
• Power used in the sleep state
• Average power used by the transceiver

21
Sensors Actuators

• Sensors measure real-world phenomena and convert
  them to electrical form
• Analogue sensors require an ADC
• Digital sensors use e.g. I2C or SPI interfaces
• Human interface can also be a sensor (button)
• IEEE 1451 standard becoming important
• Defines standard interfaces and
  auto-configuration
• Also some protocol specifications
• Actuators convert an electrical signal to some
  action
• Analogue and digital interfaces both common
• A motor servo is a good example

22
Operating Systems
23
Real-time Operating Systems

• Library vs. operating system
• Operating system manages all resources
• Embedded systems have pre-defined tasks
• Designed to optimize size, cost, efficiency etc.
• Real-time
• Real-time OS provides tools to meet deadlines
• Pre-emptive, queues, semaphores
• Concurrency
• Execution flows (tasks) able to run
  simultaneously
• Threads and processes
• Sockets and APIs

24
Real-time Issues

• Wireless embedded systems usually are real-time
• Watch, robot, building sensor, control node
• A RTOS only facilitates real-time system creation
• Still requires correct software development
• RTOS is not necessarily high performance
• Can meet general system deadlines (soft
  real-time)
• or deterministically (hard real-time)
• Deadlines can be met using
• Specialized pre-emptive scheduling algorithms
• Proper inter-task design communication
• Semaphores and queues to avoid racing

25
Real-time Issues
26
Concurrency

• Concurrency occurs when two or more execution
  flows run simultaneously
• It introduces many problems such as
• Race conditions from shared resources
• Deadlock and starvation
• OS needs to coordinate between tasks
• Data exchange, memory, execution, resources
• There are two main techniques
• Process based
• CPU time split between execution tasks
• Embedded systems typically use lighter threads
• Event based

27
Concurrency

• Process based
• Event based

28
OS Examples

• Example embedded operating systems
• Contiki (www.sics.se/adam/contiki)
• FreeRTOS (www.freertos.org)
• TinyOS (www.tinyos.org)
• and thousands of others...
• For higher powered MCUs (e.g. ARMs)
• VX Works
• Microcontroller Linux (Android, Maemo etc.)
• Windows CE
• Symbian

29
Embedded Development
30
Embedded Development
Objects
Binary
Compiler
Linker
Programmer
Sources
31
Embedded Development

• Software resides in system non-volatile memory
• External or internal flash/eeprom/prom memories
• Modern microcontrollers are capable of writing
  the internal flash memory run-time and often do
  not have an external memory bus
• Development is done outside the system
• Cross-compilers are used to create binary files
• Cross-compiler creates binary files for a
  different architecture than it is running on
• Various commercial and free compilers available
• System is programmed by uploading the binary
• In-system programming tools or external flashers

32
Cross-compiler Environments

• Integrated development environments (IDEs)?
• Commercial compilers are usually of this type
• Usually dependent on a specific OS (Windows)?
• Integrate a text editor, compiler tools and
  project management along with C library
• System programmer tool usually tightly integrated
• Also open-source IDEs available
• Open-source IDEs usually employ plugin
  architecture
• General-purpose extensible environments
• Include scripting tools for running any command
  line tools compilers, linkers, external editors
  and programmers
• Example Eclipse (implemented in Java)

33
Cross-compiler Environments

• Command line utilities
• Separate compiler/linker, editor and project
  management tools, architecture-dependent C
  library
• Project management make
• make is an automated software building tool
• Based on target-dependency-operation style blocks
• Allows use of project templates and separate
  platform build rules by using include files
• Most common way of managing open-source software
  projects
• automake and autoconf tools extend functionality
  to platform-independent software development

34
Cross-compiler Environments

• Command line compilers
• most common is gcc available for a multitude of
  microcontroller and -processor architectures
• sdcc Small Device C Compiler PICs, 8051's etc.
• single-architecture compilers
• System programming tools
• usually specific to a single microcontroller
  family
• vary greatly in their ease of use and interface
  type
• most require some sort of programming cable or a
  programmer device to upload software
• dependent on the microcontroller programming
  algorithm
• standard buses (SPI, UART, JTAG) vs. proprietary
  buses

35
Cross-compiler Environments

• Command-line tools vs. (commercial) IDEs
• IDEs are easily accessible single installer,
  single GUI
• Commercial IDEs vary greatly in usability,
  standards compliance and are (usually) tied to a
  single architecture -gt bad portability
• Most commercial IDEs don't really support
  templates
• Programmer must go through various dialogs to
  create a new project
• Often project files can not just be copied
  (contain directory paths and such) and may be
  binary format
• Command line tools have a steeper learning curve
• Once learned, applicable to most architectures
• Higher flexibility and ease of duplicating
  projects

36
Cross-compiler Issues

• Portability
• Header files may not follow standard naming
• Hardware-specific header files might not be
  automatically selected
• Most commercial IDEs use different names for each
  different hardware model -gt difficulties in
  portability
• gcc e.g. uses internal macros for model selection
  -gt easier portability via environment variables,
  no header changes
• Hardware register access and interrupt handlers
• Interrupt handler declaration is
  compiler-dependent
• Declaration format is not standardized
• Can be worked around via macros (in most cases)?
• Some compilers (and C libraries) require I/O
  macros
• gcc ports implement direct register access modes

37
Open-source Tools

• Various text editors available nedit, emacs, vi
  ...
• Project build system make
• Compilers/linkers binutils gcc, sdcc
• binutils as, ld, objcopy, size etc.
• gcc c compiler uses binutils to create binary
  files
• Standard C libraries
• Provide necessary development headers and object
  files for linking and memory mapping
• msp430-libc for MSP430, avr-libc for AVR
• Programmers
• AVR uisp, avrdude
• MSP430 msp430-bsl, msp430-jtag
• CC2430 nano_programmer
• IDE Eclipse

38
SDCC Compiler

• Simple Device C Compiler
• http//www.sdcc.org
• Specialized in 8051, PIC, HC08 etc.
  microcontrollers
• Has CC2430 and CC2510 support
• sdcc application handles both compilation and
  linking
• Uses make build environment
• Compatible with Eclipse
• Support for banking (needed in 8051 with 64k
  ROM)
• Thanks to Peter Kuhar for banking support

39
6LoWPAN Implementation Issues
40
Chip Models

• How to integrate 6LoPWAN into an embedded device?
• Challenges
• Lack of standard interfaces (no USB or PCMCIA)
• No standard operating systems (if any!)
• Power consumption limitations
• Price limitations
• Models for integrating 6LoWPAN include SoC,
  two-chip or network processor
• System-on-a-chip model
• Everything on one chip
• Maximum integration
• Minimum price and size
• - Longer, more difficult development
• - Little if any portability

41
Chip Models

• Two-chip solution
• Separate radio transceiver
• Free choice of uC
• More portability
• - More expensive
• - App integration with stack
• Network processor solution
• Network stack on the radio
• Free choice of uC
• Application independent of
• the stack
• Easy integration
• - More expensive

42
Contiki uIPv6

• Popular embedded OS for small microcontrollers
• MSP430, AVR, PIC, 8051 etc.
• http//www.sics.se/contiki
• Standard C-based
• Portable applications
• Lightweight protothreads
• uIPv6 Stack
• Full IPv6 support
• RFC4944 6lowpan-hc
• UDP, TCP, ICMPv6
• Great for research

43
NanoStack 2.0

• Sensinodes commercial 6LoWPAN stack
• Network processor model
• NAP interface over UART
• Optimized for SoC radios
• TI CC2430, CC2530
• TI CC1110
• Portable
• IPv6/6LoWPAN stack
• UDP, ICMPv6
• RFC4944, 6lowpan-hc
• 6lowpan-nd
• NanoMesh IP routing

44
Router Integration

• Edge Routers interconnect the
• IPv6 world and 6LoWPAN
• An ER needs to implement
• 6LoWPAN interface(s)
• 6LoWPAN adaptation
• Simple 6LoWPAN-ND
• A full IPv6 protocol stack
• Other typical features include
• IPv4 support and tunneling
• Application proxy techniques
• Extended LoWPAN support
• A firewall
• Management

45
Example Exercise Hardware
46
Exercise Hardware

• NanoRouter USB 2.4GHz
• Serial USB device
• NanoStack 2.0
• High-power amplifier
• NanoSensor 2.4GHz
• Demo sensor node
• Rechargeable batteries
• 3-axis accelerometer
• Light sensor
• D-connector for external sensors
• Support for either NanoStack or Contiki

47
NanoSensor D-connector

• Standard 9-pin D-connector for sensor expansion
• D-connector pin-out
• 1 3.3V in/out
• 2 Digital I/O or programmer connection
• 3 Analog switch control. 1external I/O in use
• 4 Reset
• 5 Ground
• 6 A/D (Digital I/O). P0_0
• 7 Digital I/O (P2_1) or programming connection
• 8 UART out (from RC module)
• 9 UART in (to RC module)

48
Contiki
49
What is Contiki?

• Contiki is an open-source operating
  system/protocol stack for embedded systems
• Highly portable and reasonably compact
• Protocol stack configuration customizable
• Originally created by Adam Dunkels, developer of
  the uIP stack
• http//www.sics.se/contiki

50
Contiki processes

• Contiki core is event-driven
• Interrupts and HW drivers generate events
• Events are dispatched to event handlers by the
  Contiki core
• Event handlers must return control to core as
  soon as possible
• Co-operative multitasking
• Basic processes are implemented using
  protothreads
• Easier to create sequential operations
• An abstraction to avoid complex state-machine
  programming
• In more complex applications, the amount of
  states may be huge

51
Contiki execution models

• Contiki offers multiple execution models
• Protothreads thread-like event handlers
• Allow thread-like structures without the
  requirement of additional stacks
• Limits process structure no switch/case
  structures allowed
• May not use local variables
• Multi-threading model available
• For more powerful systems
• Allows structured application design

52
Contiki processes

• Contiki core is event-driven
• Interrupts and HW drivers generate events
• Events are dispatched to event handlers by the
  Contiki core
• Event handlers must return control to core as
  soon as possible
• Co-operative multitasking
• Basic processes are implemented using
  protothreads
• Easier to create sequential operations
• An abstraction to avoid complex state-machine
  programming
• In more complex applications, the amount of
  states may be huge

53
Contiki processes An example

• / Declare the process /
• PROCESS(hello_world_process, Hello world)
• / Make the process start when the module is
  loaded /
• AUTOSTART_PROCESSES(hello_world_process)
• / Define the process code /
• PROCESS_THREAD(hello_world_process, ev, data)
• PROCESS_BEGIN() / Must always come
  first /
• printf(Hello, world!\n) / Initialization
  code goes here /
• while(1) / Loop for ever /
• PROCESS_WAIT_EVENT() / Wait for
  something to happen /
• PROCESS_END() / Must always come
  last /

54
Contiki processes Notes

• A process may not use switch-case constructs
• A limitation of the protothread model
• Complex state structures and switches should be
  subroutines
• A process may not declare local variables
• Variables will lose their values at any event
  waiting call
• All variables required by the main process must
  be static
• Effects on application design
• The main process thread should only contain
  sequences between event waits
• All operations should be done in subroutines

55
Contiki events

• process_post(process, eventno, evdata)
• Process will be invoked later
• process_post_synch(process, evno, evdata)
• Process will be invoked now
• Must not be called from an interrupt (device
  driver)
• process_poll(process)
• Sends a PROCESS_EVENT_POLL event to the process
• Can be called from an interrupt
• Using events
• PROCESS_THREAD(rf_test_process, ev, data)
• while(1)
• PROCESS_WAIT_EVENT()
• if (ev EVENT_PRINT) printf(s, data)

56
Contiki timers

• Contiki has two main timer types etimer and
  rtimer
• Etimer generates timed events
• Declarations
• static struct etimer et
• In main process
• while(1)
• etimer_set(et, CLOCK_SECOND)
• PROCESS_WAIT_EVENT_UNTIL(etimer_expired(et))
  
• etimer_reset(et)
• Rtimer uses callback function
• Callback executed after specified time
• rtimer_set(rt, time, 0 , callback_function,
  void argument)

57
Contiki Protocol Stacks

• Contiki has 2 different protocol stacks uIP and
  Rime
• uIP provides a full TCP/IP stack
• For interfaces that allow protocol overhead
• Ethernet devices
• Serial line IP
• Includes IPv4 and IPv6/6LoWPAN support
• Rime provides compressed header support
• Application may use MAC layer only
• Protocol stacks may be interconnected
• uIP data can be transmitted over Rime and vice
  versa

58
The Rime protocol stack

• Separate modules for protocol parsing and state
  machines
• Rime contains the protocol operation modules
• Chameleon contains protocol parsing modules
• Rime startup an example
• Configure Rime to use sicslowmac over cc2430 rf
• Startup is done in platform main function
  platform/sensinode/contiki-sensinode-main.c
• rime_init(sicslowmac_init(cc2430_rf_driver))
• set_rime_addr() //this function reads MAC from
  flash and places
• //it to Rime address

59
Rime Receiving

• Setting up Rime receiving broadcast
• Set up a callback function
• Declarations
• static struct broadcast_conn bc
• static const struct broadcast_callbacks
  broadcast_callbacks recv_bc
• The callback definition
• static void
• recv_bc(struct broadcast_conn c, rimeaddr_t
  from)
• In main process
• broadcast_open(bc, 128, broadcast_callbacks)
• Unicast receive in a similar manner

60
Rime Sending

• Sending broadcast data using Rime
• Declarations
• static struct broadcast_conn bc
• In main process
• packetbuf_copyfrom("Hello everyone", 14)
• broadcast_send(bc)
• Sending unicast data using Rime
• Declarations
• static struct unicast_conn uc
• In your function
• rimeaddr_t addr
• addr.u80 first_address_byte
• addr.u81 second_address_byte
• packetbuf_copyfrom("Hello you", 9)
• unicast_send(uc, addr)

61
Creating Contiki Ports

• First step see if your cpu already has code
• If yes, configure your platform to use it
• If not, see other cpu directories for
  implementation models
• Second step see if your hardware is close to
  other platforms
• If yes, copy code from example platform and
  modify
• If not, see other platforms for minimal model
• Create a test application
• Start with LEDs in platform/myplatform/contiki-myp
  latform-main.c
• Use for loops to make sure that your compiler
  works
• Continue by adding printf's to see if your UART
  works
• First real application
• Create an etimer for your test process flash
  LEDs, print info
• Try different timeouts to see if your clocks are
  correct
• Add more drivers and try them out

62
Exercises
63
Contiki Basics

• Create your own Contiki Hello World application
  using /examples/sensinode as an example. Compile
  and run it on the CC2430 target platform
• Create two parallel Contiki processes, each
  controlling a different LED

64
Contiki Advanced

• Use an etimer to set a timer event for your own
  process after a certain period (for example to
  flash a LED).
• Make two processes, and use process events
  between them.
• Make a Contiki application to read the NanoSensor
  accelerometer and light sensors using the ADC on
  the CC2430. Convert the values using the sensor
  data sheets and print them out periodically.
• Make Contiki sensor libraries for the NanoSensor
  buttons and sensors (using code from above) and
  use them to print events.

65
Contiki uIP

• Make an application which uses uIP protosockets,
  and spawns protothreads to handle both UDP and
  TCP sockets.
• Make a client application and a server
  application which communicate between each other
  over UDP.
• Design a publish/subscribe protocol
  implementation over UDP/6LoWPAN using the MQTT-S
  specification (simplified). Implement Publisher,
  Subscriber and Broker applications.
• Use MQTT-S to publish and subscribe to NanoSensor
  buttons and sensor values.