Windows CE Driven Development basics

This is my first time since January 6 to host the Tenkine Forum Embedded Development version of the article, plus the previous trivial articles amounted to 30. The more research on the more I feel that I understand too little, in fact, in the driving development of I am still a rookie, I want to make a point again, so that the people who drive have n years of experience to dedicate a bit out, so that we reduce some of the research driven by the source code and the lack of

I think that even though the reader has seen the driver in Microsoft's Training kit and CE help document, the mind is still in a daze. To really understand the driver must combine some of the driver source code, here I use the serial port driver (COM16550) in the initialization process as a clue to the basic knowledge of driving development.

Windows CE serial driver can handle all I/O behavior similar to the serial device, including based on 16450, 16550 UART (Universal Asynchronous transceiver Chip) and some of the use of DMA equipment, common 9-pin serial, infrared I/O port, modem and so on. In the%_winceroot%\public\common\oak\drivers\serial directory, the COM_MDD2 subdirectory contains the new serial port driver MDD layer function code. The COM16550 subdirectory contains serial port driven PDD layer code. The SER16550 subdirectory contains a series of functions designed to control a 16550-compliant UART, so that the main task of the PDD layer is to invoke functions in SER16550. There is also a ISR16550 subdirectory that contains an installable ISR (interrupt Service routine) dedicated to the serial driver, while many hardware device drivers use the CE default installable ISR Giisr.dll. General serial device corresponding registry settings examples and significance are as follows:

Key	Significance
"SysIntr" =dword:13	The interrupt ID for serial 1 is decimal 13
"Iobase" =dword:02f8	The first address of the IO space of serial 1 is hexadecimal 2f8
"Iolen" =dword:8	The IO space length of serial 1 is 8 bytes
"Devicearrayindex" =dword:0	The index of serial 1 is the origin of 1
"Order" =dword:0	Serial 1-driven loading sequence
"DeviceType" =dword:0	Device type for serial 1
"Devconfig" =hex:10,00 ....	Serial port 1 in the communication with modem equipment configuration, such as baud rate, parity school inspection, etc.
"FriendlyName" = "COM1:"	Serial 1 name displayed in the dialer
"Tsp" = "Unimodem.dll"	The TSP (TAPI Service provider) DLL to be loaded when the serial port 1 is used to communicate with modem devices
"Prefix" = "COM"	Prefix of the stream interface for serial 1
"Dll" = "com16550." Dll "	Driver dll for serial 1

SYSINTR is predefined by CE in file Nkintr.h to uniquely identify the interrupt device. OEMs can define their own sysintr in the file Oalintr.h. Common predefined sysintr have Sysintr_nop (interrupts only by ISR processing, ist no longer processing), sysintr_resched (rescheduling thread), sysintr_devices (base value of a CE-predefined device interrupt ID), SYSINTR _profile, sysintr_timing, sysintr_firmware, etc. are all based on the sysintr_devices definition. Iobase is the first address of the IO address space of serial 1, Iolen is the size of Io space. The IO address space exists only on the x86 platform, and if the hardware registers on other platforms must be mapped to the physical address space, the name of the subkey is Membase and Memlen. The registers of more hardware on the x86 platform are also mapped to physical address spaces due to the limitations of IO space. Devicearrayindex is the index of the device used to differentiate between devices of the same type. prefix is the prefix of the stream driver, when the application calls the CreateFile function to pass COM1: parameter, the file system is responsible for communicating with the serial driver, the serial driver is loaded by Device.exe when the CE starts.

The following is an initial exploration of the serial-driven initialization process from the MDD layer function Com_init. Com_init is called after the serial device is detected by the Device Manager Device.exe, the main function is to initialize the device, its unique parameter identifier is passed by Device.exe, its type is a string pointer, the content of the string is hlm\ The drivers\active\xx,xx is a decimal number (Device.exe tracks each driver in the system and records the loaded driver under the Active key). Com_init first assigns a hw_indep_info structure, this structure is independent of the serial Hardware header information (MDD, PDD, SER16550 all contain their own unique structure, the specific structure of the definition see serial drive source), After the assignment, each member of the structure is initialized, and the Opendevicekey ((LPCTSTR) Identifier) is opened after the structure is initialized to open the Hlm\drivers\active\xx\key contained registry path, where the path is generally hlm\ Drivers\builtin\serial, that is, the location of the driver information for the serial port in the registry. Com_init then queries the Devicearrayindex, Priority256 values under Hlm\drivers\builtin\serial, Priority256 specifies the priority of the driver, and if not, the default priority. Next Call Getserialobject (Devicearrayindex), which is defined by the PDD layer, and returns the Hwobj structure, which contains pointers to the PDD and SER16550-defined functions. That is, MDD calls this function to invoke the underlying implementation function. The next most work is to invoke the underlying function implementation initialization. The first call to the underlying function serinit the primary setting of the hardware configuration set by the user, such as line control, baud rate. It calls the Ser_getregistrydata function to get the hardware information stored in the registry, Ser_getregistrydata the DDKREG_GETISRINFODDK and Ddkreg_ provided by the internal call system The Getwindowinfo function gets the IRQ, SysIntr, Isrdll, ISRHandler, Iobase, Iolen, saved under Hlm\drivers\builtin\serial. IRQ is a logical interrupt number, Isrdll represents the name of the DLL in which the current driver's installable ISR resides, ISRHandler represents the name of the function that can install the ISRSaid. By the way, you can install an ISR here, and in my previous article on OAL, the reader can learn that OEMs associate IRQ and SYSINTR in the Oeminit function, and when a hardware device interrupts, the ISR prohibits sibling and low-level interrupts, and then returns the associated SYSINTR based on the IRQ , the kernel wakes up the corresponding IST (sysintr with the event created by the IST) based on the SYSINTR returned by the ISR, and calls InterruptDone after the IST process interrupt to unblock the interrupt. The disadvantage associated with Oeminit is that once the CE kernel has been compiled, the association cannot be added, and some hardware devices are plugged in or shared interrupts at any time, and the hardware solution to the connection is to install the ISR, which can be installed to handle interrupts from specified hardware devices. So if the hardware device requires an installable ISR, you must add Isrdll, ISRHandler to the registry. Most hardware devices adopt the CE default installable ISR Giisr.dll format as follows:

"IsrDll"="giisr.dll"
"IsrHandler"="ISRHandler"

If a hardware driver requires an ISR to be installed and the developer does not want to write one on its own, it can be implemented using Giisr.dll. In addition to adding as shown above in the registry, call the relevant function registration in the driver to install an ISR. Pseudo code is as follows:

g_IsrHandle = LoadIntChainHandler(IsrDll, IsrHandler, (BYTE)Irq);
GIISR_INFO Info;
PHYSICAL_ADDRESS PortAddress = {PhysAddr, 0};
TransBusAddrToStatic(BusType, dwBusNumber, PortAddress, dwAddrLen, &dwIOSpace, &(PVOID)PhysAddr)
Info.SysIntr = dwSysIntr;
Info.CheckPort = TRUE;
Info.PortIsIO = (dwIOSpace) ? TRUE : FALSE;
Info.UseMaskReg = TRUE;
Info.PortAddr = PhysAddr + 0x0C;
Info.PortSize = sizeof(DWORD);
Info.MaskAddr = PhysAddr + 0x10;
KernelLibIoControl(g_IsrHandle, IOCTL_GIISR_INFO, &Info, sizeof(Info), NULL, 0, NULL);