Design of embedded Linux key driver based on finite state machine

　　The general key driver is usually very simple. Once the key input port is detected as low level in the program, the software delay is used to detect the key input port again after 10 ms. If it is still low level, it means that a key is pressed, and the key processing program is executed; otherwise, when the key input port is high level, the key detection is abandoned and the key detection process is restarted. This method not only reduces the efficiency of the MCU due to the use of software delay, but also makes it difficult to coordinate with other functional modules in the system, and the real-time performance of the system is also poor. This article takes a single key as a simple system, analyzes the operation and confirmation process of its action according to the principle of the state machine, and expresses it with a state diagram, and then writes a key interface program based on the state diagram.

　　1 Simple button drive design based on state machine

　　In an embedded system, the operation of the key is random. In order to improve the working efficiency of the CPU, when designing the key driver, the external interrupt of S3C2440 is used to realize the processing of the key. Obviously, the input signal of the system is connected to the I/O port level of the key, "1" means the key is in the open state, and "0" means the key is in the closed state. The output signal of the system indicates the detection and confirmation of a key closing operation, which is represented by "1".

　　Figure 1 shows a state transition diagram of a simple button state machine.

　　In the figure, a complete key operation is decomposed into three states. Among them, state 0 is the initial state of the key. When the key input is "1", it means that the key is open, the output is "0" (I/0), and the next state is still state 0; when the key input is "0", it means that the key is closed, but the output is still "0" (without debounce, it cannot be confirmed that the key is actually pressed), and the next state enters state 1.

　　State 1 is the key closure confirmation state, which means that the key was closed 10 ms ago. Therefore, when the key input is detected as "0" again, it can be confirmed that the key is pressed (after 10 ms of debounce); the output "1" indicates that the key is confirmed to be closed (0/1), and the next state enters state 2. When the key input is detected as "1" again, it means that the key may be in jitter interference; the output is "0" (I/0), and the next state returns to state 0. In this way, the debounce processing of the key is realized by using state 1. State 2 is the state of waiting for the key to be released, because only after the key is released, a complete key operation process is completed.

　　From the analysis of Figure 1, it can be seen that during the entire process of a key operation, the state of the key changes from state 0 → state 1 → state 2, and finally returns to state 0. In the entire process, the output signal of the key only gives a unique signal "1" to confirm the key is closed when it is in state 1, and outputs "0" in other states. Therefore, the key system represented by the state machine of Figure 1 not only overcomes the problem of key jitter, but also ensures that during the entire process of a key operation, the system only outputs a key closure signal ("1") once.

　　2 Key-driven design with burst function

　　The above is the simplest case. No matter how long the key is pressed, only one confirmation output is given during the entire process of the key press. However, in some cases, for the convenience of users, it is determined whether the key is pressed "continuously" based on how long the user presses the key. For example, when setting the clock, if the key is pressed for a short time, add 1; if the key is pressed for a long time, add 10. In this case, it is necessary to determine the specific output based on the length of time the key is pressed. Figure 2 is a state transition diagram of a key driver designed as a state machine with a continuous function.

　　If the key is released within 1 second after being pressed, the system output is 1; if the key is not released within 1 second after being pressed, the output is 2 every 0.5 seconds until the key is released. If the system outputs 1, the application will increase the variable by 1; if the system outputs 2, the application will increase the variable by 10. In this way, the key driver has the function of processing continuous keystrokes. [page]

　　3 Programming

　　Due to space limitations, only the key program of the key driver, the key interrupt handler and the time processing function are given below:

　　The timing function here uses the Linux kernel timer. The kernel timer can easily implement the specific timing time of each state, and safely release the CPU to improve the efficiency of the CPU. The basic idea of ​​the program is that the key is first pressed to enter the key interrupt service program buttons_interrupt(), and determine whether the key state is in the initial state in the interrupt service program. If so, kbd_timer is initialized and the key state is changed to the debounce state. After the kbd_timer timing is reached, the key detects whether the key state is still pressed and changes the state to the key determination state. If not, the initial state is restored. When the timer reaches 1 s, it determines whether the key is still pressed. If so, it is converted to the burst state, otherwise it is restored to the initial state. When 0.5 s is reached, it is re-determined whether the key is still pressed. If so, it continues to be in the burst state, and the output value is increased by 10; if the key is lifted, it is restored to the initial state. [page]

　　4 Experimental Results

　　The driver is compiled with gcc-arm-liunx-3.4.4 and runs on the Micro2440SDK development board (the system version on the development board is linux2.6.13). The running results are shown in Figure 3.

　　From the running results, we can see that if the button is pressed and released within 1 second, the output value will only increase by 1 each time; if the button is pressed for more than 1 second, the system output value will increase by 10 every 0.5 seconds. This shows that this driver runs normally and has the burst function.

　　Conclusion

　　This paper mainly analyzes the working process of the key finite state machine, and uses the Liunx kernel timer to implement the state machine's state transition time interval. Finally, it gives the code for writing a Linux driver with a burst function based on the finite state machine, and implements a key driver with a burst function, which provides a solution for key drivers based on finite state machines.