Realization principle of LCD driver in embedded system

Combined with Samsung ARM9 series embedded Processor s3c2410, this paper explains how to program LCD driver modularization and how to load the driver into the system kernel statically.

LCD (LCD) module to meet the increasing requirements of embedded systems, it can display Chinese characters, characters and graphics, but also has low voltage, low power consumption, small size, light weight and ultra-thin and many other advantages. With the application of embedded system more and more widely, the function is more and more powerful, the Man-machine interface of the system is more and more high, in the application of demand, many work under the Linux graphical interface software package development and porting work involve the bottom of the LCD driver development problem. Therefore, the development of LCD driver in embedded system can be widely used.

Based on the LCD interface of Samsung company ARM9 Core Chip s3c2410, this paper introduces the general method of developing embedded LCD driver on Linux platform.

This paper uses the Samsung Company's s3c2410 Chip Development Board, the software uses the Linux 2.4.19 platform, the compiler is ARM-LINUX-GCC the cross compiler, uses the 640x480 resolution the TFT color LCD, through its Linux driver rewriting and debugging, The drive and display of this kind of screen are realized successfully.

the concept of embedded drive

The device driver is the interface between the operating system kernel and the machine hardware, which masks the details of the hardware for the application, so that in the case of the application, the hardware device is just a device file, and the application can operate on the hardware device as if it were a normal file. A device driver is a part of the kernel that functions primarily to initialize and release the device, to transfer data from the kernel to the hardware and read data from the hardware, to read data that the application transmits to device files, to echo application requests, and to detect and process errors in the device.

Linux divides devices into two basic categories: one for character devices and the other for block devices. The main difference between a character device and a block device is that when a read/write request is made to a character device, the actual hardware I/O typically occurs immediately thereafter. Character devices perform sequential read-write operations in a single byte, usually without buffering technology, and block devices are stored and read and written to a fixed-size block of data, such as a hard disk, floppy disk, etc., and a system memory is used as a buffer. In order to improve the efficiency, the system has provided the caching mechanism for the block device's reading and writing, because it involves the buffer management, the scheduling and the synchronization and so on, realizes is more complex than the character equipment. The LCD is accessed and managed as a character device, and Linux sees the display driver as a character device, sending the data to the LCD drive in bytes and bytes.

Linux Device management is closely linked to the file system, the various devices are stored in the form of files in/dev directory, called device files. The application can open, close, and read and write these device files to complete the operation of the device, just as you would a normal data file. In order to manage these devices, the system is numbered for the device, and each device number is divided into the main device number and the secondary device number. The main device number is used to differentiate between different kinds of devices, while the secondary device number is used to differentiate multiple devices of the same type. For common devices, Linux has a conventional number, such as the main device number of the hard disk is 3. Linux provides a unified operation function interface for all device files by using data structure struct file_operations. This data structure includes pointers to many operation functions, such as open (), close (), read (), and write (), but because of the variety of peripherals, the operating methods are different. The members of the STRUCT file_operations structure are a series of interface functions, such as the Read/write function for read/write and IOCTL for control. Opening a file is called the open operation in this file file_operations. Different types of files have different file_operations member functions, such as ordinary disk data files, interface functions to complete the disk block read and write operations, and for a variety of device files, it will eventually invoke the respective driver of the I/O function in the operation of specific devices. In this way, the application does not have to consider whether the operation is a device or a normal file, can be treated as a file, with a very clear unified I/O interface. So file_operations is a file-level I/O interface.

LCD Controller

The function of the LCD controller is to display the drive signal and then drive the LCD. Users only need to read and write a series of registers, complete configuration and display driver. In the process of driving LCD design, the first is to configure the LCD controller, while the most important step in configuring the LCD controller is the designation of the frame buffer (framebuffer). What the user wants to display is read out of the buffer and displayed on the screen. The size of the frame buffer is determined by the resolution of the screen and the number of colors displayed. The implementation of driver frame buffering is the focus of the whole drive development process. The LCD controller in s3c2410 can support STN and TFT two kinds of liquid crystals. For STN LCD flat panel, the LCD controller supports 4-bit dual scan, 4-bit single scan and 8-bit single scan three display types, supports 4-and 16-level grayscale display modes, supports 256-and 4096-color displays, and can be connected to multiple-resolution LCDs, such as 640x480, 320x240, and 160 X160 and so on, in 256-color display mode, the largest support 4096x1024, 2048x2048 and 1024x4096 display. TFT LCD Panels Support 1-2-4-8BPP (bits per pixel) palette display mode and 16BPP non-palette true color display.

A frame buffer is a driver interface that appears in the Linux 2.2.xx and later versions of the kernel, which abstracts the display device as a frame buffer device area. The frame buffer provides an abstraction for the image hardware device, which represents some video hardware devices, allowing the application software to access the image hardware device by defining an explicit interface. This software does not need to know anything about the underlying driver of the hardware (such as hardware registers). It allows the upper application to read and write and I/O control the display buffer directly in graphical mode. The device can be accessed through a dedicated device node, such as/dev/fb*. The user can see it as an image of the display memory, which is mapped to the process address space, and can be read and write, while the read-write operation can be reflected to the LCD.

The device file corresponding to the frame buffer device is/dev/fb*. If the system has more than one video card, Linux also supports multiple frame buffering devices up to 32, or/dev/fb0~/dev/fb31. While/DEV/FB points to the current frame buffer device, the default frame buffering device is typically/dev/fb0.

Frame buffer devices also belong to character devices, using the "file Layer-drive layer" interface. The following data structures are defined for them at the file layer.

