INTERRUPT MANAGEMENT An interrupt is a hardware mechanism used to service an event that can be external or internal to

Transcription

1 CHAPTER 2 ucosiii Page 1 ENGG4420 CHAPTER 2 LECTURE 5 October :28 PM INTERRUPT MANAGEMENT An interrupt is a hardware mechanism used to service an event that can be external or internal to the CPU. In real time environment, interrupts should be disabled as little as possible. INTERRUPT DISABLE TIME is the maximum amount of time that interrupts are disabled. INTERRUPT RESPONSE the time between the reception of the interrupt and the start of the user code that handles the interrupt. Accounts for the entire overhead involved in handling the interrupt. Typically processor's context is saved before the user code executes. INTERRUPT RECOVERY time required for the processor to return to the interrupted code or to a higher priority task. TASK LATENCY is defined as the time it takes from the time the interrupt occurs to the time task level code resumes.

2 CHAPTER 2 ucosiii Page 2 HANDLING CPU INTERRUPTS Most processors handle interrupts coming from a multitude of sources. For example: UART receives a character, an Ethernet controller receives a packet, a DMA controller completes a data transfer, an ADC completes a conversion, a timer expires, etc. Modern interrupt controllers have built in intelligence CPU deals with interrupts in one of two ways: All interrupts vector to a single interrupt handler. Each interrupt vectors directly to an interrupt handler.

3 CHAPTER 2 ucosiii Page 3 TYPICAL uc/os III INTERRUPT SERVICE ROUTINE (ISR) uc/os III requires that ISRs be written in assembly language. CASE: ISR signals or sends a message to a task (1) to (6) can be named as ISR Prologue and (9) to (11) as the ISR Epilogue. (1) the name of the handler that will handle the interrupting device...

4 CHAPTER 2 ucosiii Page 4 NON KERNEL AWARE INTERRUPT SERVICE ROUTINE (ISR) CASE: the ISR doesn't signal a task (1) interrupt handler's name (2)...

5 CHAPTER 2 ucosiii Page 5 PROCESSOR WITH MULTIPLE INTERRUPT PRIORITIES Some processor support multiple interrupt levels (1) assume 16 levels of priority with 0 the lowest (2) interrupt levels 0 through 12 will be allowed to make uc/os III 'post' calls to notify tasks that are assigned to service these interrupts. What happens when disabling interrupts (when entering the critical sections)?? (3) Interrupt levels 12 through 15 will not be allowed to make any uc/os III function calls.

6 CHAPTER 2 ucosiii Page 6 ALL INTERRUPTS VECTOR TO A COMMON LOCATION Some CPUs will vector to a common interrupt handler even an interrupt controller is present. The ISR queries the interrupt controller to determine the source of the interrupt For uc/os III this is an advantage (1)...

7 CHAPTER 2 ucosiii Page 7 EVERY INTERRUPT VECTORS TO A UNIQUE LOCATION If the interrupt controller vectors directly to the appropriate interrupt handler, each of the ISRs must be written in assembly language as described before in Section "Typical uc/os III Interrupt Service Routine". If the interrupt controller allows the user to query it for the source of the interrupt, then we could emulate the one vector location scenario.

8 CHAPTER 2 ucosiii Page 8 DIRECT AND DEFERRED POST METHODS uc/os III handles event posting from interrupts in two ways: 1) direct, and 2) indirect. From an application and ISR code these two methods are completely transparent. We only need to change the configuration value OS_CFG_ISR_POST_DEFERRED_EN to switch between two methods.

9 CHAPTER 2 ucosiii Page 9 DIRECT POST METHOD The direct method was used in uc/os II as well (1) device generates an interrupt (an event) (2) ISR executes and in general will signal a task that waited for this event. (3) If the ISR made a lower (or equal) priority task ready to run then after completion of the ISR code uc/os III will return to the interrupted task. (4) if the ISR made a higher priority task ready to run, uc/os III will context switch to the new highest priority task. (5) in the direct post method, uc/os III needs to protect the critical sections by disabling interrupts.

