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 2013

3. Simple Polling Loop Check for 1 • Simple • Sequential Check • Easy to maintain • Processing time is sum of handling time • Might miss messages • Main loop is always running • NOT responsive Check for 2 Check for 3 Check for n Instructor: G. Rudolph, Summer 2013

4. Command and Control App • This kind of application shows up over and over again in Embedded Systems • Simple Command Shell • Blocks/sleeps waiting for input • May use serial port • May use internet if you assume network stack is operational Instructor: G. Rudolph, Summer 2013

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

6. 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 2013

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

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

9. OS Kernel Scheduler • FIFO • Shortest task first • Priority • Round Robin • Intertask Communication Mechanisms • Pipes • Queues • Shared Memory [Variables (Mutexes)] Instructor: G. Rudolph, Summer 2013

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

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

12. Tasks/Threads • States: Ready, Running, Waiting, Dead • 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 2013

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

14. 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 2013

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

16. Multitasking • Do more than one thing • Go forward • Periodically print to screen • Decompose behaviors into tasks • Each task is one behavior • Triggered by some sensor or event Instructor: G. Rudolph, Summer 2013

17. Behavior API • Subsumption Architecture • Set of behaviors with distinct priorities • Arbitrator • A Higher-priority behavior preempts lower-priority behavior • Lejos • You define behaviors • Add them to the arbitrator • Arbitrator decides which task runs Instructor: G. Rudolph, Summer 2013

18. Message Queue • Pass messages between tasks using a Queue • Tasks + Message Queues + Events/Msgsform the basis for coding reactive FSM frameworks Instructor: G. Rudolph, Summer 2013

19. What Do You Need? Blocking Queue Task1 Task2 Put message in Q • Wait for message • Handle when arrives • Pull message • Find type • Call correct handler Instructor: G. Rudolph, Summer 2008

20. 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 2013

21. Desirable Characteristics • Responsive • Timely response to external stimuli • Reliable • Predictable device behavior • Well-behaved tasks • Known memory footprint • Robust • Reasonable response to anomalous environment—things you could not plan for Instructor: G. Rudolph, Summer 2008