Embedded Operating Systems

Hardware + software = embedded system far outnumber general-purpose computer systems

Constraints Relaxed/Strict Short/Long Lifetime Environmental Conditions Application Characteristics Computation Type Think safety: airplane versus watch Phone power conservation Hot, cold, humid i/o heavy or compute heavy? Discrete vs. continuous

Unique Characteristics Real-time operation Reactive operation Configurability I/O Device Flexibility Streamlined protection mechanisms Direct use of interrupts computation depends on time delivered infrequent external events can be prioritized config... os doesn't have to support all i/o devices special tasks instead of integrating drivers into os little variation/updates to applications; very predictable behaviors

eCos Open source C/C++ also stands for environmental council of the states (unrelated)

eCos breakdown http://ecos.sourceware.org/about.html

eCos breakdown (cont) thread syncing scheduling kernel -> low latency small memory footprint i/o-> can include whichever drivers you need; can write your own stdclib included thread sync-> semaphores, spinlocks, event flags, condition vars, mailboxes bit-mapped scheduler one task per priority (32 of them) multilevel multiple tasks per bit-mapped priority

TinyOS 400 bytes No kernel From Stanford for Wireless Sensor Networks

TinyOS Goals High concurrency Limited resources Adaptive Wide application and platform support Robust simultaneous flow of data, little buffering to limit latency data -> capture, process, stream low power usage, low memory availability "portable across hardware generations" achieved with modularity aspiring for a general-purpose embedded os sensor networks run for months or years unattended

TinyOS Structure Comprises components and modules configuration BlinkAppC { } implementation { components MainC, BlinkC, LedsC; components new TimerMilliC() as Timer0; components new TimerMilliC() as Timer1; components new TimerMilliC() as Timer2; BlinkC -> MainC.Boot; BlinkC.Timer0 -> Timer0; BlinkC.Timer1 -> Timer1; BlinkC.Timer2 -> Timer2; BlinkC.Leds -> LedsC; } Comprises components and modules All have the same structure, written in nesC Atomic tasks Hierarchical layering of components Lower levels accept commands from upper layer Events: indirect/direct hardware interrupts move up the component hierarchy can have user defined components module: implements commands components: hardware or software, handle events task: similar to a thread; atomic -> run to completion caller sends command to a module module runs the request module sends event back to the caller when finished command: non-blocking request

TinyOS Scheduling Designed for uniprocessor systems All tasks run to completion, therefore only need one queue and one stack: no preemption, no time slicing The scheduler module must be included

TinyOS Resource Conventions Dedicated: exclusive access Virtualized: copied instance of dedicated resrc (e.g. clock) Shared: resource sits on an arbiter which provides dedicated resource to a single client at a time (locks the resrc)