Copyright © 2006

EEM202A/CSM213A - Fall 2006

Mani Srivastava

UCLA - NESL

mbs@ucla.edu

http://nesl.ee.ucla.edu

Lecture #3: Software Organization for Embedded Systems

2

Reading List for This Lecture

• MANDATORY– J. Hill, R. Szewczyk, A. Woo, S. Hollar, D. Culler, and K. Pister. System architecture directions for network

sensors. ASPLOS 2000.• http://www.tinyos.net/papers/tos.pdf

– Simon Han, Ramkumar Rengaswamy, Roy S Shea, Eddie Kohler, Mani B Srivastava. A Dynamic Operating System for Sensor Nodes. In Proceedings of Mobisys'05, Third International Conference on Mobile Systems, Applications and Services, June 2005.

• http://nesl.ee.ucla.edu/projects/sos/publications/sos_mobisys_05.pdf

– Adam Dunkels, Bjorn Gronvall, Thiemo Voigt. Contiki - a Lightweight and Flexible Operating System for Tiny Networked Sensors. In Proceedings of the First IEEE Workshop on Embedded Networked Sensors 2004 (IEEE EmNetS-I), Tampa, Florida, USA, November 2004.

• http://www.sics.se/~adam/dunkels04contiki.pdf

– Adam Dunkels, Oliver Schmidt, Thiemo Voigt, and Muneeb Ali. Protothreads: Simplifying Event-Driven Programming of Memory-Constrained Embedded Systems. In Proceedings of the Fourth ACM Conference on Embedded Networked Sensor Systems (SenSys 2006), Boulder, Colorado, USA, November 2006.

• http://www.sics.se/~adam/dunkels06protothreads.pdf

• RECOMMENDED– David Gay, Philip Levis, J. Robert von Behren, Matt Welsh, Eric A. Brewer, and David E. Culler. The nesC

language: A holistic approach to networked embedded systems. In Proceedings of PLDI'03, ACM SIGPLAN Conference on Programming Language Design and Implementation, pages 1-11, 2003.

• http://nescc.sourceforge.net/papers/nesc-pldi-2003.pdf

– Melkonian, Michael. Get by without an RTOS. Embedded Systems Programming, September 2000.• http://www.embedded.com/2000/0009/0009feat4.htm

– Bhattacharyya, S.S.; Murthy, P.K.; Lee, E.A. Synthesis of embedded software from synchronous dataflow specifications. Journal of VLSI Signal Processing Systems for Signal, Image, and Video Technology, vol.21, (no.2), Kluwer Academic Publishers, June 1999. p.151-66.

• http://ptolemy.eecs.berkeley.edu/publications/papers/99/synthesis/

3Typical Approaches to Embedded System

Implementation

QuickTime™ and aTIFF (Uncompressed) decompressor

are needed to see this picture.

• Create custom system-on-chip (ASIC, FPGA)– Using “cores” from IP vendors

• Create custom board– Using COTS components

• Create custom system– Using standard chassis (e.g.

cPCI, VME etc.) with single board computers, peripheral cards etc.

• Use standard embedded system platform– Usually targeted at some

application domain• Audio processing, image

processing, sensor networks etc.

QuickTime™ and aTIFF (Uncompressed) decompressor

are needed to see this picture.

QuickTime™ and aTIFF (Uncompressed) decompressor

are needed to see this picture.

QuickTime™ and aTIFF (Uncompressed) decompressor

are needed to see this picture.

QuickTime™ and aTIFF (Uncompressed) decompressor

are needed to see this picture.

QuickTime™ and aTIFF (Uncompressed) decompressor

are needed to see this picture.

4

Typical Software-based Embedded System

5

Spectrum of Platform CapabilitiesC

apabili

tie

s

Size, Power Consumption, Cost

MICA Mote

XYZ

StarGate

QuickTime™ and aTIFF (Uncompressed) decompressorare needed to see this picture.

PASTAQuickTime™ and aTIFF (Uncompressed) decompressorare needed to see this picture.

Telos Mote