Static struct File_operations fb_fops={
Ower:this_module,
Read:fb_read,/* Read operation * *
Write:fb_write,/* Write operation * *
Ioct1:fb_ioct1,/*i/o operation *
Mmap:fb_mmap,/* Mapping operation * *
Open:fb_open,/* Open Operation * *
Release:fb_release,/* Close Operation * *
}

Its member functions are defined in LINUX/DRIVER/VIDEO/FBMEM.C, where functions operate on specific hardware, set registers, and map display buffers. There are several major structural bodies.

Struct Fb_fix_screeninfo: Information that is not modifiable for frame buffering devices and for specified display modes is recorded. It contains the physical address and length of the screen buffer.
Struct Fb_var_screeninfo: The modifiable information of the frame buffer device and the specified display mode is recorded. It includes the resolution of the display screen, the number of bits per pixel, and some time series variables. Where the variable xres defines the number of pixels in a screen row, yres defines the pixels of a screen column, and Bits_per_pixel defines how many digits each pixel is represented.
Struct Fb_info:linux is a driver-layer interface defined for a frame buffer device. It contains not only the underlying function, but also the data that records the state of the device. Each frame buffer device corresponds to a fb_info structure. Where the member variable modename is the device name, FontName is the display font, Fbops is a pointer to the function that points to the underlying action.

the main work of LCD drive development

1 Writing initialization functions

The initialization function first initializes the LCD controller, sets the display mode and number of colors by writing registers, and assigns the LCD display buffer. In Linux, you can use the Kmalloc () function to allocate a contiguous space. The buffer size is: The number of lattice rows x lattice columns x is used to represent the number of bits per pixel/8. Buffers are usually allocated in large volumes of external SDRAM, and the starting address is stored in an LCD control register. The LCD display mode in this paper is 640x480,16 bit color, then the display buffer to be allocated is 640x480x2=600kb. Finally, initialize a fb_info structure, populate the member variables, and call Register_framebuffer (&fb_info) to register fb_info into the kernel.

2 Writing member functions

Write the function pointer fb_ops corresponding member function in the structure fb_info, for the simple implementation of the embedded system, only need the following three functions.
struct fb_ops{
......
Int (*fb_get_fix) (struct fb_fix_screeninfo *fix, int con, struct fb_info);
Int (*fb_get_var) (struct fb_var_screeninfo *var, int con, struct fb_info);
Int (*fb_set_var) (struct fb_var_screeninfo *var, int con, struct fb_info);
......
}
Struct fb_ops is defined in Include/linux/fb.h. These functions are used to set/get the member variables in the FB_INFO structure. They are invoked when the application ioctl the device files. For Fb_get_fix (), the application passes in the FB_FIX_SCREENINFO structure, assigning values to its member variables in the function, primarily Smem_start (buffer start address) and Smem_len (buffer length), which are eventually returned to the application. The incoming parameter of the Fb_set_var () function is fb_var_screeninfo, and the function needs to assign values to Xres, Yres, and Bits_per_pixel.
For/DEV/FB, there are several main operations for display devices.

Read/write (read/write)/DEV/FB: equivalent to a read/write screen buffer.
Mapping (MAP) operations: Because Linux works in protected mode, each application has its own virtual address space, and the physical buffer address is not directly accessible in the application. To do this, Linux provides a mmap function in the file_operations structure of file operations, which maps the contents of a file to user space. For frame buffering devices, the mapping operation allows the physical address of the screen buffer to be mapped to a virtual address in user space, after which the user can then draw on the screen by reading and writing the virtual address to the screen buffer.
I/O control: For frame buffer devices, the IOCTL operation of device files can read/Set the display device and screen parameters, such as resolution, display color number and screen size. The IOCTL operation is done by the underlying driver. In the application, the general steps to manipulate/DEV/FB are as follows: Open the/DEV/FB device file, use the Ioctrl operation to obtain the current display screen parameters, such as screen resolution and the number of bits per pixel, based on screen parameters to calculate the size of the screen buffer; Map the screen buffer to user space Map can read and write directly to the screen buffer, drawing and picture display.

LCD Modular Drive

When you write a modular driver for a s3c2410 LCD, you first need to remove the LCD driver from the kernel. Here you need to make some changes, system calls are added to the following files, need to be removed:/root/usr/src/arm/linux/kernel/sys.c;/root/usr/src/arm/linux/include/ Arm-arm under the Unistd.h and Lcd.h;/root/usr/src/arm/linux/arch/arm/kernel under the CALLS.S.
To write a modular driver, there are several key functions.
Lcd_kernel_init (void)//When module is loaded to execute
Lcd_kernel_exit (void)//is executed when the module is moved out of kernel space
Lcd_kernel1_ioctl (Struct*inode, struct*file, unsigned int cmd, unsigned longarg)/other features
The system automatically invokes initialization module lcd_kernel_init (void) Whenever a device driver is assembled.
Another function that must be provided is lcd_kernel_exit (void), which is called when the module is unloaded, and is responsible for the work of the device driver.
The LCD driver can be added to the kernel by executing the insmod LCD.O command, and the LCD driver can be removed from the kernel by executing the rmmod LCD command.

static load LCD driver

Place the written LCD driver lcd.c in the Arm/linux/drivers/char directory, modify the Arm/linux/drivers/char/config.in file, and add a row: Bool "LCD Driver Support" CONFIG_LCD Modify Arm/linux/drivers/char/makefile file, plus one line: obj-$ (CONFIG_LCD) +=lcd.o.

This way, when make Xconfig is made, the LCD driver is selected to compile into the kernel. The same approach can also be used on other devices.