EIE 322 Interface and Embedded Systems

1. EIE 322 Interface and Embedded Systems

2. Introduction to Real-Time Operating System The acronym RTOS (�are toss�) is used in Simon. Other use the terms kernel, real-time kernel (RTK). Despite the similar name, most real-time operating systems are rather different from desktop operating systems such as Windows or Unix. RTOS available today: VxWorks, VRTX, pSOS, Nucleus, C Executive, LynxOS, QNX, MultiTask!, AMX and more.

3. Differences Compared to Desktop Operating System Desktop �your applications are compiled separately from the OS. As you turn-on your desktop, only the OS starts. Embedded system � your application is compiled and linked together with the RTOS . At boot-up time, your application usually gets control first, and it then starts the RTOS. Thus, the application and the RTOS are much more tightly tied to one another. Neither will run by itself.

4. Differences Compare to Desktop Operating System RTOS do not protect themselves as carefully from your application as do desktop operating systems. Reason: For better performance. When an Application is down, the RTOS alone cannot do much. To save memory, typically only part of the RTOS (services/routines/functions) that you need to support your embedded application system are compiled. Most RTOSs allow you to configure them extensively before you link them to the application, letting you leave out any functions you don�t need.

5. Tasks and Task States The basic building block of software written under an RTOS is the task. Tasks are very simple to write: under most RTOSs a task is simply a subroutine. (Figure 6.4) Each task in an RTOS is always in one of three states: Running, Ready, Blocked.

6. Task States

7. The Scheduler Scheduler � part of the RTOS that decides which task should go next into the running state. Unlike the scheduler in Unix or Windows, the schedulers in most RTOSs are entirely simpleminded about which task should get the processor: highest priority one runs first, and the rest wait in the ready state, regardless of starvation.

8. The Scheduler (cont) A task will block itself when it decides for itself that it has run out of things to do. A task has to be running just before it is blocked. While a task is blocked, it is inactive and the CPU cannot be re-acquire by the task itself. Therefore, an interrupt service routine or some other task in the system must be able to detect the occurrence of whatever conditions or events the task is waiting for. Otherwise, the task will be blocked forever.

9. The Scheduler (cont) The shuffling of tasks between the ready and running states is entirely the work of the scheduler. Tasks can block themselves. Tasks and interrupt routines can move other tasks from the blocked state to the ready state, but the scheduler has control over which task can switch to the running state.

10. Common Questions How does the scheduler know when a task has become blocked or unblocked? The RTOS provides a collection of functions that tasks can call to tell the scheduler what events they want to wait for and to signal that events have happened. What happens if all the tasks are blocked? If all the tasks are blocked, then the scheduler will stay in some tight loop somewhere inside the RTOS, waiting for something to happen. If something happens, an interrupt routine will calls some RTOS function that will unblock a task.

11. Common Questions (cont) What if two tasks with the same priority are ready? It depends on which RTOS was used. Possible solutions: making it illegal to have two tasks with the same priority or, time-slice between two such tasks. If one task is running and another higher-priority task unblocks, will the running task get stopped and moved to the ready state right away? A preemptive RTOS will stop a lower-priority task as soon as the higher-priority task unblocks. A non-preemptive RTOS will only take the microprocessor away from the lower-priority task when it blocks itself.

12. Tasks and Data Each task has its own private context, which includes the register values, a program counter, and a stack. However, all other data � global, static, initialized, uninitialized, and everything else � is shared among all tasks in the system. Typically, an RTOS has its own private data structures, which are not available to any of the tasks. With data variables shared among tasks, it is easy to pass information from one task to another.

13. Shared-Data Problems Recall in lecture 5 all the potential problems which are cause by sharing data. Theses problems will also arise in RTOS when data are shared among tasks. Figure 6.7 and Figure 6.8 show an example of how subtle these problems can be.

14. Reentrancy A reentrant function can be interrupted at any time and resumed at a later time without loss of data. A reentrant function can be used by more than one task without fear of data corruption. That is, more than one instance of it can be concurrently invoked and executed. One way to avoid the shared data problems is to allow access to shared data only among reentrant functions.

15. Reentrancy (cont) 3 rules to decide if a function is reentrant: A reentrant function must not perform any non-atomic access to shared unless they are stored on the stack of the task that called the function, or, they are 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 any hardware in a non-atomic way.

16. Examples from the text A Review of C Variable Storage p.150 Figure 6.9 Applying the Reentrancy Rules� Figure 6.10 Violate rule 1,2 How? Atomic? Yes and No

