Interrupt handling load in wince oal)

OAL mainly implements ISR for wince interrupt handling. Generally, ist is implemented in the device driver. We recommend an article on WinCE's interrupted architecture, as follows:

Http://msdn.microsoft.com/zh-cn/library/ms836807.aspx

 

We recommend that you read this article first if you are not familiar with the wince interrupt. Architecture

 

 

This figure must have been seen by many people. The main figure is too classic, so I am stuck with a few nagging words. After the hardware is interrupted, the kernel ISR will run, then the ISR in oal is used to handle the corresponding interruptions, and finally the corresponding ist operation completes the real interrupt processing. Therefore, in wince, the interrupt processing is completed by ISR and ist. ISR mainly determines the interrupt source, blocks the interrupt and returns the system interrupt number to the kernel. ISR should be as short as possible. Ist completes real interrupt processing, such as data transmission and parsing. Of course, not all interrupt processing requires ISR and ist. For example, if the timer of the wince system is interrupted, only ISR is required.

 

To support interrupt in oal, You need to implement the following interrupt processing functions:

1. bool oeminterruptenable (DWORD sysintr, void * pdata, DWORD datasize)

Sysintr: The system interrupt number to be enabled

Pdata: The passed Data Pointer, which is passed in by the interruptinitialize function.

Datasize: size of incoming data

This function is used to interrupt a certain hardware. When the device driver calls interruptinitialize to initialize an interrupt, the kernel will call this function to interrupt the corresponding hardware.

 

2. Void oeminterruptdisable (DWORD sysintr)

Sysintr: the number of system interruptions to be blocked

This function is used to block a hardware interruption. If the device driver calls the interruptdisable function, the function is called.

 

3. Void oeminterruptdone (DWORD sysintr)

Sysintr: the number of system interruptions to be re-Enabled

This function indicates the completion of an interrupt processing process. When the device driver calls the interruptdone function, the function is called and the corresponding hardware is interrupted.

 

4. ulong oeminterrupthandler (ulong RA)

RA: Command count, which does not make much sense in actual application.

When a hardware interruption occurs, the function is called to complete the interruption processing of the ISR part. Generally, the system interrupt tag is read in this function to determine the interrupt source and return the corresponding system interrupt number.

 

5. Void oeminterrupthandlerfiq (void)

For arm processors, this function is used to handle fast interruptions.

 

The above five functions have completed interrupt-related processing. Two concepts are mentioned here: IRQ and sysintr. IRQ refers to physical interruption or hardware interruption, while sysintr refers to system interruption, which is also called virtual interruption or logical interruption. I personally think it is better to call system interruption. Each IRQ corresponds to a system interrupt sysintr. When a hardware interrupt occurs, ISR actually processes the IRQ interrupt and then returns the sysintr to the kernel, the kernel will trigger the corresponding ist based on the corresponding sysintr to complete the interrupt processing.

The ing between IRQ and sysintr is called ing, which can be divided into static ing and dynamic ing. Static ing means that at system compilation, IRQ is already matched with sysintr, which is generally implemented through the oalintrstatictranslate function. Dynamic ing refers to the dynamic Association of IRQ and sysintr after the wince system is started, generally through kerneliocontrol (ioctl_hal_request_sysintr ...) .

 

The sysintr type is defined in nkintr. h. After the oeminterrupthandler function finishes processing the interrupt, it returns different types of sysintr to the kernel. The Kernel performs the next operation based on the return value, which is divided into the following types:

Sysintr_nop: indicates that no processing is required.

Sysintr_resched: indicates that a system scheduling is required.

Sysintr_chain: indicates that the source of the interrupt is not generated. Find the next interrupt in the interrupt chain.

Sysintr_rtc_alarm: indicates that the RTC alarm is generated.

Sysintr_timing: used for iltiming Testing

Sysintr_profile: system profile

Sysintr_firmware: Used to customize the system interrupt number. All custom system interrupt numbers should be added with 1 based on this value. These custom system interrupt numbers are used to correspond to IRQ one by one.

 

In the past, to implement the interrupt section in oal, we needed to create an IRQ table and a sysintr table, then implement the five functions mentioned above, and implement an interruptinitialize function, this function is used to initialize the interrupt and will be called in oeminit. Since wince5.0 and later, Microsoft has proposed the pqoal architecture, and the implementation of interruptions has become "tortuous. The functions to be implemented are as follows:

1. bool oalintrinit ()

This function is an interrupt initialization function that will be called in oeminit to initialize system interruptions and complete static ing of some interruptions.

 

2. bool oalintrrequestirqs (device_location * pdevloc, uint32 * pcount, uint32 * pirqs)

Pdevloc: A device_location structure pointer containing device information

Pcount: indicates the maximum number of IRQ as input and the actual number of IRQ as output.

Pirqs: points to an actually obtained IRQ array.

This function is used to obtain IRQ information through the physical address of the device. It is generally used for bus devices.

 

3. bool oalintrenableirqs (uint32 count, const uint32 * pirqs)

Count: Number of IRQ to be enabled

Pirqs: The IRQ array to be enabled

This function is used to enable IRQ interruption. This function will be called by the oeminterruptenable function.

 

4. Void oalintrdisableirqs (uint32 count, const uint32 * pirqs)

Count: How many IRQ will be disabled

Pirqs: IRQ array to be disabled

This function is used to disable IRQ interruption. This function will be called by the oeminterruptdisable function.

 

5. Void oalintrdoneirqs (uint32 count, const uint32 * pirqs)

Count: Number of IRQ to be re-Enabled

Pirqs: IRQ array to be re-Enabled

This function is used to re-enable IRQ interruption and will be called by the oeminterruptdone function.

 

In addition to the above five functions, an important function to be implemented is oeminterrupthandler. This function has been described earlier and will not be mentioned here. In fact, after wince5.0, there is a "map." In the/platform/common/src/common/intr/base directory. C "file, which implements interrupt-related interface functions, implements dynamic/static ing of interruptions, and completes the conversion between sysintr and IRQ, we only need to implement hardware interruption operations and initialization.

 

Finally, let's talk about several functions as follows:

Bspintrinit: called by the oalintrinit Function

Bspintrenableirq: called by the oalintrenableirqs Function

Bspintrdisableirq: called by the oalintrdisableirqs Function

Bspintrdoneirq: called by the oalintrdoneirqs Function

Bspintrrequestirqs: called by the oalintrrequestirqs Function

 

These functions can be called board-level interrupt processing functions. These functions are a little redundant and generally implemented in oalintrinit, oalintrenableirqs, oalintrdisableirqs, oalintrdoneirqs, and oalintrrequestirqs, however, this is a processor-level implementation. modifications may be made to different boards based on the same processor. These modifications can be completed in bspintrinit, bspintrenableirq, bspintrdisableirq, bspintrdoneirq, and bspintrrequestirqs.

 

Here, the interrupt processing functions in oal are basically described. I think the best way to understand this is to read the code. Generally, in oal, you only need to perform operations such as switch interrupt and clear interrupt mark bits. The real data processing is handed over to ist. However, in some cases, the interruption of some special devices is frequent, and the IST is too late to respond. The solution is to save the data in a piece of memory in the ISR, and then, as needed, every several hardware interruptions return a system interruption, which activates the IST to read the data at a time. One problem involved here is to share data in ISR and ist, in config. you can reserve a shared memory in bib.

 

This article from the csdn blog, reproduced please indicate the source: http://blog.csdn.net/nanjianhui/archive/2009/03/03/3953466.aspx