•Microprocessor (32b)•Broad Band radio•High performance sensors•Short relative lifetime at continuous operation

•Microcontroller (8 – 16b)•Narrow Band radio•Low bit rate, low performance sensors•Long relative lifetime at continuous operation

QuickTime™ and aTIFF (Uncompressed) decompressor

are needed to see this picture.

iMote2

QuickTime™ and aTIFF (Uncompressed) decompressor

are needed to see this picture.

Gumstix

6

Example of Low-end Processor: Atmel AVR

• 4 or 8 MHz • 8 bit • 128KB Flash • 4KB EEPROM • 4KB SRAM • 133 instructions

– most single cycle • 32 gen. regs • 2 cycle multiplier • 8 channel, 10 bit ADC

– 15 kSamps/smax resolution

7

Example of High-end Processor: XScale

• 7 stage pipeline• 32bit• 32 KB instr/data cache• 2kb mini data cache• 256 Kb SRAM• Support for various

peripherals• CPU freq: 100-600

MHz• Voltage down to 0.85

V• Found in

smartphones, PDAs etc.

8

Comparison: AVR vs. XScale

• XScale– Active: 13 MHz => 44.2 mW; 624 MHz => 925 mW

– Idle: 13 MHz => 8.2 mW; 624 MHz => 260 mW

– Deep sleep: 0.1 mW

• ATmega– Active: 4 MHz => 17 mW

– Idle: 4 MHz => 12mW

– Sleep: 45 uW

9Embedded Software Implementation

Approaches

• Synchronous– single program

• Asynchronous– foreground/background system

– multi-tasking

10

Example

• A process controller with following modules– a clock tick comes every 20 ms when a clock module

must run

– a control module must run every 40 ms

– three modules with soft constraints• operator display update• operator input• management information logs

11

Single Program Approach

while (1) {wait for clock;do clock module;if (time for control) do control;else if (time for display update) do display;else if (time for operator input) do operator input;else if (time for mgmnt. request) do mgmnt. output;

}

• Must have t1 + max(t2, t3, t4, t5) 20 ms• may require splitting tasks… gets complex!

12

Another Example

int main(void) {Init_All();for (;;) {

IO_Scan();IO_ProcessOutputs();KBD_Scan();PRN_Print();LCD_Update();RS232_Receive();RS232_Send();TMR_Process();

}// should never ever get here// can put some error handling here, just in casereturn (0); // will keep most compilers happy

}

13Observations on the Single Program

Approach

• Each function called in the infinite loop represents an independent task • Each of these tasks must return in a reasonable time, no matter what thread of

code is being executed • We have no idea at what frequency our main loop runs.

– In fact, the frequency is not constant and can significantly change with the changes in system status (as we are printing a long document or displaying a large bitmap, for example)

• Mix of periodic and event-driven tasks– Most tasks are event driven

• e.g. IO_ProcessOutputs is an event-driven task• dedicated input event queue associated with them

– e.g. IO_ProcessOutputs receives events from IO_Scan, RS232_Receive, and KBD_Scan when an output needs to be turned on

– Others are periodic• No trigger event, but may have different periods, and may need to change their

period over time

14Observations on the Single Program

Approach (contd.)

• Need some simple means of inter-task communications– e.g. may want to stop scanning the inputs after a particular keypad entry

and restart the scanning after another entry• require a call from a keypad scanner to stop the I/O scanner task

– e.g. may also want to slow down the execution of some tasks depending on the circumstances

• say we detect an avalanche of input state changes, and our RS-232 link can no longer cope with sending all these messages

• like to slow down the I/O scanner task from the RS-232 sending task

• May need to perform a variety of small but important duties– e.g. dim the LCD exactly one minute after the very last key was pressed,

flash a cursor on the LCD at a periodic, fixed and exact frequency. – dedicating a separate task to each of these functions is definitely overkill –

so handled through timers and TMR_Process

15

Foreground/Background Systems

Foreground (interrupt)on interrupt {do clock module; if (time for control) do contro;

}Background