10 CHAPTER 2 ucosiii Page 10 CHARACTERIZING THE INTERRUPT TIMES Interrupt Latency = Maximum interrupt disable time; Interrupt Response = Interrupt Latency + Vectoring to the interrupt handler + ISR prologue; Interrupt Recovery = Handling of the interrupting device + Posting a signal or a message to a task + OSIntExit() + OSIntCtxSw(); Task Latency = Interrupt response + Interrupt recovery + Time scheduler is locked; The execution times of the uc/os III ISR prologue, ISR epilogue, OSIntExit(), and OSIntCtxSw(), can be measured independently and should be fairly constant. In the direct method the scheduler is locked only when handling timers and therefore, task latency should be fast if there are few timers with short callbacks expiring at the same time.

11 CHAPTER 2 ucosiii Page 11 DEFERRED POST METHOD Instead of disabling interrupts to access critical sections, uc/os III locks the scheduler this avoids having other tasks access critical sections while allowing interrupts to be recognized and serviced. (3) the ISR queues the post to the task in a special queue called Interrupt Queue. The ISR then makes the Interrupt Queue Handler Task ready to run. This task is internal to uc/os III and it always has priority 0. (4) uc/os III context switches to the interrupt queue handler task. Interrupts are disabled while the interrupt queue is being emptied Then the interrupts are re enabled, the scheduler is locked, the post calls is performed from this task level. (5) after the queue is emptied the task makes itself not ready to run

12 CHAPTER 2 ucosiii Page 12 CHARACTERIZING THE INTERRUPT TIMES Interrupt Latency = Maximum interrupt disable time; Interrupt Response = Interrupt Latency + Vectoring to the interrupt handler + ISR prologue; Interrupt Recovery = Handling of the interrupting device + Posting a signal or a message to a task + OSIntExit() + OSIntCtxSw() to Interrupt Queue Handler Task; Task Latency = Interrupt response + Interrupt recovery + Re issue the post to the object or task + Context switch to the task + Time scheduler is locked; The main difference between the two methods is that the Deferred Post Method keeps the interrupts disabled for a very short time period and thus the first 3 metrics should be fast. However, task latency should be higher since uc/os III locks the scheduler to access critical sections.

13 CHAPTER 2 ucosiii Page 13 DIRECT VS. DEFERRED POST METHOD The interrupt disable time for the deferred post method is very short and fairly constant If interrupt disable time is critical in the application (i.e., there are very fast interrupt sources) use the deferred post method.

14 FEATURES THAT CALL FOR USING THE DIRECT POST METHOD CHAPTER 2 ucosiii Page 14

15 CHAPTER 2 ucosiii Page 15 PEND LIST (OR WAIT LIST) A pend list is a data structure of type OS_PEND_LIST Each kernel object using a pend list contains the same three fields at the beginning of the kernel object that is called an OS_PEND_OBJ. A pend list doesn't actually points to a task's OS_TCB, but instead it points to OS_PEND_DATA object shown below:

16 CHAPTER 2 ucosiii Page 16 EXAMPLE of two tasks waiting on a semaphore. Shows how all data structures connect to each other when tasks are inserted in a pend list.

17 CHAPTER 2 ucosiii Page 17 TIME MANAGEMENT uc/os III provides the following services to manage time. The code is found in os_time.c

18 CHAPTER 2 ucosiii Page 18 OSTimeDly() suspend execution until some time expires. This function allows 3 modes of time delay: relative, periodic, and absolute EXAMPLE OF USING OSTimeDly() in relative mode (1) the first argument specifies the number of ticks. If for example the tick rate is set to 1000Hz (OS_CFG_TICK_RATE_HZ in os_cfg_app.h) then we delay for 2 milliseconds. However, the delay is not accurate. (2) specifying OS_OPT_TIME_DLY indicates relative mode (3) an error will be return here (OS_ERR_NONE should be return when everything is ok) (4) always need to check the error. If not OS_ERR_NONE, then OSTimeDly() did not perform the intended work.

19 CHAPTER 2 ucosiii Page 19 THE DELAY IS NOT ACCURATE Assume that the LPT (low priority task) calls to delay for 2 ticks. (1) tick interrupt (2) all Higher Priority Tasks (HPTs) execute for an unknown amount of time. (3) LPT executes (4) LPT calls OSTimeDly() for 2 ticks in relative mode (5) the next tick occurs (6) HPT execute (LPT is blocked, waiting for 2 ticks) (7) the next tick occurs LPT is made ready to run (8) since there are no HPT to execute on this tick, LPT will get the CPU time. (9) as seen the delay time can vary greatly, depending on the execution time of HPTs

