Interrupt handling process in WinCE (driven by developers)

Interrupt handling process in WinCE (driven by developers)
Interrupt is an important way to deal with hardware and software. Therefore, most drivers involve interrupt processing. In this article, we will look at the drivers and BSP developers, to talk about the interrupt handling process in Windows CE.
If a driver needs to handle an interrupt, the driver needs to create an event first. You can use the createevent function and call interruptinitialize to bind the event to the interrupt number, this step will cause the interruption, and the oeminerrupteenable in OAL will be called. If this function does not return true, interruptinitialize will fail. Then, the IST function in the driver can use the waitforsingleobject function to wait for interruption.
When a hardware interruption occurs, the operating system encounters an exception. The interrupt vector indicates the CE exception handler. The exception handler then calls the oeminterrupthandler function of OAL. After this function detects the hardware, convert the hardware interruption to the software interrupt number and return it to the system. The interrupt number is the one used in interruptinitialize mentioned above. After obtaining the interrupt number, the system finds the event corresponding to the interrupt number and wakes up the thread waiting for the event (IST). Then, the IST can process the interrupt in the user State. After the process is completed, ist needs to call interruptdone to tell the operating system that the interrupt processing is complete. The operating system calls the oeminterruptdone function in oal again to complete the interrupt processing.
In the above description, the driver needs to use three functions: interruptinitialize, waitforsingleobject and interruptdone. BSP developers need to mainly consider three functions: callback, oeminterrupthandler, and oeminterruptdone. Of course, this is some of the functions mentioned above. In fact, BSP developers still need to consider init, disable, and other functions in the interrupt section. We will not discuss them here.
The first time you modified the wince driver
We have a product that requires the customer to take control of the shutdown. ask the customer to enter the password before shutdown. at first, I thought it was easy to intercept the wm_queryendsession or pbt_apmquerysuspend message, but I couldn't try it. After a long time, I found that wince didn't support the two messages, so I had to find a solution. that is, start with the eint0 reset button driver.
The result of pcienum.exe is output to the serial port or other output devices. You can change the code to make the output information local. The Code is as follows:
# Include <stdio. h>
File * stream;
Debuuplintf (ptchar pszformat ,...)
{
Static tchar szstring [256];
Static uchar szansistring [256];
Static int hconsole;
Va_list ARGs;
Va_start (ARGs, pszformat );
Wvsprintf (szstring, pszformat, argS );
/// Outputdebugstring (szstring );
Stream = _ wfopen (L "\ Windows \ pci.txt", l "A + ");
Fseek (stream, 0l, seek_end );
Fputws (szstring, stream );
Fclose (Stream );
Va_end (ARGs );
}