while (1) {if (time for display update) do

display;else if (time for operator input)

do operator;else if (time for mgmnt. request)

do mgmnt.;}

• Decoupling relaxes constraint: t1 + t2 20 ms

16

Multi-tasking Approach

• Single program approach: one “task” (or “thread”)• Foreground/background: two tasks• Generalization: multiple tasks

– also called processes, threads etc.– each task carried out in parallel

• no assumption about # of processors• tasks simultaneously interact with external elements

– monitor sensors, control actuators via DMA, interrupts, I/O etc.

• often illusion of parallelism

– requires• scheduling of these tasks• sharing data between concurrent tasks

17

Task Characteristics

• New instances of tasks may be activated over time– Periodic vs. aperiodic (sporadic) activation– Also called “jobs”

• Tasks may have:– resource requirements– importance levels (priorities or criticalness)– precedence relationships– communication requirements– And, of course, timing constraints!

• specify times at which action is to be performed, and is to be completed • e.g. period of a periodic task• or, deadline of an aperiodic task

• States of a task– Running task: In execution– Ready task: Waiting for CPU

• Maintained in a ready queue

– Blocked task: Waiting for some event or resource– Inactive task: Not active

18

Preemption

• Non-preemptive: task, once started, runs until it ends or has to do some I/O

• Preemptive: a task may be stopped to run another– incurs overhead and implementation complexity– but has better schedulability and easier analysis– with non-preemptive, quite restrictive constraints

• e.g. N tasks, with task j getting ready every Tj, and needs Cj time during interval Tj

then: Tj C1 + C2 + … + CN in the worst casebecause all other tasks may already be readyi.e. period of every thread sum of computation times!

19

How to organize multiple tasks?

• Cyclic executive– Also called: Static table driven scheduling, timeline scheduling– static schedulability analysis– resulting schedule or table used at run time– TDMA-like scheduling

• Event-driven non-preemptive– tasks are represented by functions that are handlers for events– next event processed after function for previous event finishes

• Thread-based– Static vs. dynamic priority– Preemptive vs. non-preemptive– static schedulability analysis– no explicit schedule constructed: at run time tasks are executed

“highest priority first”– Rate monotonic, deadline monotonic, earliest deadline first, least

slack etc.

20

How to schedule multiple tasks? (contd.)

• Dynamic planning-based scheduling– Dynamically arriving tasks– “Admission control”: Schedulability checked at run time for

a dynamically arriving task– On task arrival, before execution begins

• attempt made to create schedule that contains previously admitted tasks and the new arrival

• if attempt fails, alternative actions

– Resulting schedule to decide when to execute• Dynamic best-effort scheduling

– No schedulability checking is done– System tries its best to meet deadlines– Don’t know whether timing constraint is met until the

deadline arrives, or the task finishes

21Performance Characteristics to Evaluate

Scheduling Algorithms

• Static case: off-line schedule that meets all deadlines– secondary metric:

• maximize average earliness• minimize average tardiness

• Dynamic case: no a priori guaranteed that deadline would be met– metric:

• maximize # of arrivals that meet deadline

22Cyclic Executive, or Static Table-driven

Scheduling

• Applicable to tasks that are periodic– Aperiodic tasks can be converted into periodic by using worst case inter-arrival time

• A table is constructed and tasks are dispatched accordingly repeatedly– Feasible schedule exists iff there is a feasible schedule for the LCM of the periods– heuristics such as earliest deadline first, or shortest period first– Implementation: timer with period = schedule length initiates the schedule– Handling deadlines may be difficult

• Another approach: time slices of equal length organized into major and minor cycles– Major cycle = LCM, Minor cycle = HCF– Implementation: timer with period = minor cycle interrupts a scheduler program which

activates the task according to order in major cycle– Sum of executions within a time slice minor cycle– May need to split tasks

• Advantages– Simple to implement– Predictable: sequence of task is always same, not affected by jitter– No context switches

• But had disadvantages– Inflexible, sensitivity to application changes

• Table is completely overhauled when tasks or their characteristics change• Task splitting may change

