Design of Graphical User Interface Development Platform Based on ARM&Linux

1 Introduction

Embedded products such as PDA, set-top boxes, WAP mobile phones, etc. are rapidly becoming popular, bringing great convenience to a large number of non-professional users. At the same time, these products need to be supported by high-performance, stable and reliable GUI (Graphical User Interface).

Therefore, in the process of developing embedded products, the key step is the design of embedded graphical user interface development platform. This paper introduces the design process of a graphical user interface system development platform based on ARM, Linux and MiniGUI.

2 Hardware platform design and development environment construction

2.1 Hardware Platform Design

The hardware platform ARM221 is a self-developed ARM board based on the AT91RM9200 processor chip. The core board structure is shown in Figure 1. The AT91RM9200 processor is a cost-effective, low-power, 32-bit ARM chip based on the ARM920T core. The clock frequency is 180Mhz and the computing speed can reach 200MIPS. The AT91RM9200 has a memory management unit (MMU), 16KB of SRAM and 128KB of ROM, and an external bus interface (EBI). It supports SDRAM, static memory, Burst Flash, CompactFlash, SmartMedia, and NAND Flash. It also integrates a variety of peripherals such as USB controller, Ethernet controller, RTC, SPI, and I2C. The AT91RM9200 processor does not have an integrated LCD controller, so it needs to be equipped with a dedicated display controller to achieve LCD display.

The system uses a widely used LCD controller S1D13506, which is a newer model in the EPSON large-scale display controller family. Its output can drive VGA display or a dot matrix LCD display screen with a maximum of 800×600. It can flexibly set various display modes. It is very powerful and compatible with many popular CPU buses on the market. In addition, the display uses a Donghua 320×240-16bpp TFT-LCD. The PC card bus interface of S1D13506 can be easily connected to AT91RM920. The signals related to the bus interface signal are: data bus DB[15:0], address bus AB[21:1], chip select signal CS, high-order read and write signal WE1, write enable signal WE0, output read enable command signal RD, and select read and write video memory or read and write S1D13506 register signal M/R.

The EBI bus interface of AT91RM9200 is used to ensure correct data transmission between multiple peripherals and the built-in control memory based on ARM devices. Static memory, SDRAM and Burst Flash controller can all be used as external memory controllers on EBI. EBI has 8 chip select signals (NCS[7:0]) and can handle data transmission of up to 8 peripherals; data is transmitted through 8-bit or 16-bit data bus; address bus is up to 26 bits. Under 16-bit bus width, the bus interface signals related to EBI and display controller are: data bus DB[15:0], address bus AB[21:1], chip select signal NCS2 (corresponding address is 0x30000000), enable high byte read and write operation signal NWR1, enable byte or half byte read/write signal NRD/NWR0 and reset signal NRST. Based on the definition and analysis of the above interface signals, the bus connection diagram of S1D13506 and AT91RM9200 is shown in Figure 2 above.

2.2 Building a cross-compilation environment

Before porting Linux, you need to establish an ARM-Linux cross-compilation environment on the host machine. Community developers and some chip manufacturers have compiled tool chains for common architectures, which are easy to install. Using these tool chains can greatly reduce the workload. For the ported Linux kernel version 2.4.26, the cross-2.95.3.tar.bz2 tool chain is selected. In addition, the cross-compilation of MiniGUI also requires the support of some font, graphic and other library files. These library files include: zlib-1.2.3.tar.gz (this library is the basis for the compilation of the following libraries), libpng-1.0.10rc1.tar.gz (png graphics), jpegsrc.v6b.tar.gz (jpeg graphics), freetype-1.3.1.tar.gz (TrueType fonts), etc. Before cross-compiling MiniGUI, these libraries need to be installed in the cross-compiler. The installation process is relatively simple, and relevant information can be found. [page]

3 Embedded Linux system transplantation and related driver development

3.1 Embedded Linux System Porting

Transplanting the embedded Linux system is the core of the system software to realize the graphical user interface of the embedded system. The embedded Linux system includes three parts: bootloader, kernel and root file system. Transplanting the embedded Linux to a specific hardware platform generally requires the following five steps: ① Preliminary preparation includes downloading the source code package of the embedded Linux from *****, building a cross-compilation development environment, configuring the host development environment, etc.; ② Configure the Bootloader and burn it to the Flash of the target platform so that it can start the kernel normally; ③ Configure and compile the Linux kernel. First, make some modifications to the source code and transplant it to the target platform, and then cut it according to your own hardware resources to make the kernel optimal; ④ Make RAMDISK to mount the root file system of Linux and add your own application to RAMDISK; ⑤ Deploy the Linux system to make the target board out of the cross-development environment and start running directly on the target machine. Due to space limitations, the specific transplantation process of Linux will not be introduced in detail.

