Windows CE 6.0 interrupt handling process

Here we mainly discuss the general process of CE's interrupt establishment and interruption, as well as the involved code location. What we will talk about here is for the ARM platform. In the CE interrupt processing, some work is completed by the CE kernel, and some work is completed by the OEM.

Kernel code work

Exvector. S: interrupt vector definition, which defines the address of the armtrap. s function.

Armtrap. S: Definition of interrupt processing. The most important function is the irqhandler function, and the most important function is call oeminterrupthandler.

Mdarm. C: interrupt vector Loading

Kdriver. c: nkcallintchain function: converts IRQ to sysintr. It is worth noting that pintchaintable [] is the entry to the ISR processing program corresponding to IRQ. The main function is pfnhandler. Pfnhandler filling is in hookintchain, which is called by ISR during initialization. In this function, if pintchaintable is null, sysintr_chain is returned. If pintchaintable [] is not empty, pfnhandler is called to obtain a sysintr value and then return it.

 

OEM defined work: oalintr. C: oeminterrupthandler function. by querying the hardware interrupt register, obtain the hardware IRQ Number. For the interruption of the EINT04-23, the corresponding system IRQ is obtained through the eintmask register. Note that IRQ is defined by Ce and is an extension of system hardware IRQ. Call nkcallintchain to check whether the IRQ is an interrupt of a chain. If the function returns sysintr_chain or an invalid sysintr, The IRQ is converted to sysintr through oalintrtranslateirq. If it is a valid sysintr, this value is returned.

 

The device of a single ISR is mainly processed by oeminterrupthandler. IRQ is not defined in oeminterrupthandler. It can be associated through the hookinterrupt function in oal or driver loading.

Devices with multiple ISRs are usually required by bus devices because several devices are usually listed on the bus devices. For devices on these bus, an ISR is required to determine which device is interrupted. This ISR is a DLL program. The device driver must load this DLL program through loadintchainhandler (file name, function name, IRQ) during initialization. Loadintchainhandler is defined in nkloadintchainhandler of kdriver. C. For most bus devices, you can use the giisr. dll that has been written by Microsoft. The implementation code of giisr is under public \ common \ oak \ drivers.

 

If you use giisr for a bus device, the principle is as follows:

The driver of the bus device loads giisr through loadintchainhandler during initialization. When loading, loadintchainhandler will call the createinstance of giisr to create an instance, and giisr will return an index value to loadintchainhandler, to indicate the instance. loadintchainhandler returns a handle to the driver, and the driver accesses giisr Based on the handle. After obtaining the handle, initialization also requires reading the relevant initialization parameters from the reg table and assigning values to giisr, such as port address, mask address, and sysintr.

 

When the driver is initialized:

1. Create an event (createevent)

2. Use the interruptinitialize function to associate sysintr with this event.

3. Kick-off a thread (IST)

4. This thread is eventually waitforsingleobject (eventid)

For specific examples, see the usbfn example: In sc2410pdd. CPP, the ufnpdd_start function;

 

Repost: http://space.itpub.net/16918737/viewspace-504351