Design and Implementation of Windows CE Display Driver Based on DM6446

As a multimedia processing chip, DM6446 launched by TI adopts ARM+ DSP dual-core architecture, with rich peripheral resources and powerful computing power, so its complex resources are generally managed effectively through the operating system. The existing platform operating system of DM6446 is mainly based on embedded Linux system, but it also has the ability to support other mainstream embedded operating systems.

Since multimedia applications often require a graphical interface, the kernel and graphical interface of the existing platform operating system Linux are separated and need to be transplanted separately. In contrast, Windows CE itself comes with a relatively excellent graphical interface, and only the display driver needs to be developed to have an excellent graphical interface. Therefore, choosing to transplant and develop other systems on DM6446 will undoubtedly give the platform program development more options and higher cost performance.

Windows CE is an embedded operating system developed by Microsoft specifically for embedded products. It has the characteristics of excellent graphical user interface, multi-tasking capability, scalability and portability, rich application software support, and good real-time performance. The Windows CE version selected in this article is Windows CE.NET 5.0, hereinafter referred to as WINCE.

1 Introduction to DM6446 chip and its display module

1.1 Introduction to DM6446 Chip

The DM6446 chip, as shown in Figure 1, consists of an ARM subsystem, a DSP subsystem, a VICP coprocessor, a video processing subsystem, and numerous chip peripherals. The ARM core is used for the control function of the entire system, the DSP subsystem is used for complex data and image processing functions, and the video processing subsystem is used for image input and output. The connection between these modules is managed through the central resource exchange channel (Switch Central Resources, SCR).

Figure 1 DM6446 chip overall architecture

1.2 Introduction to chip display module functions

The DM6446 display module is also called the video processing back end (VPBE), which is part of the chip video processing subsystem. The overall structure of VPBE is shown in Figure 2. As can be seen from Figure 2, VPBE is mainly composed of an OSD (On Screen Display) engine and a video encoder (VENC, Video ENCoder). The OSD engine can process two independent video windows and two independent OSD windows, and the VENC video encoder can provide four-way video data conversion, with an operating frequency of up to 54MHz, and is compatible with NTSC/PAL video and S-Video.

Figure 2 DM6446 display module overall architecture.

The DM6446 video encoder can also provide a 24-bit digital video output interface to RGB888 display devices, supporting 8/16-bit BT.656 output and CCIR.601 with vertical/horizontal synchronization separation.

The video signal of the OSD module is synthesized before output and sent to VENC for final conversion into YCbCr format output. The video data is built in the external memory DDR2 and sent directly to the display device for display. From the DAC, it can be connected to the LCD TV through the RCA terminal. For more detailed hardware description, please refer to TI's official data sheet TMS320DM644x DMSoC Video Processing BackEnd (VPBE) User's Guide.pdf.

2 Analysis of WINCE driver architecture

In addition to writing OAL layer code and source code configuration files, porting WINCE to DM6446 also requires a lot of device driver development.

2.1 WINCE driving principle

As a functional program that abstracts physical devices or virtual devices, the device driver manages the operation of the device and exports the device's functions to the application and operating system. Therefore, user programs only need to call the interface functions provided by the driver to access these hardware devices.

All device drivers of WINCE exist in the form of dynamic link library (DLL) files in user mode. Like all Windows DLLs, DLLs cannot be loaded and run alone. If you want to run the code in the DLL, an EXE process must first load the DLL into its own address space before you can execute the code in the DLL. Drivers under WINCE must also be loaded by other EXEs.

2.2 WINCE driver classification

There are two models of drivers based on WINCE: Native Device Driver and Streams Device Driver. Native device drivers are suitable for devices integrated into the WINCE platform and are always loaded when the WINCE platform starts; Streams Device Drivers are also called installable drivers, which use streams drivers and get commands from the device manager or application with the help of file system calls (such as Createfile, DeviceIoControl, etc.). The display driver discussed in this article belongs to the native device driver.

From the perspective of driver implementation, both stream interface drivers and local device drivers can be implemented in two ways: a single structure and a layered structure. They both provide DDI (Device Driver Interface) calls for other modules or applications to call. Regardless of the structure, the driver must be consistent with the DDI of the device it controls. DDI is an interface with the WINCE system, and the DDI of stream interface devices are all stream interface functions.

