QNX Driver Development-Interrupt handling (reprint)

Original URL: http://blog.csdn.net/daniellee_ustb/article/details/7841894

In the operating system, the processing of interrupts is always a nuisance, in fact, the operating system is not familiar with the interrupt management mechanism. When the interrupt is generated, the kernel executes the interrupt service ISR, the interrupt service program should do as little work as possible to improve the efficiency of the system execution, some people in the interrupt service program using the delay function and the printf function and malloc function is very undesirable. The delay function not only greatly reduces the efficiency of the interrupt execution, but also may mask the next interrupt, thus losing the response to the interrupt. Why not for the printf function? Can be explained in terms of the output principle. By calling the printf function, the string is exported to the console when it is called to the serial port, where the volume of the semaphore and blocking operations, will increase the execution time of the interrupt service program; malloc is a non-reentrant function that will have disastrous consequences if it is not returned. In order to minimize the time of the Interrupt Service program execution and reduce the scheduling wait time, the best way to implement the ISR in the operating system is to set the flag to construct a short ISR when the interrupt occurs, and the other work to create the corresponding thread to execute separately. Just like someone calls you, when you suddenly receive a task instruction is to listen to the phone and spend a lot of time to finish, or hang up the phone to do specific tasks? Of course the latter, but most people still choose to put everything in the Interrupt service program to deal with, in fact, is very unscientific.

When the hardware interrupts, the interrupt line is pulled high until the ISR is interrupted. However, if the Interrupt service program forgets to clear the interrupt flag, then when the interrupt program finishes executing, the pic will be repeatedly executed due to an interrupt detection, so there is a problem! So a good way to do this is to clear the interrupt flag as soon as you enter the interrupt program.

So how do you write an interrupt in QNX? QNX offers two ways to connect interrupts:

int interruptattachevent (int intr, const struct sigevent *event, unsigned flags);

int Interruptattach (int intr, const struct sigevent * (*handler) (void *arg, int id), const void *area, int size, Unsigne D flags);

where int intr represents the interrupt vector number, it is written in the data sheet when the pic is initialized in startup, which indicates which interrupt occurs when the corresponding ISR is executed.

First take a look at the first function, interruptattachevent, this function tells the system to return an event when the hardware is interrupted to indicate which thread to perform the specific task, of course, in this thread must first block the interrupt source to avoid the task has not finished the time to interrupt again. When this function is called, it is similar to the query mechanism, and its trunk is as follows:

struct Sigevent event;

IntId = Interruptattachevent (HW_SERIAL_IRQ, &event, 0);

Thread_a ()

{

for (;;) {

Interruptwait (0, NULL);

Interruptunmask (HW_SERIAL_IRQ, intId);//get next Event

Clearinterruptstatus ();

Dosth ();

}

}

When an interrupt occurs, the interruptwait captures the event and processes it accordingly for different tasks. However, for the above mentioned skeleton program, may have some doubts, why just found the interruption to open the interrupt screen, instead of waiting for the interruption of the line after? Considering that if a hardware is producing faster, then we first deal with the possibility of losing the interrupt processing when the interrupt shield is turned on. Here the interruptwait can queue all the received event, and the interrupt request that is not processed in time will be processed later, which solves the above problem well.

Look at the second function, Interruptattach, this function in the event of an interruption directly called the handler interrupt handler function, is the real ISR, the function used in the global variables to use the volatile keyword decoration, Tell the compiler that this is a variable that will be changed in the interrupt and other threads, and all operations on it will be read from the source address, otherwise an error may occur. Why does this function return an event, because it can wake up the corresponding thread to do something specific.

Which is better for these two functions? Obviously each function has its own pros and cons, depending on the situation. interruptattachevent (), simple to use, running in user space, can inspire a separate thread to handle a particular task, but while it works, it will cause context switching whenever it breaks down, reducing efficiency. For Interruptattach (), because it is the ISR that interrupts the original thread, the production does not produce a new process that is determined by the ISR, so the expense of context switching can be reduced for interrupts that are not handled by themselves.

QNX Driver Development-Interrupt handling (reprint)