Which interrupt is reserved for the system timer

A new thread is created for each interrupt request. It is important to consider each individual request as a separate thread because local variables and registers used in the interrupt service routine are unique and separate from one interrupt event to the next interrupt.

In a multi-threaded system, we consider the threads as cooperating to perform an overall task. Consequently we will develop ways for the threads to communicate e. Most embedded systems have a single common overall goal. On the other hand, general-purpose computers can have multiple unrelated functions to perform. A process is also defined as the action of software as it executes. Processes do not necessarily cooperate towards a common shared goal.

Interrupt Basics. Interrupt Processing - The Context Switch. There are no standard definitions for the terms mask, enable, and arm in the professional, Computer Science, or Computer Engineering communities.

Nevertheless, in this class we will adhere to the following specific meanings. To arm a device means to allow the hardware trigger to interrupt. Conversely, to disarm a device means to shut off or disconnect the hardware trigger from the interrupts. Each potential interrupting trigger has a separate arm bit.

One arms a trigger if one is interested in interrupts from this source. Conversely, one disarms a trigger if one is not interested in interrupts from this source. To enable means to allow interrupts at this time. Conversely, to disable means to postpone interrupts until a later time. We disable interrupts if it is currently not convenient to accept interrupts. In C, we enable and disable interrupts by calling the functions EnableInterrupts and DisableInterrupts respectively. The software has dynamic control over some aspects of the interrupt request sequence.

First, each potential interrupt trigger has a separate arm bit that the software can activate or deactivate. The software will set the arm bits for those devices from which it wishes to accept interrupts, and will deactivate the arm bits within those devices from which interrupts are not to be allowed. In other words it uses the arm bits to individually select which devices will and which devices will not request interrupts. The third aspect that the software controls is the interrupt enable bit.

If this bit is 1 most interrupts and exceptions are not allowed, which we will define as disabled. If the bit is 0, then interrupts are allowed, which we will define as enabled.

The fourth aspect is priority. For example if the software sets the BASEPRI to 3, then requests with level 0, 1, and 2 can interrupt, while requests at levels 3 and higher will be postponed.

The software can also specify the priority level of each interrupt request. The fifth aspect is the external hardware trigger. Five conditions must be true for an interrupt to be generated:.

For an interrupt to occur, these five conditions must be simultaneously true but can occur in any order. An interrupt causes the following sequence of five events. First, the current instruction is finished. If the floating point unit on the TM4C is active, an additional 18 words will be pushed on the stack representing the floating point state, making a total of 26 words. Fourth, the IPSR is set to the interrupt number being processed.

These five steps, called a context switch , occur automatically in hardware as the context is switched from a foreground thread to a background thread. Next, the software executes the ISR. Rather the request is held pending , postponed until a later time, when the system deems it convenient to handle the requests.

In other words, once the trigger flag is set, under most cases it remains set until the software clears it. The five necessary events device arm, NVIC enable, global enable, level, and trigger can occur in any order. For example, the software can set the I bit to prevent interrupts, run some code that needs to run to completion, and then clear the I bit.

Clearing a trigger flag is called acknowledgement , which occurs only by specific software action. Each trigger flag has a specific action software must perform to clear that flag. The SysTick periodic interrupt will be the only example of an automatic acknowledgement.

For SysTick, the periodic timer requests an interrupt, but the trigger flag will be automatically cleared when the ISR runs. For all the other trigger flags, the ISR must explicitly execute code that clears the flag. The interrupt service routine ISR is the software module that is executed when the hardware requests an interrupt. There may be one large ISR that handles all requests polled interrupts , or many small ISRs specific for each potential source of interrupt vectored interrupts.

The design of the interrupt service routine requires careful consideration of many factors. Except for the SysTick interrupt, the ISR software must explicitly clear the trigger flag that caused the interrupt acknowledge. Because LR contains a special value e.

The software in this class will exclusively use the MSP. It is imperative that the ISR software balance the stack before exiting.

Execution of the previous thread will then continue with the exact stack and register values that existed before the interrupt. Although interrupt handlers can create and use local variables, parameter passing between threads must be implemented using shared global memory variables.

A private global variable can be used if an interrupt thread wishes to pass information to itself, e. The execution of the main program is called the foreground thread, and the executions of the various interrupt service routines are called background threads. An axiom with interrupt synchronization is that the ISR should execute as fast as possible. The interrupt should occur when it is time to perform a needed function, and the interrupt service routine should perform that function, and return right away.

