Applications and RTOSs

1. Applications and RTOSs

2. System Layers • Everything above hardware is software • Layered Architecture Application(s)/Programs Firmware Hardware Instructor: G. Rudolph, Summer 2008

3. Command and Control App • This kind of application shows up over and over again in Embedded Systems • Simple Command Shell • May use serial port • May use internet if you assume network stack is operational Instructor: G. Rudolph, Summer 2008

4. Command Representation Name • Handler • Optional Parameters • Shell must build an internal representation of any legal command • One structure entry per command • In C, we link names to function pointers • In OO systems, we would typically link a command to an object rather than a method Instructor: G. Rudolph, Summer 2008

5. Command Table • In text, all commands are in a single file • Single place to look in the code • In Java, we “can’t” do that the same way, but we can do other things • Put all command objects in the same package • Modularity is usually better in long run than monolithic files • Lejos JVM is written in C for efficiency and convenience. But JVM is an OS, not an application. Instructor: G. Rudolph, Summer 2008

6. RTOS • Embedded System May or may not use an OS • Many RTOS’s available • RTOS is NOT democratic! • Highest priority task that is ready to run gets all the time it needs • If other tasks starve, it’s the programmer’s fault Instructor: G. Rudolph, Summer 2008

7. Reasons to Use an RTOS • If not using an RTOS, use alternate software framework • Make writing programs easier • Multi-tasking • Scheduling • Timers • Inter-task communication • Isolate/manage software changes WRT hardware Instructor: G. Rudolph, Summer 2008

8. OS Kernel Scheduler • FIFO • Shortest task first • Priority • Round Robin • Intertask Communication Mechanisms • Pipes • Queues • Shared Memory [Variables (Mutex’s)] Instructor: G. Rudolph, Summer 2008

9. Real-time Scheduling Algorithms • Many tasks have deadlines, some may not • Real-time Executive • Earliest deadline First • Minimal Laxity First • Resource Reservation • Which algorithm you choose depends upon your goals • Critical timing constraints MUST be met • Most RTOSs use preemptive multitasking scheme Instructor: G. Rudolph, Summer 2008

10. Scheduling Points • Task Creation • Task deletion • Clock Tick • Task Block • Task Unblock Instructor: G. Rudolph, Summer 2008

11. Tasks/Threads • States: Ready, Running, Waiting, Dead • See Fig 10-4 pg. 180 of text • Current task will run until • it terminates • a higher task is ready to run • it blocks waiting for external event or resource • Scheduler most often uses a Priority Queue for each non-running state to keep track of tasks • Each task has its own Call Stack and Context Instructor: G. Rudolph, Summer 2008

12. Task Starvation Problems • Processor overload • Low-priority tasks never get to run • A bug in the code Solutions • Faster Processor • Different algorithm • Fix all bugs Instructor: G. Rudolph, Summer 2008

13. Task Behavior • Code becomes a collection of tasks • Don’t know in which order tasks will be executed • Use “Run-to-completion” semantics when writing code Init task-specific resources Wait for event Handle Event/Do Work Instructor: G. Rudolph, Summer 2008

14. Intertask Communication • Goal: Avoid disabling interrupts • Mutex (binary flag) and Semaphore (counter) Dangers • Deadlock • Priority Inversion Instructor: G. Rudolph, Summer 2008

15. Message Queue • Pass messages between tasks using a Queue • Tasks + Message Queues + Eventsform the basis for coding reactive FSM frameworks Instructor: G. Rudolph, Summer 2008

16. Really Real-time • Tasks have deadlines—a late answer is as bad as a wrong one • best, worst and average interrupt handling times • Deterministic • Can calculate worst-case execution time of any system call • Time Used for Context Switch Instructor: G. Rudolph, Summer 2008