Transplantation of Microwindows in Embedded Systems Based on Single Chip Microcomputer

introduction

Microwindows is an open source project organized by Gregory Haerr. It is a graphical user interface (GUI) widely used in embedded systems. The goal of the project is to provide a graphical user interface similar to that of ordinary personal computers on an embedded Linux platform. As a substitute for X_Windows, Microwindows provides similar functions to X_Windows, but takes up very little memory. Depending on the user's configuration, Microwindows only takes up about 100KB to 600KB of memory resources. The core of Microwindows is based on the display device interface, which is highly portable. It provides a variety of display device drivers commonly used in embedded systems. At present, the new version of Microwindows has a built-in framebuffer, so it is not limited to the Linux development platform and can run on operating systems such as Ecos, FreeBSD, and MiniX. On a Linux-based development platform, you can use the framebuffer mechanism to directly read and write video memory, or call the svgalib library. In the Linux-based framebuffer mechanism, Microwindows supports 1-bit, 2-bit, 4-bit, 8-bit, 16-bit, and 32-bit color/grayscale per pixel, and converts the RGB color space to the color on the target machine for display through the palette technology. The Microwindows system can support the development of the simulated target platform on the host platform in a graphical way, so the Microwindows application can be written and developed directly on the desktop and run on the target platform through cross-compilation.

This paper discusses the method and process of transplanting uclinux operating system on an embedded development platform based on s3c44b0x, and making the uclinux kernel support framebuffer devices by modifying the kernel and writing framebuffer device drivers, and transplanting microwindows on this basis

Microwindows architecture

In view of the characteristics of embedded systems, microwindows adopts a hierarchical structure, with each layer performing specific functions, as shown in Figure 1.

Figure 1 Microwindows architecture

Device driver layer

The interface functions of the device driver are defined in device.h, including the screen driver, mouse driver, and keyboard driver. The device-independent graphics engine routines provided by the graphics engine layer interact with the hardware device by calling the device driver. This ensures that when the platform hardware device changes, only the corresponding driver needs to be rewritten without modifying the upper code. Microwindows provides a frame buffer device driver based on the linux2.2.x kernel. Through the /dev/fb0 device file, the mmap() system call is used to map the display cache to the system memory.

Graphics Engine Layer

The core functions in the microwindows system are implemented in the graphics engine layer by calling the lower-level hardware device drivers. These functions encapsulate the screen, mouse, keyboard and other drivers, provide services for the API, and users call the programming interface provided by the top layer without directly calling the routines of the engine layer. In the source code of microwindows, the core routines include:

devdraw.c: Main graphics drawing operations, drawing and filling, display of circles, polygons, text and bitmaps, and color conversion related codes;

devclip.c: Clipping operation;

devmouse.c: handles mouse operation information;

devkbd.c: Processes keyboard operation information;

devpalx.c: Code related to the palette;

devimage.c: implements the display operation of graphics in gif, bmp, jpeg, ppm and other formats;

fongt_xxxx.c: Display operations for different fonts

API

Microwindows provides two types of APIs to better adapt to the porting of applications on different platforms. One is an API that is basically compatible with Win32/Win CE, supports most graphics operations, and its API is based on a message mechanism. The other is the nano-x API that uses the X system. It is a client/server model. The API functions on the client are named nx...(), and the API functions on the server are named gr...().

Specific implementation

The following is a detailed discussion of the implementation of MicroWindows on PC and S3C44B0X development board. First, you need to download the corresponding installation package. This article downloads the 0.90 version of MicroWindows and the corresponding font files. At the same time, since MicroWindows needs to use the FreeType library function to generate TrueType fonts, you also need to download and install FreeType. Here, the 1.3.1 version of FreeType is used.

Implemented on PC

Unzip the relevant installation package, install freetype, and then you can start running microwindows. Enter the command: ./xconfigure in the unzipped directory, and the corresponding configuration menu will appear. Since it is running on a PC, microwindows should be configured according to specific parameters. The specific parameter configuration is as follows:

(1) Click compiling option to enter the compiling options. In the sub-window that pops up, select optimize and click ok to return.

(2) Click platform to enter the development platform options. Since it is running on a PC, select the "linux (native)" option. In the subsequent "option" options, configure as follows: in the "screen driver" option, since it is running on a PC, select "x11"; in the "mouse driver" option, select "gpm mouse"; in the "keyboard driver" option, select "tty".

