Title: Dia 1
16LoWPAN 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
2The 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
3Outline
- Introduction
- Embedded Devices
- Operating Systems
- Embedded Development
- 6LoWPAN Implementation Issues
- Exercise Hardware
- Contiki uIP
- Exercises
4Introduction
5Embedded 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
6Embedded Devices
7Device Architecture
- Microcontroller and program code
- Power supply
- Power management
- Renewable energy?
- Memory (RAM, FLASH)
- Sensors
- Actuators
- Communication
- Input/output
- Part of a larger system?
8Microcontroller
- 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
9Example 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
10Example Atmel AVR
- Atmel AVR family
- 8-bit RISC
- RAM Up to 4 kB
- ROM Up to 128 kB
- Analogue
- ADC
- PWM
- Digital
- USARTs
- Timers
11Memory
- 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
12Common 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
13Communications
- 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
14Transceivers
- 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.
15Important 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
16Example 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
17Example 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)
18Example 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
19Power 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
20Power 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
21Sensors 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
22Operating Systems
23Real-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
24Real-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
25Real-time Issues
26Concurrency
- 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
27Concurrency
- Process based
- Event based
28OS 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
29Embedded Development
30Embedded Development
Objects
Binary
Compiler
Linker
Programmer
Sources
31Embedded 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
32Cross-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)
33Cross-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
34Cross-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
35Cross-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
36Cross-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
37Open-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
38SDCC 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
396LoWPAN Implementation Issues
40Chip 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
41Chip 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
42Contiki 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
43NanoStack 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
44Router 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
45Example Exercise Hardware
46Exercise 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
47NanoSensor 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)
48Contiki
49What 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
50Contiki 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
51Contiki 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
52Contiki 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
53Contiki 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 /
54Contiki 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
55Contiki 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)
-
56Contiki 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)
57Contiki 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
58The 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
59Rime 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
60Rime 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)
61Creating 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
62Exercises
63Contiki 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
64Contiki 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.
65Contiki 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.