17. Semaphores and Shared Data By switching the CPU from task to task, an RTOS changes the flow of execution. There, like interrupts, it can also cause a new class of shared-data problems. Semaphores is one of the tools used by the RTOS to solve such problems. Semaphores are used to implement any of : Control access to a shared resource. Signal the occurrence of an event. Allow two tasks to synchronize their activities.

18. Semaphores and Shared Data A semaphore is a key that your code acquires in order to continue execution. If the semaphore is already in use, the requesting task is suspended until the semaphore is released by its current owner. In other words, the requesting task says:�Give me the key. If someone else is using it, I am willing to wait for it!�.

19. Semaphores and Shared Data Generally, only three operations can be performed on a semaphore: INITIALIZE (also called CREATE), WAIT (also called PEND), and SIGNAL (also called POST). The initial value of the semaphore must be provided when the semaphore is initialized. The waiting list of tasks is always initially empty. Figure 6.14 is an example showing how semaphores can be used.

20. Reentrancy and Semaphores

21. Multiple Semaphores What is the advantages of having multiple semaphores instead of a single one that protects all ? This avoids the case when higher priority tasks waiting for lower priority tasks even though they don�t share the same data. By having multiple semaphores, different semaphores can correspond to different shared resources.

22. Multiple Semaphores (cont) How does the RTOS know which semaphore protects which data? It doesn�t. If you are using multiple semaphores, it is up to you to remember which semaphore corresponds to which data.

23. Semaphores as a Signaling Device Semaphores can also be used as a simple way of communication between tasks, or between an interrupt routine and its associated task. Figure 6.16 provide a good example of how it can be apply. vPrinterTask( ) prepares a line to be printed in a_chPrint[]. vPrinterInterrupt( ) is an ISR that outputs the character string in a_chPrint[] to the printer. semPrinter is used by vPrinterTask( ) as a signal to vPrinterInterrupt( ) that a new string is ready.

24. Semaphore Problems Potential problems Forgetting to take the semaphore Forgetting to release the semaphore Taking the wrong semaphore Holding a semaphore for too long Priority inversion Figure 6.17 Some RTOSs resolve this problem with priority inheritance, they temporarily boost the priority of Task C to that of Task A whenever Task C holds the semaphore and Task A is waiting for it.

25. Semaphore Variants Counting semaphores � semaphores that can be taken multiple times. Resource semaphores � useful for the shared-data problem. Mutex semaphore � automatically deal with the priority inversion problem. If several tasks are waiting for a semaphore when it is released, different RTOS may vary in the decision as to which task gets to run. Task that has been waiting longest. Highest-priority task that is waiting for the semaphore

26. Deadlock A deadlock, also called a deadly embrace, is a situation in which two tasks are each unknowingly waiting for resources held by the other. Assume task T1 has exclusive access to resource R1 and task T2 has exclusive access to resource R2. If T1 needs exclusive access to R2 and T2 needs exclusive access to R1, neither task can continue. They are deadlocked.

27. Deadlock (cont) The simplest way to avoid a deadlock is for the tasks to Acquire all resources before proceeding, Acquire the resources in the same order, and Release the resources in the reverse order. Most RTOS allow you to specify a timeout when acquiring a semaphore. This features allows a deadlock to be broken.

28. Ways to Protect Shared Data So far we have learnt two methods: disabling interrupts and use semaphores. The third way is disabling task switches. Disabling task switches � To avoid shared-data corruptions caused by an inappropriate task switch, you can disable task switches while you are reading or writing the shared data.

29. Ways to Protect Shared Data Comparison of the 3 methods of protecting shared data: Disabling interrupts. Advantages. Only method that works if your data is shared between you task code and your interrupt routines and of all other tasks in the system. It is fast. Disadvantages. Affect the response times of all the interrupt routines.

30. Ways to Protect Shared Data 2. Taking semaphores. Advantages. It affects only those tasks that need to take the same semaphore. Disadvantages. Take up microprocessor time. Will not work for interrupt routine. 3. Disabling task switches. Somewhere in between the two. It has no effect on interrupt routines, but it stops response for all other tasks cold.

31. Running Running � means that the microprocessor is executing the instructions that make up this task. Unless yours is a multiprocessor system, there is only one microprocessor, and hence only one task that is in the running state at any given time.

32. Ready Ready � means that some other task is in the running state but that this task has things that it could do if the microprocessor becomes available. Any number of tasks can be in this state.

33. Blocked Blocked � means that this task hasn�t got anything to do right now, even if the microprocessor becomes available. Tasks get into this state because they are waiting for some external event. Any number of tasks can be in this state as well.

42. Atomic?

43. 8051 code -- No

44. 80x86 code -- Yes