– Fragile during overload conditions• If a task doesn’t finish on time, both letting it continue or aborting it have problems (disrupts

scheduling vs. inconsistent system state)

23

Mechanics of Cyclic Executive

• Time organized into minor cycles, and a timer triggers a task every minor cycle (frame)

• Non-repeating set of minor cycles comprise a major cycle that repeats continuously• Operations are implemented as procedures, and placed in a pre-defined list covering

every minor cycle• When a minor cycle begins, the timer task calls each procedure in the list• No preemption: long operations must be broken to fit frames• E.g. four functions executing at rates of 50, 25, 12.5, and 6.25 Hz (10, 40, 80, and

160 ms) can be scheduled by a cyclic executive with a frame of 10 ms as below:

24

Priority-based Preemptive Scheduling

• Tasks assigned priorities, statically or dynamically– priority assignments relates to timing constraints– static priority attractive… no recalculation, cheap

• Preemptive, non-preemptive, time-slicing– Preemptive: At any time, task with highest priority runs

• if low priority task is running, and a higher priority task arrives, the former is preempted and the processor is given to the new arrival

– Non-preemptive: Task with highest priority chosen• But current task continues till it finishes or blocks

– Time-slicing: time out• Appropriate assignment of priorities allow this to handle certain types

of real-time cases• Example

– Task1: T1=2, C1=1; Task2: T2=5, C2=2.– Consider: Priority1 > Priority2– Consider: Priority 2 > Priority 1– Which works?

25Some Priority-based Preemptive Scheduling

Approaches

• Rate Montonic algorithm by Liu & Layland• static priorities based on periods

» higher priorities to shorter periods

• optimal among all static priority schemes

• Earliest-deadline First• dynamic priority assignment• closer a task’s deadline, higher is it priority• applicable to both periodic and aperiodic tasks• need to calculate priorities when new tasks arrives

» more expensive in terms of run-time overheads

• Key results on schedulability bounds!

26

Dispatching Cost

• Normally dispatching cost assumed a small constant or is ignored during schedulability analysis

• In reality, quite complicated– preemption, context-switching, readying preempted task

for future resumption

27

Other Scheduling Issues

• Scheduling with fault-tolerance constraints– Example: deadline mechanism to guarantee that a primary task

will make its deadline if there is no failure, and an alternative task (of less precision) will run by its deadline in case of failure

• if no failure, time set aside for alternative task is reused

– Another approach: contingency schedules embedded in primary schedule, and triggered when there is a failure

• Scheduling with resource reclaiming– Variation in tasks’ execution times

• some tasks may finish sooner than expected

– Task dispatcher can reclaim this time and utilize it for other tasks• e.g. non-real-time tasks can be run in idle slots• even better: use it to improve guaranteeability of tasks that have

timing constraints

• Imprecise computations– Basic idea: structure computation such that if more time is given,

the quality of result improves• if less time, then still have a poor quality result instead of nothing

28Implementation in Embedded and Real-time

Operating Systems

• Small, fast, proprietary kernels (commercial, home grown)

• Real-time extensions to commercial OSs• Research OSs• Part of language run-time environments

– Ada

– Java (embedded real-time Java)

• Monolithic kernel vs. Microkernel• Main issues

– Concurrency model: event, thread, scheduling etc.

– Memory model: static vs. dynamic

– Component model, if any

29

Embedded and Real-time OS Standards

• RT-POSIX: main general-purpose OS standard, with real-time extensions– Fixed-priority real-time systems– Four “profiles”: minimal, controller, dedicated, and general-purpose– One of the most successful

• OSEK: automotive industry– Distributed, scalable (8b upwards), static allocation, configuration tools, support for

time-triggered architectures– Set of API integrated with a network management system (VDX)– Extensions of memory protection, I/O interfacing, component-based design

• APEX: avionics systems– Analyzable and certifiable safety critical systems– Memory partitions with temporal isolation and resource quota, cyclic scheduling of

partitions, fixed priority scheduling within partition ITRON: embedded systems

