Embedded Systems Introduction to Real-Time Operating Systems

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