3.2 Development of related device drivers

Device drivers play a special role in the Linux kernel. They are independent "black boxes" that make a specific hardware respond to a well-defined internal programming interface, which completely hides the working details of the device. User operations are performed through a set of standardized calls, which are independent of specific drivers. The devices of the Linux system are divided into three types: character, block and network devices. Character devices are devices that are not cached when accessed. The reading and writing of block devices are supported by cache, and block devices must be able to be randomly accessed. Network devices are specially handled in Linux.

3.2.1 LCD controller S1D13506 driver development

① Frame buffer driver interface

The function of the LCD controller is to generate drive signals to drive the LCD. Users only need to read and write a series of registers to configure and display the driver. The most important step in configuring the LCD controller is to specify the frame buffer. The frame buffer provides an abstraction for the image hardware device. It represents some video hardware devices and allows application software to access the image hardware device through a well-defined interface. As long as the user program interacts with the interface abstracted by the frame buffer driver, it can read the content to be displayed from the buffer and display it on the screen.

The core structure in the Framebuffer driver is struct fb_info, which records the current status of the Framebuffer hardware device. It is defined in include/linux/fb.h of Linux. The main structures are: (1) struct fb_fix_screeninfo: defines the properties of the display device itself, such as the physical address and length of the screen buffer. (2) struct fb_var_screeninfo: records the modifiable information of the frame buffer device and the specified display mode, mainly including the screen resolution, number of colors and some timing variables. In actual programming, the relevant parameters of these two structures are set by assignment.

② LCD initialization

The entry point of the driver under Linux is module_init(), so the initialization is achieved by calling the module_init(13506fb_init) function. The initialization code of 13506fb_init mainly completes the following tasks: ⑴ Light up the backlight of the LCD. LCD display is a passive display mode. It cannot emit light and can only rely on controlling the transmission or reflection of the surrounding light to achieve the display purpose. Therefore, it is necessary to write registers to realize the lighting of the backlight. ⑵ This system uses an array in the 13506.h header file to predefine the setting of the register, and then uses two actual parameters to write in the initialization function to set the value of the register. The value of the register setting is: static 13506_REGSas1dregs[]={ …{0x0032,0x27},{0x0038,0xEF},{0x0039,0x0}…}. The first value of each element in the array represents the name of the register, and the second value represents the value to be set. Here, 32h sets the horizontal pixel value of the LCD display to 320; 38h and 39h are set to 0xEF and 0x0 respectively, that is, the vertical pixel value is set to 240. In addition to these three registers, the two registers 34h and 3Ah will also affect the resolution.

③ Implementation of LCD driver "file layer-driver layer" function

The frame buffer device is a character device. To implement the "file layer-driver layer" interface to drive the LCD, the file_operation data structure fb_ops must be filled and its corresponding member functions must be implemented. The file operation structure struct fb_ops of the frame buffer is defined in include/linux/fb.h under Linux transplanted by this system. Each field in this structure must point to a function that implements a specific operation in the driver. For unsupported operation fields, they can be set to NULL or left to be added in subsequent development. For the LCD of this system, specific operation member functions are required as follows:

static struct fb_ops 13506fb_ops=

{ owner:THIS_MODULE, fb_open:13506fb_open, fb_get_fix:13506fb_get_fix,

fb_get_var:13506fb_get_var, fb_set_var:13506fb_set_var, fb_get_cmap:13506fb_get_cmap,

fb_set_cmap:13506fb_set_cmap, fb_mmap:13506_mmap,

};

At this point, the LCD driver framework has been completed. The remaining work is to complete some calling functions. After writing the driver, use the arm-linux-gcc cross-compilation tool to compile the driver module, and then dynamically load or statically compile it into the kernel.

3.2.2 USB driver development

Universal Serial Bus (USB) is an external bus structure, which features unified interface, easy to use, convenient expansion, support for hot plug and PNP (Plug-and-Play), and simplifies the connection between computers and different types of peripherals. Once launched, it has been widely adopted by computer peripheral hardware manufacturers. Linux, as an open source operating system with a considerable market share, has added support for USB since the 2.2.18 kernel version.

