Dia 1 - PowerPoint PPT Presentation

About This Presentation
Title:

Dia 1

Description:

6LoWPAN: The Wireless Embedded Internet Companion Exercise Slides Zach Shelby, Martti Huttunen This work is licensed under the Creative Commons Attribution ... – PowerPoint PPT presentation

Number of Views:123
Avg rating:3.0/5.0
Slides: 66
Provided by: Tero153
Category:
Tags: basics | batteries | dia

less

Transcript and Presenter's Notes

Title: 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.
Write a Comment
User Comments (0)
About PowerShow.com