Design and implementation of keyboard driver based on I2C bus

Publisher:CaptivatingGazeLatest update time:2014-01-11 Source: elecfans Reading articles on mobile phones Scan QR code
Read articles on your mobile phone anytime, anywhere

With the rapid development of embedded systems, embedded PCs are widely used in many fields. Among them, embedded keyboards, as a human-computer interaction tool, play a very important role. The usual keyboard design adopts an array design. For example, a keyboard with 9 key values ​​requires 6 general I/O ports to achieve communication. The more key values ​​a keyboard has, the more general I/O ports it needs.

The I2C (Inter-Integrated Circuit) bus is a 2-wire serial bus developed by Philips for connecting microcontrollers and their peripherals. The main advantages of the I2C bus are its simplicity and effectiveness. Since the interface is directly on the component, the I2C bus takes up very little space. Another advantage of the I2C bus is that it supports multimastering, where any device capable of sending and receiving can become the master bus. A master can control the transmission of signals and the clock frequency. But there can only be one master at any point in time.

These characteristics of I2C make it popular in many designs. The MAX7347-7349 series chips introduced in this article are I2C compatible chips. It encapsulates a series of operations such as key value scanning inside the chip. The CPU only needs to communicate with the chip through the I2C bus and complete certain operations by writing certain commands to the chip. This simplifies the processing of keyboard drivers. And because I2C supports multiple masters, it does not affect the operation of other devices in the system. The whole process only requires 3 general I/O ports to communicate with the CPU, and can handle up to 64 key value responses, effectively saving general I/O ports.

2 Basic principles

2.1 Keyboard driver implementation principle

The usual keyboard adopts the matrix principle. For example, for a keyboard with 20 key values, a 4×5 matrix array is used, that is, 4 rows and 5 columns. The rows and columns are directly connected to the I/O ports of the CPU, and 4 I/O ports are used as interrupt I/O ports. Once an external key is pressed, an interrupt will be generated. Since the row and column corresponding to the key are connected after the keyboard is pressed, the position of the pressed key can be obtained by judging the level of the I/O port corresponding to each column, so that the corresponding response can be taken.

The MAX7347-7349 series chips used in this article have an internal FIFO queue, which completes a series of complex operations such as key debouncing, scanning key values, automatic key repeat, and alarms at certain times. The keyboard driver itself needs to send a series of commands to obtain certain required status values ​​in order to perform corresponding operations.

2.2 I2C bus communication principle

The I2C bus is a serial bus consisting of a data line SDA and a clock SCL, which can send and receive data. Various controlled circuits are connected in parallel on this bus, and each circuit and module has a unique address. The CPU will issue an address code for address selection, that is, to connect the circuit to be controlled. Therefore, although each control circuit is connected to the same bus, they are independent of each other and unrelated.

The I2C bus defines strict transmission signals to complete a transmission.

Start signal: When SCL is high, SDA jumps from high to low and starts transmitting data.

End signal: When SCL is at a low level, SDA jumps from a low level to a high level, ending the data transmission, as shown in Figure 1.

Note: The data state on the SDA line can only change when SCL is at a low level. When SCL is at a high level, changes in the SDA state will be recognized as start and stop conditions.

Response signal: After receiving the 8-bit data, the IC that receives the data sends a specific low-level pulse to the IC that sends the data, indicating that the data has been received. After the CPU sends a signal to the controlled unit, it waits for the controlled unit to send a response signal. After receiving the response signal, the CPU determines whether to continue to transmit the signal based on the actual situation. If no response signal is received, it is determined that the controlled unit has a fault. As shown in Figure 2. 

3 Specific Implementation

3.1 Interface Circuit

Figure 3 shows the schematic diagram of the MAX7347 chip circuit. 

Eleven of the pins are keyboard array inputs connected to keyboard peripherals, 3 rows and 8 columns, and can control up to 24 different keys. Three pins communicate directly with PXA 270, INT is the interrupt pin, which is low level when the key is pressed, SCL is the I2C compatible serial clock input, and SDA is the I2C compatible serial I/O port. [page]

When a key is pressed, the 11 pins connected to the keyboard will have level changes. The chip will get the key value of the pressed key based on the level change, and then store it in the FIFO inside the chip, while pulling the INT foot down to a low level. At this time, the keyboard driver will send a series of commands to the chip through SDA after detecting that INT has become low, and the chip will return the corresponding status and value to the driver through SDA. The level changes of SCL and SDA strictly follow the I2C bus communication signal rules introduced in Section 2.2.

3.2 Software Implementation Framework

The driver layer of Windows CE operating system is divided into two layers: MDD layer (Model Device Driver) and PDD (Platform Dependent Driver), and the framework structure is shown in Figure 4. The MDD layer is some abstract functions that are not directly related to the hardware. It receives data from the PDD layer, completes the key value obtained by processing, and sends a message to notify the program to process the response operation. The PDD layer is directly related to the hardware, implements the hardware interface and passes the obtained hardware characteristics to the MDD layer. 