3 Display driver implementation

3.1 Display driver loading management

Figure 3 Schematic diagram of the main architecture of WINCE display driver.

Drivers under WINCE must be loaded by other EXEs, and display drivers are no exception. WINCE display drivers are loaded and managed by GWES.exe when the system starts, and reside in the process address space of GWES. As shown in Figure 3, the GWES subsystem, which consists of two parts, GDI and DirectDraw, provides system calls for graphics functions for applications running on the operating system, such as CreateDC, ReleaseDC, etc. The specific process of GWES loading display drivers is as follows: When GWES starts, it will access the candidate display device list (the list is under the registry HKEY_LOCAL_MACHINESystemGDIDisplayCandidates) to see if there is a driver that has been instantiated on the local machine. If so, GWES will use the first instantiated driver it finds; if the driver is not instantiated on the local machine or a suitable driver cannot be found, GWES will try to load Ddi.dll. By default, Ddi.dll is loaded, but if the KEY_LOCAL_MACHINESystemGDIDriversDisplay item exists, GWES will load the display driver specified by this registry item.

3.2 Main components of display driver

The display driver of WINCE is shown in Figure 3, which consists of two parts: DDI (Display Device Interface) and HAL (Hardware Abstraction Layer).

HAL mainly serves DirectDraw, and only needs to export HALinit() to GDI in the driver. Therefore, the focus of this article is the DDI part, that is, the usual display driver part. Since there are a lot of hardware-independent operations in the display, the display driver usually adopts a layered structure, which helps to reduce code complexity and improve code efficiency. The MDD layer implements the default drawing function and is composed of the Graphics Primitive Engine module (GPE) provided by Microsoft. If you want to support DirectDraw, you must use the DDGPE module; the PDD layer is specifically related to the hardware and is the main content of the display driver, which is generally implemented by OEM manufacturers or independent hardware vendors.

WINCE upper-level programs interact with the display driver through a set of (about 20 or more) display driver interface functions, so the display device driver must implement these display driver interface functions. GDI initializes the display device driver and outputs graphics to the display device by calling this set of functions. Due to the hierarchical structure, the display driver is responsible for providing function interfaces to the upper-level GWES module by the MDD layer, but these functions are not provided directly. In fact, they are only completed through a DrvEnableDriver() function. As an exported function of the DDI part, DrvEnableDriver will be called when GDI is initialized.

DrvEnableDriver is not implemented in the MDD layer, so it needs to be defined in the PDD layer. The main code is as follows:

BOOL APIENTRY DrvEnableDriver

(ULONG engineVersion,ULONG cj,DRVENABLEDATA *data,PENGCALLBACKS engineCallbacks)

{

BOOL fOk = FALSE;

if(gszBaseInstance[0] != 0)

{

fOk =

GPEEnableDriver(engineVersion, cj, data, engineCallbacks);

}

return fOk;

}

Here GPEEnableDriver is a MDD layer function pre-written by Microsoft. This function is located in the source file ddi_if.cpp, so we only need to call it.

The GPEEnableDriver function passes the address of a predefined DRVENABLEDATA structure variable pDrvFn to an upper structure pointer pded by executing the statement memcpy (pded, &pDrvFn, cj). The structure variable pDrvFn already contains more than 20 underlying display driver function pointers, so that GWES can manipulate the underlying display hardware through these pointers. For example, when an application wants to create a connection to a graphics device, it can call CreateDC() through GWES.exe, and this function will call the DrvEnablePDEV() function. When the application needs to disconnect from the display device, it will call DeleteDC(), and DeleteDC() will call DrvDisablePDEV(). DrvEnablePDEV() and DrvDisablePDEV() are among the more than 20 underlying display driver functions called by GWES.

Most of the above low-level display driver functions are closely related to hardware, so it is necessary to further call PDD layer functions. Since different display hardware has different characteristics, the interface functions exposed by the PDD layer to the MDD layer will inevitably be different, which will inevitably increase the complexity of the code. For this reason, Microsoft designed a GPE class. A GPE class instance represents a display device hardware. All its data members correspond to the attribute data of a display device, and multiple member functions are designed to manipulate these data members. Considering the diversity of hardware, some functions of the GPE class are not fully implemented, or are empty functions or virtual functions, which need to be implemented or overwritten by their subclasses. Therefore, variables of GPE type cannot be defined directly. You can only construct the GPE class as an inherited class of the parent class first, and then define the instance.