20 CHAPTER 2 ucosiii Page 20 OSTimeDly() with the OS_OPT_TIME_PERIODIC parameter this option allows delaying the task until the tick counter reaches a certain periodic match value. In relative mode it is possible to miss one of the ticks when the system is heavily loaded, missing a tick or more on occasion. In periodic mode, the task may execute later but it will always be synchronized to the desired number of ticks. Periodic mode is preferred mode to use to implement a time of day clock.

21 CHAPTER 2 ucosiii Page 21 OSTimeDly() with OS_OPT_TIME_MATCH parameter is the absolute mode. The "dly" parameter corresponds in this case to the desired value of OSTickCtr you want to reach. Normally, counted from the power up. SUMMARY the task will wake up when OSTickCtr reaches the following value:

22 HOMEWORK: OSTimeDlyHMSM(); OSTimeDlyResume(); OSTimeSet(); OSTimeGet(); OSTimeTick(). CHAPTER 2 ucosiii Page 22

23 CHAPTER 2 ucosiii Page 23 TIMER MANAGEMENT os_tmr.c Timer services are enabled when setting OS_CFG_TMR_EN to 1 in os_cfg.h uc/os III provides the following services to mange the timers A timer must be first created by calling OSTmrCreate() and specify a number of arguments based on the desired timer functionality. Once the timer operation is specified, its operation can't be change until the timer is deleted or recreated. The timers can be created to operate in one of three modes: One shot, Periodic (no initial delay), and Periodic (with initial delay).

24 CHAPTER 2 ucosiii Page 24 RESOURCE MANAGEMENT uc/os III provides services to mange shared resources. A shared resource is typically a variable (static or global), a data structure, table (in RAM), or registers in an I/O device. When protecting a shared resource is preferred to use mutual exclusion semaphores.

25 CHAPTER 2 ucosiii Page 25 RESOURCE SHARING METHODS DISABLE/ENABLE INTERRUPTS LOCK/UNLOCK

26 CHAPTER 2 ucosiii Page 26 SEMAPHORES is a kernel object defined by the OS_SEM data type, which is defined by the structure os_sem (see os.h). Types of semaphores: Binary takes two values: 0 or 1 Counting takes values between 0 and 255; or 0 and 65,535; or 0 and 4,294,967,295. There are a number of operations that an application can perform on semaphores:

27 CHAPTER 2 ucosiii Page 27 BINARY SEMAPHORES a task that wants to acquire a resource must perform a Wait (or Pend) operation. If the semaphore is available (it's value is 1), the semaphore value is set to 0, and the task continues execution (owning the resource). If the semaphore's value is 0 then the task performing the Pend is placed in the waiting list of the semaphore. A timeout on wait can be specified. A task releases a semaphore by performing a Signal (or Post) operation. CREATING A SEMAPHORE

28 CHAPTER 2 ucosiii Page 28 USING A SEMAPHORE TO ACCESS A SHARED RESOURCE (3) this argument specifies how to wait. There are two options: OS_OPT_PEND_BLOCKING and OS_OPT_PEND_NON_BLOCKING. Blocking calling OSSemPned() will wait until the semaphore is posted or until timeout expires Non blocking OSSemPend() will return immediately and not wait if semaphore is not available.

29 USING A SEMAPHORE FROM A DIFFERENT TASK TO ACCESS A SHARED RESOURCE CHAPTER 2 ucosiii Page 29

30 CHAPTER 2 ucosiii Page 30 SEMAPHORES ARE USEFUL WHEN TASKS SHARE I/O DEVICES RULE: To access the printer each task must first obtain the resource's semaphore. Each task must know about the existence of the semaphore to access the resource.

31 CHAPTER 2 ucosiii Page 31 HIDING A SEMAPHORE FROM A TASK It is better to encapsulate the critical section and its protection mechanism each task would not know that in fact they need to acquire a semaphore when accessing the resource. Example above with RS232C port uses a command function CommSendCmd() with 3 arguments.

32 COUNTING SEMAPHORES CHAPTER 2 ucosiii Page 32