Placing backward branches busy-wait loops, iterations in the interrupt software should be avoided if possible. The percentage of time spent executing interrupt software should be small when compared to the time between interrupt triggers.

Performance measures: latency and bandwidth. For an input device, the interface latency of an interrupt-driven input device is the time between when new input is available, and the time when the software reads the input data.

For example, if we request that a certain sector be read from a disk, then the device latency is the time it take to find the correct track and spin the disk seek so the proper sector is positioned under the read head. For an output device, the interface latency of an interrupt-driven output device is the time between when the output device is idle, and the time when the software writes new data.

A real-time system is one that can guarantee a worst case interface latency. Many factors should be considered when deciding the most appropriate mechanism to synchronize hardware and software. One should not always use busy wait because one is too lazy to implement the complexities of interrupts. On the other hand, one should not always use interrupts because they are fun and exciting. Interrupts allow for quick response times to important events. In particular, using interrupts is one mechanism to design real-time systems, where the interface latency must be short and bounded.

Bounded means it is always less than a specified value. Short means the specified value is acceptable to our consumers. Interrupts can also be used for infrequent but critical events like power failure, memory faults, and machine errors.

Periodic interrupts will be useful for real-time clocks, data acquisition systems, and control systems. For extremely high bandwidth and low latency interfaces, direct memory access DMA should be used. An atomic operation is a sequence that once started will always finish, and cannot be interrupted.

In this way, interrupts will not be able to break apart the sequence. Checkpoint As you develop experience using interrupts, you will come to notice a few common aspects that most computers share.

The following paragraphs outline three essential mechanisms that are needed to utilize interrupts. Although every computer that uses interrupts includes all three mechanisms, how the mechanisms operate will vary from one computer to another.

All interrupting systems must have the ability for the hardware to request action from computer. In general, the interrupt requests can be generated using a separate connection to the processor for each device. The TM4C microcontrollers use separate connections to request interrupts. All interrupting systems must have the ability for the computer to determine the source. A vectored interrupt system employs separate connections for each device so that the computer can give automatic resolution.

You can recognize a vectored system because each device has a separate interrupt vector address. With a polled interrupt system, the interrupt software must poll each device, looking for the device that requested the interrupt. Most interrupts on the TM4C microcontrollers are vectored, but there are some triggers that share the same vector.

For these interrupts the ISR must poll to see which trigger caused the interrupt. For example, all input pins on one GPIO port can trigger an interrupt, but the trigger flags share the same vector. The third necessary component of the interface is the ability for the computer to acknowledge the interrupt. Normally there is a trigger flag in the interface that is set on the busy to ready state transition.

In essence, this trigger flag is the cause of the interrupt. Acknowledging the interrupt involves clearing this flag. It is important to shut off the request, so that the computer will not mistakenly request a second and inappropriate interrupt service for the same condition. So when designing an interrupting interface, it will be important to know exactly what hardware condition sets the trigger flag and request an interrupt and how the software will clear it acknowledge in the ISR.

Common Error: The ISR software should not disable interrupts at the beginning nor should it reenable interrupts at the end. Which interrupts are allowed to run is automatically controlled by the priority set in the NVIC. For regular function calls we use the registers and stack to pass parameters, but interrupt threads have logically separate registers and stack. More specifically, registers are automatically saved by the processor as it switches from main program foreground thread to interrupt service routine background thread.

Exiting an ISR will restore the registers back to their previous values. Thus, all parameter passing must occur through global memory.

One cannot pass data from the main program to the interrupt service routine using registers or the stack. In this chapter, multi-threading means one main program foreground thread and multiple ISRs background threads.

An operating system allows multiple foreground threads. Synchronizing threads is a critical task affecting efficiency and effectiveness of systems using interrupts.

In this section, we will present in general form three constructs to synchronize threads: binary semaphore, mailbox, and FIFO queue.

Inter-Thread Communication and Synchronization. A binary semaphore is simply a shared flag, as described in Figure There are two operations one can perform on a semaphore. Signal is the action that sets the flag. Wait is the action that checks the flag, and if the flag is set, the flag is cleared and important stuff is performed. This flag must exist as a private global variable with restricted access to only these two code pieces.

In C, we add the qualifier static to a global variable to restrict access to software within the same file. In order to reduce complexity of the system, it will be important to limit the access to this flag to as few modules as possible. Figure A semaphore can be used to synchronize threads. A flag of course has two states: 0 and 1.