(3) Click “libraries to compile” to enter the library configuration options. There are nanox library and microwindows library. In the “option” option of “nanox”, select “link app into server” and “compile demos” options.

Other parameter configurations, including fonts, file format support, etc., should be configured according to specific circumstances. At this point, the configuration of running MicroWindows on the PC has been completed. Save and exit, and the screen will show that the configuration is successful. Enter the command: make to complete the compilation. When the compilation is completed, there are many demonstration programs in the bin directory of src, some of which are based on nano-x api and some are based on win32 api. Just run them.

The above briefly discusses the method and process of running MicroWindows on a PC. The running process on a PC is relatively simple. You only need to configure and compile according to the actual situation.

Implementation on embedded development board

The following discusses the steps and methods for running microwindows in an embedded development board with s3c44b0x as the main control chip. First, you need to establish a cross-compilation development environment. The compiler established here is arm-elf-gcc, the assembler is arm-elf-as, the linker is arm-elf-ld, and the library manager is arm-elf-ar. Then, port the corresponding clinux. There are many articles about this, so I will not repeat them here. Finally, open the frame buffer device driver of s3c44b0x in the clinux kernel, and you need to create the /dev/fb0 device node. The development of the frame buffer device driver of s3c44b0x has been published in another article. So far, the basic work of microwindows porting has been done. The following specifically discusses the steps and methods for implementation.

During the configuration of microwindows, you can use the ./xconfigure command to enter the menu configuration interface, or you can directly modify the configuration file "src/config" to configure microwindows. The latter is adopted here, and several key options include architecture, cross compiler, bits per pixel, frame buffer, etc. The specific configuration parameters are as follows:

(1) About architecture and compiler options

[ Related pictures ]

(2) Bits per pixel screen_pixtype = mwpf_truecolor332 For s3c44b0x, in color mode, 1 byte of 8-bit (3-bit red, 3-bit green, 2-bit blue) image data corresponds to one pixel, that is, the pixel byte is stored in the memory in a format of 332 bits. Therefore, when setting the bits per pixel of microwindows, set its format to 332, and set it to mwpf_truecolor332 according to the definition in the header file.

(3) Since the frame buffer device is running on an embedded development platform, different from a PC, Microwindows should be based on the frame buffer driver, that is, it needs to call the /dev/fb0 device, so the parameter configuration should be:

There are some other related configuration parameters that should be configured according to the actual situation. So far, the configuration of microwindows has been completed. Now we need to modify the source code of microwindows according to the characteristics of ?clinux. The specific areas that need to be modified include three aspects:

When opening the frame buffer device, you need to call the void *mmap(void *start,size_t length,int prot,int flags,int fd,off_t offsize) function to map the screen buffer to the user address space. When developing based on a PC, under the Linux system, the flags parameter defaults to map_shared, that is, the data written to the mapped area will be copied back to the file, and other processes that map the file are allowed to share. Since ?clinux does not have an MMU (memory management unit), the flags parameter should be map_fixed, that is, if the address pointed to by the start parameter cannot be successfully mapped, the mapping is abandoned and the address is not corrected. Therefore, the file /src/drivers/scr_fb.c should be modified to change the flags parameter in the mmap() function to map_fixed.

If you compile the configured and modified source code of microwindows directly, you will get the error "undefined reference to '_ _ctor_list'" and "undefined reference to '_ _dtor_list'". This is because the _ _ctor_list and _ _dtor_list parameters were defined in libgcc, but the symbols were deleted in the clinux cross-compilation chain. The definitions of these two symbols are provided in the elf2flt link script. When using the clinux cross-compilation chain to compile executable programs, you must use the -elf2flt option. Therefore, you should add "-elf2flt" to the compilation options, and the modified files include the makefile files in each related folder under the demos folder.

Since clinux lacks MMU hardware support, it cannot implement the fork() function and can only use the vfork() function. Therefore, the corresponding conditional compilation instructions should be added to the file containing the fork() function, and vfork() should be used instead of fork().

The above three modifications are more important. So far, the entire microwindows has been transplanted in the s3c44b0x embedded development board. You can compile it. Finally, copy the compiled demonstration program to the clinux kernel, compile the kernel, download the compiled kernel image file to RAM, and run the demonstration.

Conclusion

This article mainly discusses the architecture of MicroWindows, and introduces the steps and methods of running it on a PC and an embedded development board based on S3C44B0X, and points out the issues that should be paid attention to during the development process. Now you can use the corresponding development tools to develop MicroWindows applications to achieve the corresponding functions.