Linux Gpio keyboard Driver development record _omapl138

Linux Gpio keyboard Driver development record _omapl138

Linux basic configuration is complete, these days began to start the development of Linux, from a simple keyboard driver, and gradually understand the development-driven process. Look at the Linux3.3 kernel file under the driver directory, click on the C file inside, feel that the underlying Linux drive mechanism is still very complex, it will take a long time to learn. Now the development can not be said to be called the driver, but also can only be said to drive the application, we learn to drive from the application of the gradual start, go deep inside it.

0. Development readiness

• Kernel source files (when we compile the kernel at the time of the directory, it is important to compile drivers need to rely on these kernel source files)
• Makefile file (compile-driven makefile file)
• Driver source Program
• Application (with main function)

1. Wiring diagram of the keyboard

We mainly use USER0 and USER1 key, two keys, to complete the Linux GPIO keyboard driver development. It can be seen that gpio0_6 and Gpio6_1 mainly collect the information of the keyboard press.

2. KEY.C driver files

The drive structure can be seen primarily in registering Linux kernel devices, and we use Platform_device for kernel registration. From the thought to the graph, we make a definition from the forward order.

2.1 Gpio_key_buttons Structural Body

Linux provides a standard structure, in the # include <linux/gpio_key.h> header file. it is necessary to define the behavior information of the key and specify the Gpio port, which is a structure to deal with the hardware schematic diagram above. The following are definitions related to this structure.

#include <linux/gpio.h>#include <linux/gpio_keys.h>#include <mach/da8xx.h>//Board header file#define Omapl138_keys_bebounce#define Omapl138_gpio_keys_poll_ms#define OMAPL138_USER_KEY0 Gpio_to_pin (0,6)#define OMAPL138_USER_KEY1 Gpio_to_pin (6,1)Static Const  ShortOmapl138_user_key_pins[] = {da850_gpio0_6, Da850_gpio6_1,-1};Static structGpio_keys_button omapl138_user_keys[] = {[0] = {. Type = Ev_key,. Active_low =1,. Wakeup =0,. Debounce_interval = omapl138_keys_bebounce,. Code = KEY_PROG1,. desc ="User_key0",. Gpio = Omapl138_user_key0}, [1] = {. Type = Ev_key,. Active_low =1,. Wakeup =0,. Debounce_interval = omapl138_keys_bebounce,. Code = KEY_PROG2,. desc ="User_key1",. Gpio = Omapl138_user_key1}};

In other platforms may be different definition of Gpio port, I use OMAPL138, the kernel file used is provided by OMAPL138, his inside defines da8xx.h definition of the relevant GPIO macro definition, you need to find your own platform Gpio structure definition, You can modify this macro definition . This structure is very readable, a look can understand, which .code is when we write the application, the key read out the value, you can judge.

2.2 Gpio_keys_platform_data Structural Body

The PLATFORM_DATA structure, as its name implies, is basically related to our entire drive development data.

staticstruct   gpio_keys_platform_data     omapl138_user_keys_pdata    =   {    .buttons                =   omapl138_user_keys,    .nbuttons               =   ARRAY_SIZE( omapl138_user_keys )};

The members inside, just as .buttons we defined the Gpio_keys_button array, .nbuttons is the length, we use the macro function to ARRAY_SIZE complete the value.

2.3 Platform_device Structural Body

Mind map forward, we need to define the platform_device structure, the structure is to deal with the Linux kernel structure to mention. It has the name of the device, .name .id dev .

static  void  omapl138_user_keys_release (struct  device *dev) {}static  
    
     struct  platform_device omapl138_user_keys_device = {
     //can fin d Mount Root by command "DMESG |        grep Gpio-keys ";         
     //Cat/proc/bus/input/devices look at the where the device is.         . Name = 
      "Gpio-keys" ,. id = 
     1 ,                            . Dev = {. Platform_data = &omapl138_user_keys_pdata, . Release = Omapl138_user_keys_release,},}; 
     

.nameThis name can be seen in the kernel debug output when the driver registers with Linux after registering with dmesg | grep gpio-keys the command. The ID of the .id Device Mount node, and the same device ID cannot be duplicated. .devgiven the data and release functions (can be empty).

2.4 Initialization functions and exit functions

The last is the initialization function and Exit function, the final thing is to resigster this function. Register the device with the kernel.

