6lowpan book course exercises (ppt)

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

http://creativecommons.org/licenses/by-nc-sa/3.0/

v4.3.2010 6LoWPAN: The Wireless Embedded Internet, Shelby & Bormann 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

http://www.6lowpan.net/



Outline

• Introduction

• Embedded Devices

• Operating Systems

• Embedded Development• 6LoWPAN Implementation Issues• Exercise Hardware• Contiki & uIP• Exercises



Introduction



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



Embedded Devices



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?



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



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



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

QuickTime™ and aTIFF (Uncompressed) decompressor

are needed to see this picture.



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



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



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



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.



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



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

Sleep Tx Rx

0.7 uA 12 mA 3.8 mA



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)

Sleep Idle Tx Rx

20 uA 426 uA 8.5 – 17.4 mA 18.8 mA



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



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

Output Power (mW)

Power Used (mW)

0.003 15.30 0.032 17.82 0.100 20.16 0.200 22.50 0.316 25.02 0.501 27.36 0.794 29.70 1.000 31.32



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

€

Pavg =1

TFPRxTwk− up + PRx(NTxTTx− up + NRxTRx− up ) + PTxTTx + PRxTRx + PidleTidle + PsleepTsleep{ }

€

Twk− up

€

TTx− up

€

TTx

€

TRx− up

€

TRx

€

Tidle

€

Tsleep

€

NTx

€

NRx

€

TF

€

PTx

€

PRx

€

Pidle

€

Psleep

€

Pavg



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



Operating Systems



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



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



Real-time Issues

Task1

Task2

Task3

T1 T2 TN

T1 T2 TN

Task1

Task2

Task3 time

Task1

Task2

Task3

Lock resource A

Try access resource A

Unlock resource A



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



Concurrency

• Process based

• Event based



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

http://www.freertos.org/



http://www.tinyos.org/





Embedded Development




Compiler Linker ProgrammerSources

Objects Binary




• 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



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)




• 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




• 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




• 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 -> 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



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 -> difficulties in portability

• gcc e.g. uses internal macros for model selection -> 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



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



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



6LoWPAN Implementation Issues



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



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



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

http://www.sics.se/contiki



• Sensinode’s 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

NanoStack 2.0



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



Example Exercise Hardware



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



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. 1=external 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)



Contiki



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

http://www.sics.se/~adam/contiki






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



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



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



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 */

}



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



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 eventsPROCESS_THREAD(rf_test_process, ev, data) { while(1) { PROCESS_WAIT_EVENT(); if (ev == EVENT_PRINT) printf(“%s”, data); }}



Contiki timers

• Contiki has two main timer types; etimer and rtimer

• Etimer: generates timed eventsDeclarations: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);



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



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



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 voidrecv_bc(struct broadcast_conn *c, rimeaddr_t *from);

In main process:broadcast_open(&bc, 128, &broadcast_callbacks);

• Unicast receive in a similar manner



Rime: Sending

• Sending broadcast data using RimeDeclarations:static struct broadcast_conn bc;In main process:packetbuf_copyfrom("Hello everyone", 14);broadcast_send(&bc);

• Sending unicast data using RimeDeclarations:static struct unicast_conn uc;In your function:rimeaddr_t *addr;addr.u8[0] = first_address_byte;addr.u8[1] = second_address_byte;packetbuf_copyfrom("Hello you", 9);unicast_send(&uc, &addr);



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-myplatform-

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



Exercises



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



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.



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.


6lowpan book course exercises (ppt)

Documents

embedded system control

introduction embedded

integrated integrated

memory rom

systems embedded development

embedded systems appliances

wireless microcontrollers

rom integrated ieee