Analysis of Design Method of Interface Drive Based on USB Device.

Last Update Time: 2020-10-17 10:35:14

      With the continuous increase of USB2.0 devices, USB device driver development becomes more and more important in embedded development. Windows CE's support for USB 2.0 is a huge boost to this new wave of technology. Recently I am in charge of a project like this to develop peripheral device drivers for USB interfaces under WinCE. It took me quite a lot of time and energy to do this project at the time, and taking many wrong paths made me exhausted.

      The project requirement is to develop a driver for the USB WiFi wireless network card on the adjusted ARM9 board. The specific requirement is that the driver platform is WinCE, the CPU type supports the ARM architecture, and it must be easier to port to X86; the driver interface type is USB2. 0 and Wlan 802.11b. Later, because the connection efficiency has always been problematic, they changed from east to west, and the last change was a mess.


image.png


What is a WinCE device driver?

     (1) Distinguish from driver loading method

      Before delving into the peripheral device drivers supported by Windows CE, first understand the two devices used on the WinCE platform: built-in devices and installable devices. Therefore, from the perspective of driver loading, WinCE can be divided into native device drivers (Built-In Driver), loadable drivers (Loadable Driver), and hybrid drivers.

     ① Local device driver

      Native device drivers are Native Device Drivers. WinCE is designed to use built-in devices directly.                These devices are controlled by the native driver process, and the native driver is closely connected to the core components of WinCE. The devices corresponding to these drivers are usually loaded in the GWES process space when the system starts, so they do not exist as independent DLLs, and therefore each native driver must be called with a device driver interface (DDI ) The specific interface is consistent.

       Local devices are devices integrated into the platform, including display, touch panel, audio, serial port, LED, battery, and PC card sockets. Without these local devices, the entire system cannot communicate with user information, such as touch panels and displays. Native drivers are generally designed as dynamic link libraries, with two exceptions: battery and LED drivers are designed as static libraries due to their small size (linked to the GWES module when building CE images). The corresponding drivers for these devices were developed by the OEM during the WinCE platform development process and they are stored in ROM or flash memory. Usually only the OEM will modify the native device driver, other free device manufacturers only provide additional hardware devices, there will not be too much involved in the native device driver.

      ② Loadable device driver

       Loadable devices refer to third-party interface devices that can be connected to and separated from the platform and can be installed and uninstalled by the user at any time. Such peripheral device drivers are also called stream drivers. These drivers can be dynamically loaded by the device manager at system startup or at any time after startup. Usually such drivers exist in the form of DLL dynamic link libraries.               After the system is loaded, these drivers only run in user mode. The loadable driver obtains commands from the device manager and applications through the file manipulation API. Typical loadable drivers in WinCE are: PCMCIA driver (PCMCIA.dll), Serial driver (SERIAL.dll), ATAFLASH driver (ATA.dll), Ethernet driver (NE2000.dll, SMSC100FD.dll).

      Unlike native drivers, all loadable stream drivers share a common interface. The interface consists of 10 functions or record points within each driver that match the functions in the file API used by the application. Therefore, the stream interface driver that controls the loadable device is generally accessed by the application program. The stream interface driver uses a special file to show the device functions to the application program. The file can be opened, read, written, and closed. For example, after a user connects a GPS device to the platform, he can launch a GPS-enabled application to access and use the device. WinCE uses existing APIs to allow applications to access these drivers, rather than creating new APIs.

      (2) Classification from the driver level

      Generally can be divided into two types of independent drive and hierarchical drive. Independent driver refers to the driver is written as an independent driver that contains both the Model Device Driver (MDD) and Platform Dependent Driver (PDD) layers. The advantage of using an independent driver is that it can save the information transfer between the MDD and PDD layer drivers, which is very important in real-time processing. Independently driven code includes interrupt service routines and platform-dependent processing functions. In addition, if the operation of the device is consistent with the interface description of the MDD driver layer, using separate drivers can improve processing performance.

       Hierarchical driving refers to two layers, the MDD of the upper layer and the PDD of the lower layer. MDD implements platform-independent functions. It describes a general driver framework; PDD is composed of hardware and platform-related code. MDD calls specific interfaces in PDD to obtain hardware related information. When using a layered driver, you generally only need to use a similar sample driver, modify only the PDD program for specific hardware, and the framework established by MDD can continue to be used. However, due to the layer-by-layer call of the inter-layer interface and the passing of messages, the processing speed is slower than that of the independent driver. Therefore, in the harsh environment of embedded real-time requirements, hierarchical drivers are not very suitable.

      To put it simply, the independent driver writes PDD and MDD together without strict distinction. Usually this driver is relatively simple, such as ATADIK. As for the native driver and load-type stream driver, they are classified from the interface between the driver and other modules (callers) of the system. Therefore, a load driver can be a stand-alone streaming driver, such as ATADISK, or a layered streaming driver, such as OHCI. In other words, independence and layering are classifications on the driver implementation, while native and load streaming are classifications on the driver model. The so-called native driver is that the operating system has a reserved special interface, and loading the streaming driver refers to the interface for writing DLL files to export various streaming interface functions.

 

If you want to know more, our website has product specifications for the USB Device you can go to ALLICDATA ELECTRONICS LIMITED to get more information