Static int__init Omapl138_user_keys_init (void){intReg Reg = Platform_device_register (&omapl138_user_keys_device);if(REG) {pr_warning ("Could not register baseboard GPIO tronlong keys!"); }Else{PRINTK (kern_info"User keys register successful!"); }returnReg;}Static void__exit Omapl138_user_keys_exit (void) {Platform_device_unregister (&omapl138_user_keys_device); PRINTK (Kern_info"User keys unregister!"\ n");} Module_init (Omapl138_user_keys_init); Module_exit (Omapl138_user_keys_exit); Module_description ("User keys platform driver,"); Module_author ("Carlos Wei."); Module_license ("GPL");

When we use it insmod name.ko , we automatically call the function written in Module_init (), and when we do, we rmmod name.ko automatically call the function written in Module_exit ().

3 Compile the kernel or load it in a modular form

We can either statically compile this driver into the kernel tree or load it into the kernel as a module, and I suggest that it should be added to the kernel in the form of a module at the beginning of development, and then compiled into the kernel after the compilation is mature.

3.1 Compiling

Establish the path of the kernel source files, write good makefile files, compile and upload to the target board any path.

3.1.1 Makefile File

ifneq ($(KERNELRELEASE),)obj-m := key.oelseall:    make -C $(KDIR) M=$(PWD) modules ARCH=arm CROSS_COMPILE=arm-arago-linux-gnueabi-clean:    rm -rf *.ko *.o *.mod.o *.mod.c *.symvers  modul* .button.* .tmp_versionsKDIR=/usr/src/linux-headers-3.3.0-omapl138endif

Here are the more important:

• Kdir=? This location is the path to your Linux source files (the kernel must be compiled correctly beforehand )
• Cross_compile= This specifies cross compiler, my cross compiler name is rather weird arm-arago-linux-gnueabi-

3.1.2 Make a Build Key.ko

After compiling, view the Key.ko file generated by the LS command.

Transfer the Key.ko file to the target board via SCP or FTP.

3.2 Loading drivers and viewing mount nodes

1)insmod key.ko

2) by dmesg checking if the kernel output is successful

3) cat /proc/bus/input/devices View hang in details by command

The point is event1, for a moment our editing application needs to open /dev/input/event1 This device node for the Gpio keyboard operation.

4) test Keyboard input

In the absence of writing an application, we can also make a simple test of the Gpio keyboard in a simple way. The Gpio mount node is handlers = Event1 input:

cat /dev/input/event1

Then we press the keyboard, if the terminal output garbled when we click on the keyboard, it means that our driver is written successfully.

5) Solution-Hung Drive

If we do not need to drive, then we need to do the unlocking drive:

rmmod key.ko

You can also view the kernel output log through the DMESG command.

4 Application Development

Build file: key_app.c

#include <stdio.h>#include <stdlib.h>#include <unistd.h>#include <sys/ioctl.h>#include <time.h>#include <fcntl.h>#include <linux/input.h>intMainintargcChar**ARGV) {intKey_state;intFdintRetintCodestructInput_event buf; FD = open ("/dev/input/event1", o_rdonly);if(FD <0) {printf ("Open Gpio_keys failed!!\ n");return-1; } printf ("Open GPIO keys successful!\ n"); while(1) {ret = read (FD, &AMP;BUF,sizeof(structInput_event));if(Ret <=0) {printf ("Read failed!\ n");return-1;        } code = Buf.code;        Key_state = Buf.value; printf"Wait ...\ n");Switch(code) { CaseKey_prog1:code = '1‘; printf"KEY1 state =%d\ n", key_state); Break; CaseKey_prog2:code = '2‘; printf"KEY2 state =%d\ n", key_state); Break; }} printf ("key test finished.\ n"); Close (FD);return 0;}

A very simple procedure is the output of the case. We compile it:

arm-arago-linux-gnueabi-gcc key_app.c -o key_app.o

The generated KEY_APP.O file is placed in the Linux directory of the target board and then run.

5 Debug Results

These values can be output by pressing the key, which means that our drive development is successful.

Appendix: Source Program

Link: https://pan.baidu.com/s/1pNcEBEj Password: xpsq

Copyright Notice:

1. This article for the Multibeans Team research and development follow the article, without permission shall not be reproduced.

2 · If there is infringement, please contact with me, I will promptly delete.

3 · Respect the results, this article will be used in all the references to the selfless engineers, enthusiasts salute.

Linux Gpio keyboard Driver development record _omapl138