this is test article
we are going to change this article
RTOSs use a third mechanism: they provide a separate set of functions especially for interrupt routines. So for example, in addition to OS, there might be ISR, which is to be called from interrupt routines. ISR is the same as 0S, except that it always returns to the interrupt routine that calls it, never to some other task. In this method, the RTOS also has a function the interrupt routine calls when it is over, and that function calls the scheduler.
Rule 2: No RTOS Calls without Fair Warning
To understand rule 2, examine figure above, a naive view of how an interrupt routine should work under an RTOS. The graph shows how the microprocessor’s attention shifted from one part of the code to another over time. The interrupt routine interrupts the lower-priority task, and, among other things, calls the RTOS to write a message to a mailbox (legal under rule l, assuming that function can’t block). When the interrupt routine exits, the RTOS arranges for the microprocessor to execute either the original task, or, if a higher-priority task was waiting on the mailbox, that higher priority task.
Interrupt routines in most RTOS environments must follow two rules that do not apply to task code.
Rule 1. An interrupt routine must not call any RTOS function that might block the caller. Therefore, interrupt routines must not get semaphores, read from queues or mailboxes that might be empty, wait for events, and so on. If an interrupt routine calls an RTOS function and gets blocked, then, in addition to the interrupt routine, the task that was running when the interrupt occurred will be blocked, even if that task is the highest- priority task. Also, most interrupt routines must run to completion to reset the hardware to be ready for the next interrupt.
Most RTOSs have some kind of memory management subsystem. Although some offer the equivalent of the C library functions malloc and free, real-time systems engineers often avoid these two functions because they are typically slow and because their execution times are unpredictable. They favor instead functions that allocate and free fixed-size buffers, and most RTOSs offer fast and predictable functions for that purpose.