1 / 73

Embedded Systems Introduction to Real-Time Operating Systems

Embedded Systems Introduction to Real-Time Operating Systems. C.-Z. Yang http://syslab.cse.yzu.edu.tw/~czyang Sept.-Dec. 2001. OS Architectures. A traditional UNIX system architecture. OS Architectures. A monolithic OS kernel. OS Architectures. A real-time kernel implementation.

gamba
Télécharger la présentation

Embedded Systems Introduction to Real-Time Operating Systems

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. Embedded SystemsIntroduction to Real-Time Operating Systems C.-Z. Yang http://syslab.cse.yzu.edu.tw/~czyang Sept.-Dec. 2001

  2. OS Architectures • A traditional UNIX system architecture Embedded Systems - Introduction to Real-Time Operating Systems

  3. OS Architectures • A monolithic OS kernel Embedded Systems - Introduction to Real-Time Operating Systems

  4. OS Architectures • A real-time kernel implementation Embedded Systems - Introduction to Real-Time Operating Systems

  5. OS Architectures • A micro-kernel RTOS Embedded Systems - Introduction to Real-Time Operating Systems

  6. Case Study: Real Time or Real Linux? A Realistic Alternative Paul N. Leroux Technology Analyst QNX Software Systems Ltd. Embedded Systems - Introduction to Real-Time Operating Systems

  7. Using Linux as a Real-time OS • For the embedded systems designer, Linux poses a dilemma. • Linux has a rich legacy of source code, and industry-standard POSIX APIs. • The standard Linux kernel can't deliver the "hard" real-time capabilities. • Several innate problems • Process scheduling • Preemptible kernel Embedded Systems - Introduction to Real-Time Operating Systems

  8. Process Scheduling • Preemptive priority • Rather than use a preemptive priority-based scheduler, as an RTOS would, Linux implements a "fairness" policy so that every process gets a reasonable opportunity to execute. • In fact, the OS will sometimes interrupt a high-priority process to give a lower-priority process a share of CPU time. Embedded Systems - Introduction to Real-Time Operating Systems

  9. Preemption • The standard Linux kernel isn't preemptible. • A high-priority process can never preempt a kernel call, but must instead wait for the entire call to complete - even if the call was invoked by the lowest-priority process in the system. Embedded Systems - Introduction to Real-Time Operating Systems

  10. Real Time Implemented Outside of Linux • Running Linux as a task on top of a realtime kernel • Any tasks that require deterministic scheduling also run in this preemptible kernel, but at a higher priority than Linux. Embedded Systems - Introduction to Real-Time Operating Systems

  11. The Dual-kernel model • System Operations • The realtime kernel always gets first dibs on hardware interrupts. • Otherwise, the kernel will pass the interrupt to Linux for processing. • Advantages • All this work is invisible to applications running in the Linux environment - except, of course, for the CPU cycles lost to the realtime kernel and its tasks. • System development is very flexible. Embedded Systems - Introduction to Real-Time Operating Systems

  12. Shortcomings of The Dual-kernel model • Duplicated coding efforts • Tasks running in the realtime kernel can't make full use of existing Linux system services. • Fragile execution environment • Tasks running in the realtime kernel don't benefit from the robust MMU-protected environment. • Limited portability • With the dual-kernel approach, realtime tasks aren't Linux processes at all, but threads and signal handlers written to a small subset of the POSIX API or, in some cases, a non-standard API. Embedded Systems - Introduction to Real-Time Operating Systems

  13. Shortcomings of The Dual-kernel model • No determinism for existing Linux applications and drivers • Because Linux processes don't run in the realtime kernel, they don't gain any deterministic behavior. • Limited design options • The APIs supported by the realtime kernel provide only a subset of the services provided by standard POSIX and Linux APIs. Embedded Systems - Introduction to Real-Time Operating Systems

  14. "Pure" Realtime Linux? • It allows developers to use a standard Linux kernel and programming model. • It helps address the low-latency requirements of reactive, event-driven systems. • However, • such low-latency patches don't address the complexity of most realtime environments. • For example, modifications of the Linux driver and virtual file system (VFS) are needed. Embedded Systems - Introduction to Real-Time Operating Systems

  15. Difficulties in a Pure Realtime Linux • In any case, it's unclear which realtime modifications, will eventually be integrated into the standard Linux kernel. • After all, most Linux-based systems rely on the kernel's current approach, which sacrifices predictability to achieve higher overall throughput. Embedded Systems - Introduction to Real-Time Operating Systems

  16. The Best of Both Worlds • The RTOS should be able to • allow Linux developers to keep their existing tools, source code, and programming model • maintain the key benefits, such as easier troubleshooting and OS customization, of Linux's open source model • address the shortcomings of realtime Linux extensions Embedded Systems - Introduction to Real-Time Operating Systems

  17. Several Problems • How well can an RTOS support the Linux programming model? • The answer lies, to a great degree, in the POSIX APIs adopted by Linux. • As a result, an RTOS can support the same POSIX APIs as Linux without adopting Linux's non-deterministic kernel. • A need for a new lingua franca among embedded Linux developers. Embedded Systems - Introduction to Real-Time Operating Systems

  18. QNX model • A realtime, microkernel architecture Embedded Systems - Introduction to Real-Time Operating Systems

  19. Embedded Linux: a new definition • As a set of APIs, along with a test suite to measure conformance. • As a result, • the RTOS inherently supports embedded Linux applications, while simultaneously providing all the benefits of a true RTOS designed from the ground up for embedded systems. Embedded Systems - Introduction to Real-Time Operating Systems

  20. More Benefits • A tougher runtime model • This model provides an environment for realtime applications that's inherently more robust than Linux - and certainly much tougher than the unprotected realtime kernels used in the dual-kernel approach. • A unified environment • The realtime and non-realtime environments are one and the same. Embedded Systems - Introduction to Real-Time Operating Systems

  21. More Benefits • Less duplicated effort • All drivers run in user space, so they can be developed using standard source-level tools and techniques. Embedded Systems - Introduction to Real-Time Operating Systems

  22. Background Embedded Systems - Introduction to Real-Time Operating Systems

  23. An Embedded RTOS • At boot-up time, your application usually gets control first, and it then starts the RTOS. • Many RTOSs do not protect themselves as carefully from your application as do desktop OS. • For many embedded systems, it may not matter if the application takes the RTOS down with it: the whole system will have to be rebooted anyway. Embedded Systems - Introduction to Real-Time Operating Systems

  24. An Embedded RTOS • To save memory RTOSs typically include just the services that you need for your embedded system and no more. • Most RTOSs allow you to configure them extensively before you link them to the application. Embedded Systems - Introduction to Real-Time Operating Systems

  25. Several Purchase Options • Run faster • Use less memory • Have a better API • Have better debugging tools • Support more processors • Have more already-debugged network drivers Embedded Systems - Introduction to Real-Time Operating Systems

  26. Tasks and Task States Embedded Systems - Introduction to Real-Time Operating Systems

  27. Tasks • The basic building block • Three states Embedded Systems - Introduction to Real-Time Operating Systems

  28. The Scheduler • It keeps track of the state of each task and decides which one task should go into the running state. • The schedulers in most RTOSs are entirely simpleminded about which task should get the processor: • They look at priorities you assign to the tasks. • The scheduler assume that you knew what you were doing when you set the task priorities. Embedded Systems - Introduction to Real-Time Operating Systems

  29. State Transitions • A task will only block because it decides for itself that it has run out of things to do. • While a task is blocked, it never gets the microprocessor. • The shuffling of tasks between the ready and running states is entirely the work of the scheduler. Embedded Systems - Introduction to Real-Time Operating Systems

  30. Some Common Questions • How does the scheduler know when a task has become blocked or unblocked? • Through a collection of RTOS function calls. • What happens if all the tasks are blocked? • The scheduler will spin in some tight loop somewhere inside of the RTOS, waiting for something to happen. Embedded Systems - Introduction to Real-Time Operating Systems

  31. Some Common Questions • What if two tasks with the same priority are ready? • It depend upon which RTOS you use. • At least one system solves this problem by making it illegal to have two tasks with the same priority. • Some other RTOSs will time-slice between two such tasks. • Some will run one of them until it blocks and then run the other. Embedded Systems - Introduction to Real-Time Operating Systems

  32. Some Common Questions • If one task is running and another, higher-priority task unblocks, does the task that is running get stopped and moved to the <ready> state right away? • A preemptive RTOS will stop a lower-priority task as soon. • A non-preemptive RTOS will only take the microprocessor away from the lower-priority task when that task blocks. Embedded Systems - Introduction to Real-Time Operating Systems

  33. This task will be unblocked as soon as the user pushes a button. A Simple Example • The classic situation Embedded Systems - Introduction to Real-Time Operating Systems

  34. A Simple Example • The computational task Embedded Systems - Introduction to Real-Time Operating Systems

  35. System Operations • Transitions Embedded Systems - Introduction to Real-Time Operating Systems

  36. Initialization Code • Assigning the priorities Embedded Systems - Introduction to Real-Time Operating Systems

  37. Features of Using an RTOS • Two tasks can be written independently of one another, and the system will still respond well. • The RTOS will make the response good whenever the user presses a button by turning the microprocessor over to the task that responds to the buttons immediately. Embedded Systems - Introduction to Real-Time Operating Systems

  38. Tasks and Data Embedded Systems - Introduction to Real-Time Operating Systems

  39. Context • Each task has its own private context. • the register values, • a program counter, • a stack. • All other data is shared among all of the tasks in the system. • Global • static • initialized • ... Embedded Systems - Introduction to Real-Time Operating Systems

  40. An Example • A common data area Embedded Systems - Introduction to Real-Time Operating Systems

  41. Sharing Data • Two main functions vRespondToButton vCalculateTankLevels Embedded Systems - Introduction to Real-Time Operating Systems

  42. Shared-data problems • Another example • Task2 interrupts Task1 Embedded Systems - Introduction to Real-Time Operating Systems

  43. A clearer examination • The assembly code Embedded Systems - Introduction to Real-Time Operating Systems

  44. A clearer examination • The flow Embedded Systems - Introduction to Real-Time Operating Systems

  45. Reentrancy • Reentrant functions are • functions that can be called by more than one task and that will always work correctly. • Even if the RTOS switches from one task to another in the middle of executing the function. Embedded Systems - Introduction to Real-Time Operating Systems

  46. Three Rules • A reentrant function may not use variables in a nonatomic way unless they are stored on the stack of the task that called the function or are otherwise the private variables of that task. • A reentrant function may not call any other functions that are not themselves reentrant. • A reentrant function may not use the hardware in a nonatomic way. Embedded Systems - Introduction to Real-Time Operating Systems

  47. A Review of C Variables • Where will the variables in the following code be stored? Embedded Systems - Introduction to Real-Time Operating Systems

  48. Applying the Reentrant Rules • Is this example reentrant? Embedded Systems - Introduction to Real-Time Operating Systems

  49. Gray Areas of Reentrancy • A reentrant function may not use non-stack variables in a non-atomic way. Is incrementing cErrors atomic? Embedded Systems - Introduction to Real-Time Operating Systems

  50. A 8051 code A 80x86 code A closer look Embedded Systems - Introduction to Real-Time Operating Systems

More Related