However, it is good design to assign a meaning to this flag. For example, 0 might mean the switch has not been pressed, and 1 might mean the switch has been pressed. The big arrows in this figure signify synchronization links between the threads. In the example on the left, the ISR signals the semaphore and the main program waits on the semaphore. In the example on the right, the main program signals the semaphore and the ISR waits. In this particular application, if the ISR is running and the semaphore is 0, the action is just skipped and the computer returns from the interrupt.

The second inter-thread synchronization scheme is the mailbox. The mailbox is a binary semaphore with associated data variable. Interactive Tool The mailbox structure is implemented with two shared global variables. Mail contains data, and Status is a semaphore flag specifying whether the mailbox is full or empty.

A mailbox can be used to pass data between threads. Use the following tool to how the foreground and background thread communicate using a "mailbox".

Using the tool demonstrates that during execution of block A, the mailbox is empty, the input device is idle and the main program is performing other tasks, because mailbox is empty. When new input data are ready, the trigger flag will be set, and an interrupt will be requested.

The main program recognizes Status is full in Block C. In Block D, the main program processes data from Mail , sets Status to empty. Notice that even though there are two threads, only one is active at a time. Figure illustrates schematically the relationships between the main descriptors that represent the state of the IRQ lines. The figure does not illustrate the data structures needed to handle softirqs and tasklets; they are discussed later in this chapter.

Identifies the interrupt service routines to be invoked when the IRQ occurs. The field points to the first element of the list of irqaction descriptors associated with the IRQ. The irqaction descriptor is described later in the chapter. A set of flags describing the IRQ line status see Table Shows 0 if the IRQ line is enabled and a positive value if it has been disabled at least once.

Counter of unhandled interrupt occurrences on the IRQ line for diagnostic use only. An interrupt is unexpected if it is not handled by the kernel, that is, either if there is no ISR associated with the IRQ line, or if no ISR associated with the line recognizes the interrupt as raised by its own hardware device.

Usually the kernel checks the number of unexpected interrupts received on an IRQ line, so as to disable the line in case a faulty hardware device keeps raising an interrupt over and over. Because the IRQ line can be shared among several devices, the kernel does not disable the line as soon as it detects a single unhandled interrupt.

The status of an IRQ line is described by the flags listed in Table An IRQ has occurred on the line; its occurrence has been acknowledged to the PIC, but it has not yet been serviced by the kernel.

The kernel is using the IRQ line while performing a hardware device probe; moreover, the corresponding interrupt has not been raised. This is accomplished through the following statements:. This code looks in the interrupt array to find the interrupt handler addresses that it uses to set up the interrupt gates. The advantage of this object-oriented approach is that drivers need not to be aware of the kind of PIC installed in the system.

Each driver-visible interrupt source is transparently wired to the appropriate controller. This variable is initialized as follows:. Next come the pointers to six different functions used to program the PIC. The first two functions start up and shut down an IRQ line of the chip, respectively. But in the case of the A chip, these functions coincide with the third and fourth functions, which enable and disable the line.

As described earlier, multiple devices can share a single IRQ. Therefore, the kernel maintains irqaction descriptors see Figure earlier in this chapter , each of which refers to a specific hardware device and a specific interrupt. The fields included in such descriptor are shown in Table , and the flags are shown in Table This is the key field that allows many devices to share the same IRQ.

Points to the next element of a list of irqaction descriptors. The elements in the list refer to hardware devices that share the same IRQ. The device may be considered a source of events that occurs randomly; it can thus be used by the kernel random number generator.

Set of flags denoting the pending softirqs see the section " Softirqs " later in this chapter. Number of occurrences of NMI interrupts. Linux sticks to the Symmetric Multiprocessing model SMP ; this means, essentially, that the kernel should not have any bias toward one CPU with respect to the others.

As a consequence, the kernel tries to distribute the IRQ signals coming from the hardware devices in a round-robin fashion among all the CPUs. In particular, the task priority register TPR of each chip is initialized to a fixed value, meaning that the CPU is willing to handle every kind of IRQ signal, regardless of its priority.

The Linux kernel never modifies this value after its initialization. All task priority registers contain the same value, thus all CPUs always have the same priority. Because such values are automatically changed after every interrupt, the IRQ signals are, in most cases, fairly distributed among all CPUs. No other CPUs are notified of the event. All this is magically done by the hardware, so it should be of no concern for the kernel after multi-APIC system initialization.

Unfortunately, in some cases the hardware fails to distribute the interrupts among the microprocessors in a fair way for instance, some Pentium 4-based SMP motherboards have this problem. Therefore, Linux 2. The exception stack is used when handling exceptions including system calls. The hard IRQ stack is used when handling interrupts.