Driver implementation process, the PDD layer mainly implements keyboard monitoring, opens two threads, and the thread MaxKeyCheckPro monitors the level change of the INT pin. When a key is pressed, INT is pulled low. At this time, when the I2C bus is ready, the command to read the key value is sent through the I2C bus to read the chip's FIFO. After receiving the command, the chip will send the key value stored in the FIFO back to the thread MaxKeyCheckPro through the I2C bus, and at the same time send a notification to the thread KeybdIstThreadProc, and pass the returned key value to the thread KeybdIstThreadProc. The thread KeybdIstThreadProc is then responsible for passing the key value to the MDD layer. The MDD layer is responsible for storing the key value and sending a message to notify the corresponding program to respond to the key value.

The purpose of using two threads is to allow each to complete its own operation without affecting each other. In the case of frequent key triggering, the MaxKey CheckPro thread can quickly obtain the key value and pass it out and immediately wait for the next key press to occur, without delaying the response to the next key press due to processing other operations.

3.3 I2C bus communication process

Since frequent button pressing will cause the I2C bus to be used continuously to read the chip FIFO, it is an important issue to prevent interference between two read and write operations (that is, before one read and write is completed, another read and write operation also occupies the I2C bus, causing confusion in the data of the two times).

For a read/write operation, considering its uninterruptibility to prevent data corruption, a mutex lock is used. That is, only one read/write operation is allowed to occupy the I2C bus at a time. Before a read/write operation begins, wait for the mutex lock until the read/write operation is completed and the mutex lock is released. In this way, before a read/write operation is completed, another read/write operation cannot occupy the I2C bus and can only wait. The specific process is shown in Figure 5: 

3.4 Specific read and write operations

The keyboard driver here is different from the ordinary keyboard driver. It does not need to determine the level change of the keyboard matrix to get the key value. These operations are completed inside the chip. The keyboard controller debounces the key operation and automatically stores it in the FIFO. Therefore, all you need to do is read the FIFO after detecting that the keyboard is pressed. See Figure 6.

But it is worth noting that after each key is pressed, the INT pin will be pulled high, but it will only be pulled low after the FIFO is cleared. If the keyboard continues to be pressed after being pulled low, the key value will continue to be stored in the FIFO. Therefore, the FIFO needs to be cleared for each read operation. However, in actual applications, it is found that when the keyboard is pressed quickly, responding to the operations in the FIFO will affect the performance of the system, so the other key values ​​in the FIFO queue are discarded and only the last one is retained.

4 Performance Analysis

During the whole process, the CPU communicates with the chip through three main lines, realizing fast response and processing of key operations, and can control the anti-shake and response of up to 64 keys. Since the chip encapsulates some functions, the hardware processes them to make the speed faster. Due to the multi-master control feature of I2C, it will not affect the work and performance of other peripherals hanging on I2C.

5 Conclusion

This article introduces the design and implementation of a keyboard driver based on the PXA270 processor and WindowsCE 5.0 operating system. It has been running stably on this platform and has good key processing capabilities.

Reference address:Design and implementation of keyboard driver based on I2C bus

Previous article:Design of keyboard driver based on embedded Linux
Next article:Hardware Design of Multipoint Video Conference Control Unit Based on IXP425 and DM642

Latest Microcontroller Articles
  • Download from the Internet--ARM Getting Started Notes
    A brief introduction: From today on, the ARM notebook of the rookie is open, and it can be regarded as a place to store these notes. Why publish it? Maybe you are interested in it. In fact, the reason for these notes is ...
  • Learn ARM development(22)
    Turning off and on interrupts Interrupts are an efficient dialogue mechanism, but sometimes you don't want to interrupt the program while it is running. For example, when you are printing something, the program suddenly interrupts and another ...
  • Learn ARM development(21)
    First, declare the task pointer, because it will be used later. Task pointer volatile TASK_TCB* volatile g_pCurrentTask = NULL;volatile TASK_TCB* vol ...
  • Learn ARM development(20)
    With the previous Tick interrupt, the basic task switching conditions are ready. However, this "easterly" is also difficult to understand. Only through continuous practice can we understand it. ...
  • Learn ARM development(19)
    After many days of hard work, I finally got the interrupt working. But in order to allow RTOS to use timer interrupts, what kind of interrupts can be implemented in S3C44B0? There are two methods in S3C44B0. ...
  • Learn ARM development(14)
  • Learn ARM development(15)
  • Learn ARM development(16)
  • Learn ARM development(17)
Change More Related Popular Components

EEWorld
subscription
account

EEWorld
service
account

Automotive
development
circle

About Us Customer Service Contact Information Datasheet Sitemap LatestNews


Room 1530, 15th Floor, Building B, No.18 Zhongguancun Street, Haidian District, Beijing, Postal Code: 100190 China Telephone: 008610 8235 0740

Copyright © 2005-2024 EEWORLD.com.cn, Inc. All rights reserved 京ICP证060456号 京ICP备10001474号-1 电信业务审批[2006]字第258号函 京公网安备 11010802033920号