RTOS Interrupt Architectures: Two Approaches - Unified and Segmented

Like stand-alone systems, embedded applications running on top of real-time operating systems (RTOSes) require Interrupt Service Routines (ISRs) to handle interrupts generated by external events. External events can be caused by just about anything, from an asynchronous character arrival on a UART to a periodic timer interrupt. ISRs have the responsibility of acknowledging the hardware condition and provide the initial handling of data sent or received as required by the interrupt. An ISR often is responsible for providing the RTOS with information necessary to provide services to application threads. Examples include moving data into a buffer for processing, adding an entry to a queue for processing, setting a value to indicate that an event has occurred, and so on. Since application code execution is interrupted (delayed) during the execution of an ISR, most applications minimize the amount of code in the ISR and rely instead on non-ISR code (an application “Thread” or “Task”) to complete the processing. This allows the highest priority application code to be executed as quickly as possible, and delayed as little as possible, even in situations with intense interrupt activity.

View Entire Paper | Previous Page | White Papers Search

If you found this page useful, bookmark and share it on: