Implementation of a keyboard driver for an embedded Linux system (1) (2)

Initialization part. This part includes initialization on the hardware layer and software layer. In this example, you need to configure the matrix circuit and the GPIO ports used by the SN74hc164 chip first so that the CPU can control and access them. In order to configure a GPIO port as an input, output or interrupt source, the correct value needs to be set in the corresponding GPIO control register. The specific value can be obtained by consulting the S3C2410 development board manual. For example, in order to set GPB1 as the input terminal of SN74hc164, two bits 2 and 3 in the GPBCON control word need to be set to binary 01. In order to set GPG6 as a low voltage jump interrupt source, two bits 12 and 13 in GPGCON need to be set. bit set to binary 10. After completing the hardware initialization operation, it is the initialization on the software layer. First, register the keyboard interrupt processing function to the system, and then set up a timer structure so that when the interrupt occurs, it will be hung in the kernel's timer queue. The timer will trigger the scanning operation of the keyboard. Finally, the 16 columns of the matrix circuit are set to zero through SN74hc164.

Interrupt handling part. As mentioned before, what this part of the software should do is to scan the special keyboard, determine which key is pressed, get a stable scan code, and then call the kernel export function handle_scancode. In this application, the layout of the special keyboard is similar to the layout of the PC standard keyboard, so we directly use the system scan code of the corresponding key on the PC keyboard as the scan code of each key on our special keyboard, and at the same time we use the PC keyboard driver The conversion function pckbd_translate from the scan code to the key code is used as our kbd_translate function.

The algorithm to determine which key is pressed is as follows. When the interrupt comes, we can already determine which row the pressed key is based on the interrupt number, and we also need to determine which column the pressed key is. To this end, we first send a CLR signal to the two SN74hc164 chips connected in series, clear it, and then send 16 1s, so that the columns of the special keyboard are all high. At this time, what we read on the row ports of the keyboard are all high. Potential. Under 16 clock pulses, 1 0 and 15 1s are sent to the SN74hc164 chip, so that 0 appears uniquely once in each column, and at the same time, the keyboard row port is scanned. When the column of the pressed key is set to 0, the row where it is located will read a low level. Using this "walk 0 method", we can determine which key on the keyboard was pressed. But this simple scanning algorithm is not enough, because in this type of matrix scanning keyboard, every time a key is pressed and lifted, there will be 10~20ms (the length of this period is determined by the hardware characteristics) burr jitter. , as shown in Figure 2, so in order to obtain stable key information, it is necessary to find a way to remove this jitter to avoid mistaking the user's one key press as several key presses. A common method of deburring is to not scan the keyboard immediately when a keyboard interrupt arrives, but to wait for a period of time and then scan the keyboard after skipping the burr jitter. The pseudo code is as follows:

Wait for a period of time and skip the jitter;

Scan the keyboard;

if no key is pressed on the keyboard

End and return;

if a key is pressed on the keyboard

Wait for a while again and check if the same key is Still pressed;

if the same key is still pressed

to return the scan code read;

else

to return directly;

This solution is certainly feasible, but it uses busy The waiting method is used to remove burrs. During the busy waiting period, the system cannot do any useful work. This is a luxurious waste for embedded Linux systems with limited computing resources. In this application, we designed a deburring solution suitable for embedded systems with good results.

Since the Linux kernel provides a timer queue, we can use this mechanism to avoid busy waiting and improve system performance. When a key on the keyboard is pressed, the keyboard interrupt handler first closes the interrupt source, enters polling mode, and ends after hanging a timerlist object into the timer queue. The timer hooked into the kernel is triggered on time, and the function it triggers completes the following tasks: first scans all the keys on the entire keyboard, and saves the scan results to a static 2-dimensional array variable snap_shot_matrix[16 ][4]. This variable describes the pressing status of all keys on the keyboard at this moment of this keyboard scan. If a key is not pressed, that is, it is in a released state, then the corresponding value in snap_shot_matrix is ​​set to 0. If a key is pressed, then the corresponding value in snap_shot_matrix is ​​incremented by 1. If the If the value is greater than a pre-specified number after increasing by 1, we can consider it to be a stable value, and set the value in the corresponding coordinates of another 2-dimensional array variable current_matrix with a size of 16*4 to 1, otherwise set it to 0 . This variable describes the stable value of the current keystrokes on the keyboard. That is to say, we first process the sampled data obtained in this scan and save it to snap_shot_matrix, and then filter to obtain the current_matrix based on the value in this variable. Through this process, we perform deburring processing. After obtaining the stable value current_matrix of this scan, we compare it with the stable value previous_matrix obtained last time to determine whether the key conditions on the keyboard have changed at this moment compared with the last scan, and whether the keyboard conditions at this moment have changed. whether a key is pressed. If it is found that no keys on the keyboard are pressed, turn on the keyboard interrupt and switch back to interrupt mode again. If a key is pressed on the keyboard, and it is different from the last scanned pressed key, we immediately call the key processing function process_key, which will call the upper-level function handle_scancode in the keyboard driver. If the key pressed on the keyboard is the key pressed last time, we will increment a counter. When the counter reaches a certain specified value, we start the so-called Auto repeat function, that is, the user keeps pressing a certain key. The driver automatically generates keyboard input repeatedly. This counter is set to 0 when the key pressed changes. But as long as there are still keys on the keyboard that are pressed, we copy the currently read keyboard stable value current_matrix to the previous_matrix, and hang the previously described timer object into the kernel timer queue again. After a while, Then scan the entire keyboard again until no keys on the keyboard are pressed.

4 Conclusion

With the advancement of the information society and computer software and hardware technology, the design and application of embedded information products have developed rapidly, and the need to add special keyboard drivers to your own embedded Linux systems is also increasing. universal. After introducing the overall framework of the keyboard driver in Linux, this article takes a special keyboard on the S3C2410 development board as an example to focus on describing the work that needs to be done when writing a driver for a special keyboard in an embedded Linux environment, providing a basis for similar The development provides an idea and reference.

(T114)

The above is the content of (1) (2) of the keyboard driver implementation of an embedded Linux system. For more related content, please pay attention to the PHP Chinese website (www.php.cn)!