Introduction
Interrupts are the mechanism that allow for a system to respond to external events in a timely manor which is crucial for the use of timers as both precision and accuracy are required for accurate time keeping. Interrupts are also used frequently for implementing communication protocols as to lower the processor overhead and meet timing requirements.
Interrupts are implemented using dedicated routines called interrupt service routines (ISRs) and dedicated interrupt hardware called an interrupt controller. These allow external events to be registered by the system allowing appropriate action to be taken. An alternative to using an interrupt is a polling technique that periodically check for changes to memory state of a memory mapped device or registers associated with a device. This behavior is non-deterministic as no timing guarantees can be made therefore interrupts should be implemented for time or safety sensitive applications. The other drawback of using a polling technique is that it incurs a higher overhead than an interrupt due to redundant polling of memory and registers which requires CPU time as it does not use dedicated hardware for the task.
About this Document
This ISR User Guide describes the operation and configuration of Interrupts for RTA-OS using the ISOLAR and OS Configuration tool.
How interrupts are implemented
Interrupts use specialized hardware which can be implemented in a number of ways however they are typically implemented using a technique called Message Signal Interrupts (MSI). MSI works by having an interrupt controller which maps a unique memory address to each device, when the memory mapper/manager detects a memory write to one of these addresses the interrupting device is then identified by the address written to as each devices interrupt address is unique.
To determine which interrupt the now-identified device has triggered; the value written to memory is evaluated. This value corresponds to an entry in the interrupt vector table where each entry in the table corresponds to an interrupt service routine (ISR). Once an interrupt has been triggered, a dirty bit is then set against the interrupt indicating that the interrupt has been triggered which, depending on the hardware target may have to be cleared manually. The responsibility for clearing this bit can be on either the OS or the ISR, the responsibility of this typically depends on the interrupt category (See next section) however this isn't guaranteed to be the case so the responsibility should be known before any ISRs are implemented.
Types of interrupt
The Autosar specification outlines two types of interrupt; category 1 (CAT1) and category 2 (CAT2) interrupts, these differ in their interaction with the operating system. CAT1 interrupts are not allowed to interact with OS data structures or use OS API calls with the exception being that they may make API calls only to disable and enable interrupts which allows them lower latency as they are invisible to the operating system.
Interrupts being invisible to the OS puts the responsibility of saving the processor state and then setting up the processor state in preparation for the interrupt on the implementer of the ISR, this includes resetting the interrupt's dirty bit which is advised to be done as the first thing in the ISR as during the execution of the ISR as the same interrupt may be triggered a second time which wont be registered unless the dirty bit has already been cleared. Lastly, the CAT1 ISR implementation has the responsibility of restoring the processor state back to the pre-interrupted state once the interrupt has completed which is target specific therefore development of these ISRs becomes a more complex task. To implement a CAT1 interrupt, the implementer should define it as a C function using the CAR1_ISR macro which will be used by the compiler to insert the required API calls for the OS.
CAT2 interrupts are allowed to make most OS API calls however as they are directly supported and abstracted by the OS therefore these types of interrupt typically have higher latency than CAT1 interrupts therefore consideration should be taken as to which type of interrupt best suits the prolem. The OS abstraction makes the OS responsible for saving, initializing and restoring the processor state for the interrupt which simplifies ISR development.
Configuration of interrupts
ISOLAR-AB
Interrupts are configured using the ISOLAR-AB tool, configuration is done through the OS BSW module in ISOLAR under the OsIsrs sub folder as shown below.
In the image below, the heading OsIsr refers to the C code that implements the handler. OsIsrCategory identifies the interrupts as CAT1 or CAT2. OsIsrPriority is used by the interrupt controller to allow nesting of interrupts as higher priority interrupts may execute over lower priority interrupts. This Priority value is target-specific so an OS target must be specified before OsIsrPriority may be set. OsIsrAddress specifies the interrupt vector used by the OS to generate the vector table. This is target-specific so a target must be specified before the field may be configured.
MCAL Configuration
Interrupts for the MCAL are configured in the irq module found in the drop down list on the left pane.
Double clicking to open this module configuration will lead to the irq module configuration pane opening up in the center of the screen as shown below.
Each type of IRS for configuration can be found in it's respective tab across the top as seen in the screenshot above, eg CAN interrupts are found in the tab irqCanConfig.
ISRs can be configured by clicking on their respective tab and then double clicking on the left cell in for the entry in the table as shown by the arrow in the image below.
This opens up the configuration window for the selected ISR type as shown below.
The specific ISR's may then be found within the tabs across the top of the above image such as the GtmTom 0 ISR may be configured by clicking the left cell of the associated row in the table as shown by the red arrow in the image below.
This opens into the GtmTom0 config window as seen below.
Example
ISOLAR-AB configuration
For an example, lets configure an ISR for the generic timer module (GTM). Firstly under the OS folder, we will add an entry to the OsIsrs folder with the name GTMATOM0SR0_ISR which refers to the C function name of the interrupt handler.
Next we will select the interrupt category which we will set as CATEGORY_2.
Next we shall select the address/vector of the interrupt which is Interrupt_SRC_GTMATOM00 for our timer.
We can then choose the ISR priority, for our demonstration we can just use priority level 2.
The result should look like this:
MCAL Configuration
Next the ISR must be configured for the MCAL, therefore configuration must be done using the MCAL configuration tool.
Lets start by opening up the MCAL configuration tool, importing the project and opening up the irq module configuration window.
Next we will navigate to the irqGtmConfig tab and opening up the entry for irqGtmConfig_0.
We will next navigate to the irq_GtmATOM_Config tab as we are setting up the GTMATOM0 ISR and opening the associated entry in the table for IRS (irq_GtmAtom0_Config). From here we can set the interrupt to CAT2 and the priority to 2 these values must match the same config used in the ISOLAR-AB tool as seen below.
With all of this done and the project generated, compiled and running on hardware; we should have the routine GTMATOM0SR0_ISR executing upon every trigger of GTMATOM0SR0.