– ITRON: Industrial TRON - The Real-time Operating-sysem Nucleus– Started in Japan in 1980s, still mostly in Japan– Many new versions, e.g. Micro-ITRON 4.0 in 2002– Primarily aimed at small systems (8b to 32b) such as consumer electronics– Standard profile: 16-32b processor, 10-20KB kernel image, whole system linked in

one module, kernel object statically generated, no protection, fixed priority preemptive scheduling

30Comparison of Various RTOS Organizations:

Cyclic Executive

Kernel Mode

Device Drivers

Network Drivers

Hardware

I/O Services

TCP/IP Stack

Application Application Application

31Comparison of Various RTOS Organizations:

Monolithic Kernel

User Mode(protected)

Kernel ModeFilesystems

Device Drivers

Network Drivers

Hardware

I/O Managers Graphics Subsystem

Graphics Drivers Other….

Application Application Application

Hardware Interface Layer

32Comparison of Various RTOS Organizations:

Microkernel

User Mode(protected)

Kernel Mode

Device Drivers

Network Drivers H

ardwareFilesystem

Manager

Graphics Drivers

Application

Application

Application

Filesystem Drivers

Device Manager

Photon

Network Manager

Kernel (tiny)

33

Some Examples

• For tiny systems– TinyOS– SOS– Contiki– NuttOS– ERIKA

• For mid-size systems– µCOS-II– eCos– OSE– Embedded Linuxes: µ Linux– Inferno

• For large-size systems– VxWorks– QNX Neutrino– Real-time Linuxes: RTLinux, RTAI,Linux/RK– Research kernels: SHARK, MARTE

34

Example: µCOS-II

• Portable, ROMable, scalable, preemtpive, multitasking RTOS– Up to 63 statically declared tasks

• Services– Semaphores, event flags, mailboxes, message queues, task

management, fixed-size memory block management, time management

• Source freely available for academic non-commercial usage for many platforms– http://www.ucos-ii.com– Value added products such as GUI, TCP/IP stack etc.– Book “MicroC/OS-II: The Real-Time Kernel” describes the

internals

35

Example: eCos

• Embedded, Configurable OS• Open-source, from RedHat• Designed for devices lower-end than embedded Linux• Several scheduling options

– bit-map scheduler, lottery scheduler, multi-level scheduler• Three-level processing

– Hardware interrupt (ISR), software interrupt (DSR), threads• Inter-thread communication

– Mutex, semaphores, condition variables, flags, message box• Portable

– Hardware Abstraction Layer (HAL)• Based on configurable components

– Package based configuration tool– Kernel size from 32 KB to 32 MB– Implements ITRON standard for embedded systems– OS-neutral POSIX compliant EL/IX API

36

Example: Real-time Linuxes

• Microcontroller (no MMU) OSes:– uClinux - small-footprint Linux (< 512KB kernel) with full TCP/IP

• QoS extensions for desktop:– Linux-SRT and QLinux

• soft real-time kernel extension• target: media applications

• Embedded PC– RTLinux– RTAI – Linux/RK– HardHat Linux from MontaVista– Other approaches:

• Low-latency patch– Adds explicit rescheduling points in kernel code to reduce maximum latency

• Kernel preemptability patch– Removes constraint of single execution flow in kernel– MontaVista: spinlocks, TimeSys: mutexes with priority inheritance

37

RTLinux

• University of New Mexico and FSM Labs, Inc.– http://fsmlabs.com

• Small executive with real-time scheduler– POSIX-compliant simple fixed priority scheduler

• Linux kernel runs in background as lowest priority thread– Linux kernel made completely preemptable– Linux interrupt handler routine and interrupt enabling/disabling macros are modified

• Real-time threads and Linux processes communicate via shared memory and file-like interface• Issues

– Real-time threads run in same address space as Linux kernel– Need to write device-drivers for real-time threads as they cannot use standard Linux device driver mechanisms – No support for resource management– Linux drivers that directly disable interrupts are a problem

38

RTAI (Real Time Application Interface)

• Politecnico di Milano– http://www.aero.polimi.it/rtai/

• Open source project that builds on the original idea of RTLinux, but is considerably enhanced

• Linux kernel modified in interrupt handling and scheduling policies, leading to a combination of– Real-time platform with low latency and high predictability– And, full non real-time Linux with TPC, GUI etc.

• Integrated scheduling of RTAI proper kernel tasks, Linux kernel threads, and User space processes/tasks – Thread protection at the cost of increased latencies using Linux

schedulable objects• Basically, an interrupt dispatcher that traps peripheral interrupts and routes

them to Linux if needed– Uses a HAL (Hardware Abstraction Layer)

• Dynamically extensible, light middleware layer based on remote procedure call allows use of RTAI API in adistributed way

• On top of Adeos nano-kernel to support debuggers, analyzers, and other features

39

Linux/RK

• From CMU, marketed by TimeSys Inc.

• Linux kernel directly modified

– Minimally, with RK layer as a module with call back hooks

• RK = Resource Kernel

– Kernel provides resource reservation directly to user processes

– Specific API to take advantage of reservations and QoS management

– Transparent mechanism to assign reservation to legacy applications

• Resource management

– Reserve represents a share of a resource• CPU time, physical memory pages, network bandwidth, disk bandwidth

– Kernel keeps track of resources and enforces utilization

– Resources may be time multiplexed (temporal resources, e.g. CPU time) or dedicated (spatial resources, e.g. memory pages)

• Time multiplexed resources: (C, D, T) = (processing time, deadline period)

• QoS manager

40

Example: SHARK

• From Scuola Superiore S. Anna, Pisa– http://shark.assup.it

• Dynamically reconfigurable real-time OS for x86• Research kernel meant for development and testing of new algorithms• Generic kernel + scheduling modules + device management

– GK: doesn’t implement any specific scheduling algorithm but provides mechanisms that modules can use to perform scheduling and resource management

• Task Models and Resource Models

– SM: external entities that implement scheduling algorithms and configured at run time using a Model Mapper

– Device management: device driver (hardware dependent) vs. device management (hardware independent device scheduling)

• Scheduling modules can be composed in priority layers to do a multi-level scheduling approach

• GK also has a Job Execution Time (JET) estimator– Monitors time actually consumed by a job– For use for measurement, resource accounting,temporal protection etc.

41

Example: TinyOS

● Not really an operating system in the traditional sense● More like an application specific operating system● Application = Scheduler + Graph of Components● Concurrency Model - Event-driven architecture● Naturally implies a Single shared stack● Programming in NesC, an extension of C

42

Simple Application - Blink LEDS

BlinkM

ClockC

Main

StdControl

LedsClock

LedsC

• Application contains 5 components and 3 interfaces• Two types of components

– Configuration - Component that wires together other components– Module - Components that implement functionality

ComponentsInterfaces

Blink

43

The Complete Picture

BlinkM Component

StdControl

LedsClock

provides

uses

Main Component

usesStdControl

LedsC Component

Ledsprovides

ClockC Component

Clockprovides

module BlinkM {

provides {

interface StdControl; }

uses {

interface Clock;

interface Leds; }

}…

Configuration Main {

uses {

interface StdControl;}

}…

Configuration ClockC {

provides {

interface Clock;}

}…

44

TinyOS Concurrency Model

• Event-driven execution• Two contexts

– Foreground - Commands, Events– Background - Tasks– Background context can be interrupted by foreground

• Revisiting NesC syntax– Interface - Collection of Commands and Events

StdControl.nc

interface StdControl {

command result_t init();

command result_t start();

command result_t stop();

}

Clock.nc

interface Clock {

event result_t fire();

command result_t setRate(char interval, char scale);

}

45

Understanding Blink Execution

Main Component{ call StdControl.init()}

BlinkM ComponentImplementation{ result_t command StdControl.init(){ … call Clock.setRate(…); … } …}

ClockC Component{ …. result_t command Clock.setRate(…){ …. } ….} Timer0 Hardware

ClockC Component{ …. TIMER0_ISR(){ signal Clock.fired(); } ….}

