Introduction
Wince5.0 is a 32-bit, multi-task, multi-thread real-time embedded operating system. USB camera is widely used for its excellent performance and low price. It is easy to integrate into embedded systems due to its flexibility and convenience.
By using USB camera, you can conveniently obtain real-time images under wince5.0. However, due to the diversity of embedded hardware environments and the fact that wince5.0 only provides some underlying support for USB driver development, camera manufacturers have not yet provided drivers for USB cameras under wince5.0, therefore, developing a USB camera driver under wince5.0 has practical significance and value. This article studies the development of USB driver for wince5.0 and designs a USB camera Driver Based on the stream interface driver model. The developed driver is applicable to the zc030x plus series of cameras. Samstmg 2410 is the hardware platform of the experiment.
1. USB Bus drive frame for wince5.0
A usb system consists of a USB host, one or more USB devices, and a physical bus. The host is divided into two layers: the high software layer that contains the driver of the USB device and the host controller hardware layer, also known as the "adaptation layer ". The main task of the host is to control two-way data transmission to the USB device. A physical bus is a set of USB cables used to connect controllers with peripheral devices. The USB system software of wince5.0 consists of two layers: the USB driver layer and the underlying USB function layer implemented by wince5.0.
USB device drivers use USB functions to establish connections with the devices they control and configure and communicate with these devices. The lower USB function layer is composed of two parts: the higher general serial bus driver (usbd) module and the lower master controller driver (HCD) module. HCd provides an abstract host controller and abstracts the data transmission of the USB system seen by the host controller. Usbd provides an abstract device that abstracts data transmission between usbd customers and USB device functional components. The USB driver uses the usbd interface function to communicate with the peripheral device.
Ihv and USB device manufacturers use the functions provided by usbd to implement USB device drivers. The OEM is responsible for providing the HCD module for the Wince-based platform so that the corresponding hardware can interact with the usbd module. Figure 1 shows the layers of software corresponding to the USB hardware and peripheral devices of the host.
2 wince5.0 downstream Driver Model
Two dedicated driver models based on the wince5.0 platform are: local device drivers and flow interface drivers. The local device driver is suitable for devices integrated into the wince 5.0 platform, while the latter is a general type of device driver, applicable to most peripheral devices, such as modem and printer. For most USB peripheral devices, it is suitable for developing drivers using the stream interface driver model.
A stream interface driver is a driver model that allows you to customize interfaces. Generally, the Device Manager is responsible for management. It converts the commands of the Device Manager and application into the information required for the appropriate actions of the controlled device. The stream interface driver needs to implement a set of fixed stream interface functions for use by the kernel of the wince5.0 system.
The relationship between the flow interface driver of the USB device and other components of the wince5.0 system is shown in 2. The stream interface driver interacts with the application through the file system API provided by the system, and the system completes the management of the stream interface driver, such as loading and uninstalling through the Device Manager; the stream interface driver can communicate with the underlying USB device by calling the interface functions provided by the usbd module.
The stream interface function methods used in this article are listed in Table 1.
Functions that must be output by the USB driver include:
① Usbdeviecattach (). When a USB device is connected to a computer, the usbd module calls this function. This function is mainly used to initialize a USB device, obtain information about the USB device, configure the USB device, and apply for required resources.
② Usbinstalldriver (). It is mainly used to create a driver to load the required registry information, such as read/write timeout and device name.
③ Usbuninstalldriver (). It is mainly used to release the resources occupied by the driver and delete the Registry created by the usbinstalldriver () function.
The above three function interfaces are required by all USB drivers and are indispensable.
In addition, it is important to configure the registry for the driver of the USB device. The general USB driver registry is configured under [HKEY_LOCAL_MACHINE \ drivers \ USB \ loadclients \ port, the sub-keys of each driver are in the group 1_id \ group2_id \ group3_id \ drivername format. The sub-keys of a device are composed of suppliers, devices, and protocols. Table 2 lists the allowed combinations.
Take the USB camera used in this experiment as an example. If the supplier ID of the USB cam-era is 0x046d and the device ID is 0x08a2, the loading registry should be written as follows:
It should be noted that the composition of the Registry is identified by a decimal number, and the conversion between the decimal and hexadecimal numbers should also be noted.
3. USB camera driver for wince5.0
The USB camera used in the experiment is zc030x of the 301 chipset of xingwei. Its Vid/PID is 0x046d and 0x08a2. Due to the large amount of real-time image data transfer, many USB camera products have performed data compression before image transmission. If you do not know the decoding algorithm, there is no way to obtain the image on wince. Snoopypro is mainly used during development. It is a software that can analyze USB communication data, assist in zc030x driver development, and finally develop the zc030x driver under wince5.0. The following describes how to use the data stream and necessary functions in the driver in combination with the USB camera driver development. The first is the specific registry information:
Hdevice is the handle of the current peripheral provided by the system. It can be used to obtain peripheral information, such as vid and PID. usbfuncs is the function pointer provided by the system to the usbd function, it can call usbd functions, such as getlsochresult and issuelsochtransfer. The bool value pointed to by the acceptcontrol pointer must be determined. If it is controllable, set it to true; otherwise, set it to false.
In this function, you need to determine whether the peripherals are controllable, allocate and fill in the context content of the device, and call activatedevjce () the function registers the pointer to the device context in the drivers \ USB \ clientdrivers \ camera_class key value (camera_class is the name of USB camera ), at the same time, activatedevice registers the device context pointer in the registry [HKEY_LOCAL_MACHINE \ drivers \ Active \ n], where n is an integer, which is the number automatically allocated to the driver. The system automatically calls the cam_init function when activatedevice () is called.
DWORD cam_init (lpctstr pcontext, lpcvoidip vbuscontext)
Pcontext is the content of the string automatically passed in by the system. It is also the preceding key name, that is, [HKEY_LOCAL_MACHINE \ drivers \ Active \ n]; what cam_init needs to do is to read the pointer of the device context under this key and return it as DWORD; Skip buscontext.
In usbdeviceattach (), the final task to be completed is to call the registernotifroutine function of usbd module in this function to register the devicenotify function. This devicenotify function is required. After the device is removed, the system calls this function to complete the relevant work.
Bool winapi devicenotify (lpvoid lpvpolicypa-rameter DWORD dwcode. lpdword dwinf01.lpdw0rddwlnfo2. lpdword dwlnfo3.lpdword dwlnfo4)
Ipvpolicyparameter is the context handle of the device and is passed as a parameter in registernoticationroutine. dwcode is the reason for the system to call this function. If the device is removed, the dwcode value is usb_close_device, the user uninstalls the DLL; dwinfol ,..., Dwinfo4 is not used.
Since then, the system has completed the driver loading for the added USB peripherals in USB deviceattach. When a user calls the createfile function, the system will enter the parameter value of createfile () and directly upload it to cam_open ().
DWORD cam_open (DWORD hdevicecontext, dwordaccesscode, DWORD encryption mode)
Among them, hdevicecontext is the driving context handle, which is automatically filled by the system; accesscode is the access mode, and the sharing mode is the sharing mode, which is passed by createfile; the work of cam_open is to return HDE-vicecontext in the form of DWORD, and then return it to the user as the handle value of createfile. When you call closehandle (), the system directly calls cam_close () to close a driver.
B00l cam_close (DWORD hopencontext)
The hopencontext is the reference case handle of the device driver, which is created by cam_open. In this driver, all operations on USB camera are completed by ing iocontrol () to cam_iocontrol. The following is a part of the cam_iocontrol source code analysis:
Because this driver is for USB camera, cam_write, cam_read, cam_powerup, and cam_powerdown have no content. However, the system maps the data to cam_write when you call writefile. Other functions are similar. Generally, the standard image compression algorithm is MJPEG. Zc030x adopts this algorithm to compress data. As long as the MJPEG decoding algorithm is added to the driver to restore the compressed data, the image can be correctly displayed. So far, the entire USB camera driver has been written. It has been verified through experiments that a maximum of 25 frames/s and an image size of 320x240 have been transferred.
Knot
This article introduces the USB driver framework under wince5.0, and illustrates the flow direction of the driver data in the USB driver framework based on the USB camera driver development example, it has been successfully used and practiced on the 301plus and 303 series cameras of star micro. The program design methods and ideas used have a high reference value for the design of other software similar to embedded systems.