Embedded Operating Systems Embedded Software Design 熊博安國立中正大學資訊工程研究所 pahsiung@cs.ccu.edu.tw Textbook: Programming Embedded Systems in C and C++, Michael Barr, O Reilly 1
Contents History and Purpose A Decent Embedded Operating System Real-Time Characteristics Selection Process 2
History and Purpose Originally, no operating system (OS) Users controlled everything Later, a loose collection of routines (like modern software library) resetting hardware to a known state reading state of inputs changing state of outputs Finally, modern OS set of tasks 3
Tasks Task: a piece of software that can be separated from and run independently of the rest A set of embedded software requirements can be DECOMPOSED into a small number of independent pieces (tasks). Example: Printer-sharing device Task 1: receive data from serial port A Task 2: receive data from serial port B Task 3: format & send waiting data to printer 4
Tasks Software abstraction Software design easier Software implementation easier Designer can concentrate on unique features of system under development Need an OS 5
Embedded OS Small No need of filesystem No need of GUI Single user No need of security features of multiuser OS 6
ADEOS (A Decent Embedded OS) Developed by Michael Barr Less than 1000 lines of source code ¾ platform independent, in C++ ¼ platform dependent, in assembly For learning embedded OS 7
Tasks Pseudoparallel: take turns using processor Processor decides: which task gets the processor context of a task (like a bookmark for a book reader) Instruction Pointer: Pointer to next instruction (80x86 Eg: CS and IP) Stack Pointer: Address of current top of stack (80x86 Eg: SS and SP) Process flag and general-purpose register contents (80x86 Eg: Flags, DS, ES, SI, DI, AX, BX, CX, DX) 8
Task Class in ADEOS class Task { public: Task( void (*function)(), Priority p, int stacksize ); TaskID id; Context context; TaskState state; Priority priority; int * pstack; Task * pnext; void (*entrypoint)(); private: static TaskId nextid; }; 9
Task States enum TaskState { Ready, Running, Waiting }; 10
Task Mechanics How to create a task for OS to run? How to use tasks? How to assign priority? How to assign stack size? etc. 11
Task Constructor 12
Task Constructor 13
Scheduler Decides which ready task gets to execute on the processor Common scheduling algorithms for nonembedded systems: First-In-First-Out (FIFO) Shortest Job First (SJF) Round Robin (RR): preemptive Not suitable for real-time embedded systems requires task priorities 14
Scheduler Priority-based scheduling needs a backup policy required when tasks have equal priorities Mostly, round-robin In ADEOS: FIFO ADEOS supports: 255 tasks, and 255 levels of priorities 15
Scheduler in ADEOS extern Sched os; 16
Scheduling Points Set of operating system events that result in scheduler invocation (os.schedule()) Task Creation (see constructor) Task Deletion Clock Tick (awakes tasks waiting on timers) (Timer class from Chapter 7 Peripherals: disable entercs, enable exitcs, 1 ms 10 ms ) 17
Ready List Fast dispatching Slow insertion 18
Idle Task An infinite loop Lowest priority At the end of ready list When no task is ready for execution, scheduler runs the idle task Other tasks are called user tasks 19
Scheduler 20
Scheduler 21
Scheduler 2 situations when context switch is not done: Multitasking not enabled (state!= Started) to create all tasks first and then start scheduler During interrupt processing (interruptlevel!= 0) to speed up interrupt response time 22
Create all tasks first 23
then, start scheduler! 24
Context Switch Hardware specific, in assembly contextswitch() executed twice! Returns non-zero when going to sleep Returns zero when awaking 25
Context Switch 26
Task Synchronization Tasks are not necessarily independent Tasks must communicate for solving a larger problem To coordinate access to shared data: variables, buffers, device registers, OS must provide one of the following: mutex or semaphore, message queues, monitors 27
Task Synchronization Mutex a multitasking-aware binary flag grants exclusive access to shared data! setting / clearing are ATOMIC! (guaranteed by OS by disabling interrupts) 28
Mutex Class wait for mutex to be cleared and set it clear a previously set mutex list of tasks waiting to take mutex 29
Mutex Constructor 30
Mutex::take() 31
Mutex::take() continued 32
Mutex:: release() 33
Mutex:: release() continued 34
Critical Section Mutexes can be used to access shared data without disabling interrupts Thus, to enter critical sections we do not need to disable interrupts Just use mutexes!!! 35
Dangers of using Mutex: Deadlock 2 Tasks, each of which require two mutexes: A and B Task 1 has mutex A and requires mutex B, Task 2 has mutex B and requires mutex A, Both will wait for each other and a deadlock occurs! System will crawl to a standstill Need reboot! 36
Dangers of using Mutex: Priority Inversion Low priority task is running and holds a shared resource High priority task need that shared resource High priority task waits for low priority task to release resource Middle priority task activates, preempts low priority task, and runs!!! High priority task is waiting for a long time, even forever! Space shuttle sent to Mars was lost like this! 37
38
Priority Inversion t 0 t 1 t 2 t 3 t 4 t 5 t 6 39
Real-Time Characteristics A late answer is as bad as a wrong one! A missed ABS deadline you are in an accident OR you are in a coffin! For an embedded OS to be a RTOS (Real- Time OS), it must satisfy 3 goals: Deterministic Guaranteed Worst-Case Interrupt Latency Guaranteed Worst-Case Context Switch Times 40
1. Deterministic RTOS Worst-case execution time of each system call is calculable RTOS vendor must publish a data sheet providing minimum, average, & maximum #clock cycles required for each system call Different for different processors Deterministic on 1 processor deterministic on any other processor 41
2. Guaranteed Worst-Case Interrupt Latency in an RTOS Interrupt Latency = from interrupt signal arrival to start of ISR Finish executing current instruction Recognize interrupt type Start interrupt (if enabled) If interrupts are disabled, the duration must also be considered in the interrupt latency 42
3. Guaranteed Worst-Case Context Switch Time in an RTOS Important because it is an overhead of entire system Processor-specific Must be published by RTOS vendor 43
Selection Process Buy a commercial RTOS, if you can afford to! Continuum of functionality, performance, and price! Lower end of spectrum: Accelerated Technology s Nucleus Kadak s AMX scheduler + a few system calls 44
Selection Process Higher end of spectrum: more functionalities stronger guarantees about real-time performance costly: $10,000 ~ $50,000 royalties: on every copy shipped in ROM free technical support, training, development tools Wind River Systems VxWorks Integrated Systems psos Microtec s VRTX 45
Selection Process Between these 2 extremes more functionalities than scheduler reasonable guarantees about real-time performance reasonable costs and royalties no source code extra cost for technical support Examples: all other commercial RTOS 46
Selection Process Processor Real-Time Performance Budget Compatibility with cross-compilers debuggers development tools Main Selection Criteria Differences: processors supported, memory requirements, add-on software modules (network protocol stacks, device drivers, Flash filesystems, ) 47