1. Embedded Operating Systems

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

3. 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

4. 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

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

7. eCos breakdown

8. 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

9. TinyOS
400 bytes
No kernel
From Stanford for Wireless Sensor Networks

10. 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

11. 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

12. 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

13. 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)