BlinkM ComponentImplementation{ result_t signal Clock.fired(){ … call Leds.display(…); … } …}

46

TASKS

• provide concurrency internal to a component– longer running operations

• are preempted by events• able to perform operations beyond event context• may call commands• may signal events• not preempted by tasks

{...post TskName();...}

task void TskName {...}

47

TinyOS Execution Contexts

• Events generated by interrupts preempt tasks• Tasks do not preempt tasks• Both essential process state transitions

Hardware

Interrupts

eve

nts

commands

Tasks

48

Traditional Systems: Monolithic Binary

• Most systems statically linked at compile-time– Entire system is a

monolithic binary

– Compile-time optimizations, analysis possible

– Makes code smaller

• But: hard to change– Must download

entire system

Adam Dunkels @ EmNets 2004

49

Why software reconfiguration?

• Sensor networks require uninterrupted operation indefinitely

• Post-deployment software updates are common– Customizing the system to the environment

– Feature upgrades

– Bug removal

– Re-tasking of the system

• E.g. sensor networks for environmental observation evolving towards a shared observatory model– NEON initiative in the US

• Re-programming a deployed system is hard• Remote reprogramming is essential for sustainability

50

Reconfiguration OptionsU

pd

ate

Cos

t(T

ran

spor

t +

Sto

rage

)

Flexibility

Lightweight Scripts(VMs - e.g. Matè)

Modular Binary(SOS)

Entire Image(TinyOS)

DifferentialBinary

Patching

51

Architecture Overview

Static Kernel• Hardware abstraction and common

services• Costly to modify after deployment• Data structures to enable module

loading

Dynamic Modules• Drivers, protocols, and applications• Inexpensive to modify after deployment• Position independent

DynamicMemoryDynamicMemory

MessageSchedulerMessage

SchedulerDynamicLinker

DynamicLinker

KernelComponents

SensorManagerSensor

ManagerMessaging

I/OMessaging

I/OSystemTimer

SystemTimer

SOSServices

RadioRadio I2CI2C ADCADC DeviceDrivers

Tree RoutingModule

Tree RoutingModule

Data CollectorApplication

Data CollectorApplication

Photo-sensorModule

Photo-sensorModule

DynamicallyLoaded modules

Static SOS Kernel

52

Other OS for Low-end Sensor Nodes

• Contiki– Event-driven kernel, neat light-weight protothread feature, per-

process optional pre-emptive multithreading, TPC/IP stack, GUI subsystem with VNC support, dynamic loading and unloading of programs, portable (MSP430, AVR, HC12, Z80, 6502, x86…)

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

• Nutt/OS– Used by Btnode– Non-preemptive multithreading, events, periodic and one-shot

timers, dynamic heap memory allocation, inerrupt driven streaming I/O, TCP/IP stack, graphical configurator

– http://www.ethernut.de/en/software.html• Mantis

– Thread-based kernel with subset of POSIX threa API– http://mantis.cs.colorado.edu

53

Contiki Structure

• Programs are loaded on top of kernel (core)

• Kernel– Contains the “main loop” of the system– Calls programs when events occur– Calls programs when no events occur

(polling)

• Application– Init function, called by program loader

• LOADER_INIT_FUNC(function_name, arg);

– Eventhandler, called by kernel• EK_EVENTHANDLER(eventhandler,

ev, data);– Pollhandler, called repetedly by kernel

• EK_POLLHANDLER(pollhandler);

• All communication is made through µIP• Individual programs can be

loaded/unloaded– Core resident in the memory– Programs “know” the kernel and

statically linked against it– Code relocation made by module

loader to exercise flash ROM evenlyAdam Dunkels @ EmNets 2004

54

Contiki: Threads vs. Events

• Concurrency management mechanisms: Events vs threads

– Event-driven (TinyOS, SOS)• Processes do not run without events

• Event occurs: kernel invokes event handler

• Event handler runs to completion (explicit return;)

• Compact, low context switching overhead, fits well for reactive systems

• Not suitable for e.g. long running computations

– Public/private key cryptography