USB is a layered bus structure. Information transmission between USB devices and hosts is realized through USB controllers. The USB controller driver is divided into three layers, from bottom to top: USB host controller driver, USB driver and USB device class driver. [page]

The USB host controller driver (HCD) at the bottom layer is a software module for the USB host to interact directly with the hardware. The USB in the Linux-2.4 kernel supports two host controller interfaces: the Universal Host Controller Interface (UHCI) and the Open Controller Interface (OHCI). The host controller driver provides a unified interface for the upper layer, shielding the specific details of the hardware. The specific functions implemented are: host controller hardware initialization; providing corresponding interface functions for the USBD layer; providing hub device configuration and control functions; completing 4 types of data transmission. The USB driver (USBD) part is the core of the entire USB host driver, and is mainly responsible for the management of the USB bus, USB bus devices, USB bus bandwidth management, providing relevant interfaces for USB device drivers, and providing file interfaces for USB systems accessed by applications.

The USB device class driver is the software module that ultimately interacts with the application, and mainly provides an interface for accessing specific USB devices and applications. The USB device classes supported by the Linux kernel include: USB printer device class, communication device class, storage device class, voice device class, etc. Since the USB HOST controller of AT91RM9200 complies with the OHCI standard, and the Linux kernel selected by the system provides module support for the OHCI specification, the development work is relatively simple. When developing the USB driver required by the target board, you only need to make slight modifications to the original Linux kernel driver for the target board. The specific modifications are as follows: ① Adjust the initialization address. In /usb/usb-ochi.c, use the onboard start address (0x40700000) for initialization; ② Delete the processing code of the PCI interface. On the target board ARM221 platform, the USB host controller does not contain a PCI interface, so delete the PCI-related code in /usb/usb-ochi.c; ③ Modify the number of ports under the HUB. The target board ARM221 has two USB HUB ports for keyboard and mouse interfaces. Therefore, in /usb/usb-ochi.c, change the number of downstream ports of the HUB from the default value to 2. After the code is modified, recompile and load it into the kernel.

4 Porting of MiniGUI on ARM221 target board

4.1 MiniGUI Architecture

MiniGUI is a cross-operating system, lightweight graphical user interface support system for embedded devices. From the overall structure, MiniGUI is designed in layers. At the bottom layer, the Graphic Abstract Layer (GAL: Graphic Abstract Layer) and the Input Abstract Layer (IAL: Input Abstract Layer) provide the underlying graphics device interface GDI (GDI: Graphic Device Interface) and input device drivers, and Pthread (POSIX standard thread) is used to provide a C function library for kernel-level thread support; the middle layer is the core layer of MiniGUI, including various modules that are essential to the window system; the top layer is the Application Programming Interface (API: Application Programing Interface). This layered architecture of MiniGUI greatly facilitates its transplantation on the target system.

4.2 Porting of MiniGUI

Porting MiniGUI mainly involves customizing or porting the GAL engine and IAL engine according to the specific hardware platform, which mainly includes the following three aspects of work. ① Porting of the GAL engine. MiniGUI can support a variety of GAL engines, including support for the Framebuffer engine. Therefore, for the target board ARM221, the display device is LCD, and the corresponding driver has been developed. Here, you only need to modify gal_engine=fbcon in the configuration file MiniGUI.cfg. ② Porting of the IAL engine. MiniGUI can support a variety of IAL engines, including USB mouse, keyboard engine and some touch screen engines.

For the target board ARM221, its hardware and software already support USB mouse and keyboard, so here you only need to modify ial_engine=console, mdev=/dev/PS2 in the configuration file MiniGUI.cfg. ③ Cross-compile MiniGUI's library files, resource files, and applications, and make a root file system and download it to the target board system for operation. After the transplantation is completed, the operation of the onboard MiniGUI is shown in Figure 3.

5 Conclusion

This paper introduces the design process of a graphical user interface platform based on ARM&Linux. Experiments show that the platform runs stably and reliably, and in the application system, only the upper-layer application software needs to be implemented according to actual needs.

The author's innovation is: from an overall perspective, the author analyzes and studies the embedded GUI development platform, selects the reliable ARM, open source Linux and lightweight embedded GUI support library MiniGUI, and completes the system's hardware and software design.