1 / 16

Applications and RTOSs

Applications and RTOSs. System Layers. Everything above hardware is software Layered Architecture. Application(s)/Programs. Firmware. Hardware. Command and Control App. This kind of application shows up over and over again in Embedded Systems Simple Command Shell May use serial port

Download Presentation

Applications and RTOSs

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related