– Multi-threading• Threads blocked, waiting for events

• Kernel unblocks threads when event occurs

• Thread runs until next blocking statement

• Suitable for long running computations

• Requires more resources, e.g. stack

Adam Dunkels @ EmNets 2004

Kernel

Handler

Handler

Handler

Handler

55

Program as a Finite State Machine

Waiting Received

SendingWait for

ACK

Command

No output

Output

Output sent

No ACK received

ACK received

Adam Dunkels 2004

56

Event Driven Code

eventhandler1(event) {switch(event) {case INIT:

initialize();return;

case PACKET_RECEIVED:handle_packet();return;

case EXIT:cleanup();return;

}}

eventhandler2(event) {

switch(event) {

case EVENT1:

if(condition) {

post(EVENT2, self);

}

return;

case EVENT2:

condition = 0;

return;

case EVENT3:

condition = 1;

return;

}

}Adam Dunkels 2004

57

Thread Example

eventhandler(event) {

PT_BEGIN();PT_WAIT_UNTIL(event == PACKET_RECEIVED);send_reply();PT_WAIT_UNTIL(event == PACKET_TRANSMITTED);lock_cache();PT_WAIT_UNTIL(event == PACKET_RECEIVED);if(packet == ACK) release_cache();else post(PACKET_RECEIVED, self);PT_END();

}

Adam Dunkels 2004

58

Event vs. Thread Trade-offs

Event-driven- No wait() statements

- No preemption

- State machines

+ Compact code

+ Locking less of a problem

+ Memory efficient

Multi-threaded+ wait() statements

+ Preemption possible

+ Sequential code flow

- Larger code overhead

- Locking problematic

- Larger memory requirements

Adam Dunkels @ EmNets 2004

59

Contiki Combines the Two

• Contiki: kernel is event-based– Most programs run directly on top of the kernel

• Multi-threading implemented as a library• Threads only used if explicitly needed

– Long running computations, ...• Preemption possible

– Responsive system with running computations

Kernel

Event

Event

Event

Event ThreadThread

Adam Dunkels @ EmNets 2004

60Protothreads in Contiki

(http://www.sics.se/~adam/pt)

• Extremely lightweight, portable, and stackless threads for memory constrained embedded systems– Provide blocking context on top of an event driven system in C

• linear code execution with blocking wait without complex state machine, full multithreading, and stack switching

– Only 2 bytes per protothread and no per-thread stack– Pure C - no machine-specific assembler code– Driven by repeated calls to the function in which pt is running

• restarts where it blocked, and continues till next block or exit

• Features– Runs within a single function and cannot span functions

• can call functions but can’t block inside called functions• potentially blocking functions need to be their own protothreads

– Local (stack, register) variables are not preserved across blocking call– Scheduling is controlled by application calling the function– Can be used without an underlying OS

61

Protothread Example

#include "pt.h”struct pt pt;struct timer timer;int flag;PT_THREAD(example(struct pt *pt)){ PT_BEGIN(pt); while(1) { timer_restart(&timer);

PT_WAIT_UNTIL(pt, timer_expired(&timer)); if(flag) {

timer_restart(&timer); PT_WAIT_UNTIL(pt,!flag || timer_expired(&timer));} else { trigger_event();}

} PT_END(pt);}

Adam Dunkels 2004

62

Protothreads (contd.)

• Similarities:– Asymmetric Co-routines (but, stackless)– Stackless threads in some discrete event simulators– Python generators

• Implementation via Local Continuation– Represents current state of execution at a particular place in the

function• but does not provide call history or local variables

– Set and restore• Approaches

– Assembly code – In C, using switch {} statement in a funny way (Duff’s device)– Using compiler extensions, such as GCC’s label pointers to

implement computed goto

63

The Embedded OS Space…

Simple control loop

Event-driven system

Lightweight multi-threading, preemption

Heavy-weight processes with memory protection

Linux, VxWorks

eCos, OSE, Mantis

TinyOS, SOS

Contiki, NuttOS

Adam Dunkels @ EmNets 2004