The underlying display driver function of the MDD layer can directly call the PDD layer code by instantiating an instance of the GPE inheritance class, which is generally implemented through the SafeGetGPE function.

SafeGetGPE is designed and implemented by Microsoft and is located in ddi_if.cpp of the MDD layer. Generally, no modification is required. The GetGPE function is called in the SafeGetGPE function. This function does not exist in the MDD layer and needs to be implemented in the PDD layer. The GetGPE function can be simply implemented as follows:

The code here takes advantage of the polymorphism and inheritance of C++. In C++, the pointer of the parent class or the class at the next higher level can reference the same variable in the inherited class, and the reference to the data member and member function takes precedence over the implementation or definition of the inherited class. In this way, when the data or function pointed to by the pointer gGPE is used in MDD, the member variables and member functions of the class DM6446VPBE are obtained. It can be seen that the GetGPE function is the bridge between MDD and PDD in the display driver, through which MDD can directly call the code of PDD.

3.3 Implementation of GPE inheritance class

From the above analysis, we can see that the main part of WINCE display driver is in PDD layer, and PDD layer, in addition to exporting some interface functions to MDD such as DrvEnableDriver, mainly builds a subclass of GPE or DDGPE (if DirectDraw is to be implemented). Since the parent class of DDGPE is GPE, there is not much difference between the subclasses of DDGPE and GPE.

Constructing a GPE subclass is actually to implement a subclass of the GPE class that has specific data and functions and accurately reflects the hardware properties of a specific display device, and to instantiate an object through the subclass.

A GPE subclass usually needs to overload the functions of the same name in the GPE class and implement the virtual functions in GPE as well as some functions unique to the subclass such as the initialization constructor [3]. The subclass constructor is mainly used to initialize the hardware and subclass member variables, such as the video processing clock register setting, the size and coordinates of the OSD Window, the output mode of VENC, and the member variables of the subclass such as the display width m_nScreenWidth and the display height m_nScreenHeight, etc. The functions in the GPE class that the subclass needs to implement include the empty functions and virtual functions of GPE. These functions are actually the functions that need to be implemented in the MDD calling the PDD layer driver. The main functions include: SetMode(), which is used to set the display mode that a display device can support; GetPhysicalVideoMemory(), which is used to obtain the system base address and memory size of the display device memory; and AllocSurface(), SetPointerShape(), BltComplete(), SetPalette(), etc. For details of these functions, please refer to the driver sample code provided by Microsoft, which is located in the Public CommonOAKDriversDisplay directory [1]. In addition to these functions, PDD also needs to implement an MDD layer function DrvGetMask, but it is relatively simple and only requires the definition of a global array gBitMasks. The content of this array represents the bit fields occupied by RGB and is related to the specific display hardware.

3.4 Communication between driver and application

Unlike other streaming drivers that can be called directly by applications, display drivers are called by the operating system and cannot be directly accessed by applications. Specifically, applications do not access through file system API interfaces such as CreateFile, but indirectly through the GDI interface. For GDI calls, the corresponding background service process is GWES.exe, and then GWES.exe further calls MDD and PDD functions, which are the underlying display drivers of WINCE. For example, if you want to draw a rectangle, you can call functions such as SetRect, GetDC, and FillRect to display it on the graphical interface, and to output a piece of text on the graphical interface, you only need to call the DrawText function, and as for the display driver call, it can be handed over to GDI.

4 Conclusion

This article explains and analyzes the DM6446 display hardware principle and Windows CE driver model, and analyzes the working principle and display workflow of the display driver. The innovation of this article is that it fully explains the design and implementation of the WINCE display driver on DM6446. In the past, the display driver of WINCE was based on LCD, so this article will have a certain reference value for developers who write similar drivers. After WINCE is started and running, the graphical interface runs stably and can support the application software running under Windows CE, indicating that the driver design is good.