As with other context switches, the need to save registers leaves the kernel developer with a somewhat messy coding job, because the registers have to be saved and restored using assembly language code. However, within those operations, the processor is expected to call and return from a C function. In this section, we describe the assembly language task of handling registers; in the next, we show some of the acrobatics required in the C function that is subsequently invoked.

Saving registers is the first task of the interrupt handler. As already mentioned, the address of the interrupt handler for IRQ n is initially stored in the interrupt[n] entry and then copied into the interrupt gate included in the proper IDT entry.

S file. The element at index n in the array stores the address of the following two assembly language instructions:. The result is to save on the stack the IRQ number associated with the interrupt minus The kernel represents all IRQs through negative numbers, because it reserves positive interrupt numbers to identify system calls see Chapter The same code for all interrupt handlers can then be executed while referring to this number.

The macro then loads the selector of the user data segment into ds and es. It is declared as follows:. In particular, the function performs the following substeps:. If the two addresses are equal, the kernel is already using the hard IRQ stack, thus jumps to step 3. This happens when an IRQ is raised while the kernel is still handling another interrupt.

It uses address ranges at the top of its address space, Fh and above up near 4 GB , to provide additional memory ranges for which there is inadequate room in UMA. Windows 98 does the same, but also uses memory ranges immediately above the end of the range occupied by physical RAM.

Memory range conflicts are seldom a problem on modern computers running recent versions of Windows. Windows 9X and Windows NT both provide convenient means to view the resources that are in use. To view system resources with Windows or Windows XP in Classic Mode , right-click My Computer, choose Properties, display the Hardware tab, and then click the Device Manager button to display the dialog shown in Figure , which lists all installed devices.

If a problem exists with a device a resource conflict, missing driver, etc. To view a global list of resources, click the View menu and select the Resources by Type option to display the Device Manager window shown in Figure Expand the listing for the type of resource you want to view. To view all resources being used by a particular device, expand the Device Manager tree see Figure , double-click the device name to display the Properties sheet for that device, and display the Resources tab. The Resource type pane displays all resources assigned to that device, although you may have to scroll the list to see all items.

The Properties sheet for a device lists all resources allocated to that device. To view system resources with Windows 98, right-click My Computer, choose Properties, and click the Device Manager tab to display the System Properties dialog shown in Figure , which lists all installed devices. To view a global list of resources, double-click the Computer branch to display the View Resources page of Computer Properties, shown in Figure Choosing any of the four option buttons immediately displays a global list of assignments for that resource, allowing you to determine easily which resources are unassigned.

To view all resources being used by a particular device, expand the Device Manager tree see Figure and double-click the device name to display the Properties sheet for that device. The Resource type pane displays all resources assigned to that device. If a resource conflict exists, Windows 98 displays a list of other devices using the same resource s in the Conflicting device list pane.

For such situations, Windows allows you to specify manually which resources these older cards require, removing them from the pool of resources that Windows manages automatically. Display Device Manager and click the Reserve Resources tab to display the dialog shown in Figure This dialog lists any resource reservations already in effect, and allows you to modify existing reservations and add new reservations.

Mark one of the four option buttons to select the type of resource for which you want to add a reservation or view existing reservations. The Reserve Resources dialog allows you to remove resources from the pool available to Windows and assign those resources manually to legacy devices. To add a resource reservation, click Add to display the Edit Resource Setting dialog, whose appearance varies depending on the type of resource you are adding a reservation for.

Figure shows the dialog for reserving an IRQ. Use the up and down arrows to specify a value for the resource to be reserved and click OK. You can reserve multiple resources in a single session by repeatedly selecting resource type and adding reservations.

When you finish reserving resources, click OK to store the resource reservations and then restart the system to put the changes into effect. The Edit Resource Setting dialog allows you to specify the resource to be reserved. Device Manager initially displays reserved resources as System Reserved, as shown in Figure However, once you restart the computer, that resource will no longer be displayed in Device Manager.

Be very careful when reserving resources. Windows 98 allows you to reserve any resource, including ones that are already in use. Reserving an in-use resource may disable the device that is currently using that resource.

However, if you are installing a legacy ISA card on a Windows NT system, you need to configure it to use resources that are not already in use. The Windows NT Diagnostics Resources page displays a global list of assigned resources of the type selected. Click the Devices button to display a list of installed devices, shown in Figure We physically installed the card, but when we attempted to install the drivers, Setup could not locate the card.

This problem, described in the Microsoft Knowledge Base article Q, can be resolved by installing the Pnpisa.