Implementation of a keyboard driver in an embedded Linux System

The implementation of a keyboard driver for an embedded Linux system-general Linux technology-Linux programming and kernel information. The following is a detailed description. 1 Introduction

Linux has been widely used in embedded systems because of its powerful and stable kernel, easy expansion and reduction, and rich hardware support. Many embedded Linux systems, especially some embedded systems with strong interaction with users, usually need a special keyboard. At this time, developers need to write drivers for their own special keyboards according to the actual situation.

　　 2 Linux keyboard driver Introduction

Most drivers in Linux use hierarchical architecture, and the keyboard driver is no exception. In Linux, the keyboard driver is divided into two layers. The upper layer is a general keyboard abstraction layer, which provides services for the underlying layer without relying on the underlying hardware. The lower layer is the hardware processing layer, it is closely related to specific hardware and is mainly responsible for direct hardware operations. The upper-layer public part of the keyboard driver is in driver/keyboard. c. The most important thing in this file is the handle_scancode function exported by the kernel using the EXPORT_SYMBOL macro. Handle_scancode is used to convert the scan code to the key code, and then convert the key code to the target code based on the press conditions of the shift, alt, and other extended keys. Generally, it is an ASCII code, finally, place the ASCII code in the buffer zone of the terminal device, and schedule a tasklet to display it on the display. It can be seen that this function completes some of the core work of the keyboard driver, and these core logic functions are independent of the underlying hardware, so they can be independent, and export it to the underlying hardware processing function call. This file also defines several other callback functions, which are called by the upper public part of the keyboard driver and implemented by the underlying hardware processing functions. For example, kbd_init_hw, kbd_translate, and kbd_unexpected_up. Kbd_translate is called by handle_scancode and is responsible for converting the scan code into a key code. The underlying hardware processing part of the keyboard driver is implemented based on different hardware. For example, the underlying hardware processing functions of the standard keyboard on the PC platform are concentrated in driver/Pc_keyb.c. This file includes the keyboard_interrupt function for keyboard interrupt handling, the function for scanning code to keycode conversion, pckbd_translate, and other functions closely related to the underlying hardware.

In this architecture, you need to add a special keyboard to the system. Developers only need to write the underlying hardware processing functions in the driver program for them to drive the keyboard. Generally, the most important task of underlying hardware processing functions is to obtain the scan code of the pressed key in the keyboard interrupt processing and call handle_scancode with it as the parameter. This scan code can be customized, however, it must be the only landmark to identify the position on the keyboard where the key is pressed. In addition, developers also need to provide the corresponding Conversion Function kbd_translate from the custom scan code to the key code. Handle_scancode is responsible for specific key-code conversion, placing the target code in the input buffer of the terminal, and echo. We can also see that the kernel export function handle_scancode plays a key role in sticking the upper-layer general abstraction layer to the underlying hardware processing layer throughout the keyboard driver.

　　 3. Application Instances

Next we will use a specific application example to illustrate the specific process of writing a driver for a special keyboard in the embedded Linux system.

　　 3.1 hardware module description

The system is built using Samsung's S3C2410 Development Board as the hardware platform. The hardware module of the special keyboard consists of two SN74hc164 chips and a 4-row and 16-column matrix scanning circuit. SN74hc164 is an 8-Bit String-type input and output shift register. It is composed of eight D triggers. The working principle is simply like this. The rising edge of the SN74hc164 chip in the clock CLK pulse will be, the string input on Pin B is output to the output pin QA to QH after 8 clock pulses. The truth table is shown in.

The two SN74hc164 chips are first connected in series, and then their CLK pins and CLR pins are respectively connected to the gmaster and GPB4 ports of the S3C2410 Development Board, and the first SN74hc164 chip, pin B is connected to GPB1 ON THE DEVELOPMENT BOARD. These three GPIO ports are configured as output ports. In this way, we use two SN74hc164 registers to occupy only three GPIO ports and provide input to 16 columns of the matrix Scan Circuit, which saves both costs, this avoids the waste of GPIO resources. But it also brings some trouble to the implementation of the keyboard driver. The driver must first drive SN74hc164 and then control the 16 columns of the matrix circuit. The four line pins of the matrix circuit are connected to the GPG6, GPG7, GPG8, and GPG9 ports of S3C2410 respectively, and these four ports are configured as the interrupt source. When the keyless press is used, the system reads high potential directly. When using the SN74hc164 chip, the 16 columns of the keyboard are set to low potential. If any key is pressed, the corresponding GPG port will have a voltage jump from high to low, thus triggering an interruption.

　　 3.2 software module description