Shulou(Shulou.com)06/02 Report--

This article shows you how to get started with OMAPL138-based Linux device driver development, the content is concise and easy to understand, it will definitely brighten your eyes. I hope you can get something through the detailed introduction of this article.

LED device driver LED device driver parsing

The corresponding relationship between the LED number and GPIO of the development board is as follows:

Table 1

Development board model

GPIO0 [0]

GPIO0 [5]

GPIO0 [1]

GPIO0 [2]

TL138/1808-EVM

D7

D6

D9

D10

TL138/1808-EasyEVM

D7

D6

D9

D10

TL138/1808-EthEVM

D7

D6

D9

D10

TL138/1808F-EasyEVM

\

GD1

GD2

GD3

TL138/1808F-EVM

\

D1

D2

D3

The source code of the LED device driver is found in the development board data CD, and its path is:

Led.c:demo\ driver\ linux-3.3\ led\ led.c

Take the TL138/1808-EVM development board as an example to explain this device driver.

# include

# include

# include

# include

# include

# include

/ * because the platform-related header files are used, ARCH=arm is required at compile time * /

# include

# include

# include

# include

/ * define the GPIO corresponding to the 4 user LED, and the corresponding number of the development board LED is D7Magic D6Magi D9Magi D10 * /

# define DA850_USER_LED0 GPIO_TO_PIN (0,0)

# define DA850_USER_LED1 GPIO_TO_PIN (0,5)

# define DA850_USER_LED2 GPIO_TO_PIN (0,1)

# define DA850_USER_LED3 GPIO_TO_PIN (0,2)

/ * assign the tl som board LED-GPIOs*/

Static const short da850_evm_tl_user_led_pins [] = {

/ * These pins are definition at file * /

DA850_GPIO0_0, DA850_GPIO0_1, DA850_GPIO0_2, DA850_GPIO0_5

-1

}

/ * define 4 LED corresponding GPIO number, effective level (lights-out level), name, trigger mode, etc. * /

/ * use the standard gpio-led framework provided by Linux * /

Static struct gpio_led da850_evm_tl_leds [] = {

{

.active _ low = 0, / * effective level (flameout level): low level * /

.gpio = DA850_USER_LED0, / * GPIO number: LED corresponds to gpio pin * /

.name = "user_led0", / * name: corresponding to the name under / sys/class/leds/ * /

.default _ trigger = "default-on", / * trigger mode: lit by default * /

}

{

.active _ low = 0

.gpio = DA850_USER_LED1

.name = "user_led1"

.default _ trigger = "default-on"

}

{

.active _ low = 0

.gpio = DA850_USER_LED2

.name = "user_led2"

.default _ trigger = "default-on"

}

{

.active _ low = 0

.gpio = DA850_USER_LED3

.name = "user_led3"

.default _ trigger = "default-on"

}

}

Static struct gpio_led_platform_data da850_evm_tl_leds_pdata = {

.leds = da850_evm_tl_leds

.num _ leds = ARRAY_SIZE (da850_evm_tl_leds)

}

Static void led_dev_release (struct device * dev)

{

}

/ * use the standard platform_device framework provided by Linux * /

Static struct platform_device da850_evm_tl_leds_device = {

.name = "leds-gpio"

ID = 1, / * first determine whether the id number is used. This id is the id of platform_device, regardless of the number of LED * /

.dev = {

.platform _ data = & da850_evm_tl_leds_pdata

.release = led_dev_release

}

}

Static int _ init led_platform_init (void)

{

Int ret

# if 0

/ * use davinci pinmux to set the interface, and configure the pins corresponding to LED into gpio mode * /

Ret = davinci_cfg_reg_list (da850_evm_tl_user_led_pins)

If (ret)

Pr_warning ("da850_evm_tl_leds_init: User LED mux failed:"

"% d\ n", ret)

# endif

/ * register the LED device device, and the system LED framework will receive the registration and generate the corresponding LED node * /

Ret = platform_device_register (& da850_evm_tl_leds_device)

If (ret)

Pr_warning ("Could not register som GPIO expander LEDS")

Else

Printk (KERN_INFO "LED register sucessful!\ n")

Return ret

}

Static void _ exit led_platform_exit (void)

{

Platform_device_unregister & da850_evm_tl_leds_device)

Printk (KERN_INFO "LED unregister!\ n")

}

Module_init (led_platform_init)

Module_exit (led_platform_exit)

MODULE_DESCRIPTION ("Led platform driver")

MODULE_AUTHOR ("Tronlong")

MODULE_LICENSE ("GPL")

The above is the parsing of the LED device driver. For the Linux versus LED device framework, here is a little explanation:

Linux's LED device class is described in detail in the kernel "Documentation/leds/leds-class.txt" file.

After registering a LED device successfully, the corresponding device node will be generated "/ sys/class/leds/".

Users can control LED dimming by reading and writing to the brightness file in the node directory.

For the operation of GPIO port, there are the following steps:

Look at the schematic of the development board to find the GPIO connected to the LED. The GPIO connected between TL138/1808-EVM development board and LED are GPIO0 [5], GPIO0 [0], GPIO0 [1] and GPIO0 [2] respectively.

Check the data manual of OMAP-L138, find the address of the corresponding PINMUX register, and set the corresponding bit in the register of the corresponding pin to the working mode of GPIO. PINMUX1 is used in this example.

Sets the direction register for GPIO. In this routine, the GPIO port is configured as output.

Configure the data register of GPIO, write "1" to indicate high output level and write "0" to indicate low output level.

Compile LED device driver

Makefile is used here to compile the LED device driver. There are sometimes many source files in the project, which are placed in several directories according to type, function and module. Makefile defines a series of rules to specify which files need to be compiled first, which files need to be compiled later, which files need to be recompiled, and even more complex functional operations, because Makefile is like a Shell script, which can also execute operating system commands.

In the development board data CD, there is a LED device driver Makefile file, and its path is:

Makefile: demo\ driver\ linux-3.3\ led\ Makefile

The following is the parsing of the LED device driver Makefile file:

Ifneq ($(KERNELRELEASE),)

Obj-m: = led.o / * defines the driver file to be compiled as led.c and the generated module name as led.ko*/

Else

/ * the following defines the kernel source code, driver source code path, platform, cross-compilation tool chain and other parameters used to run the compilation command * /

All:

Make-C $(KDIR) masking $(PWD) modules ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-

/ * define the files to be cleared when running "make clean" * /

Clean:

Rm-rf * .ko * .o * .mod.o * .mod.c * .symvers modul* .button. * .tmp _ versions

# help: make KDIR=

Endif

Figure 1

Copy the led.c and Makefile files from the CD "demo\ driver\ linux-3.3\ led" to any path of the development system Ubuntu, and run the following command in the led.c and Makefile directories to compile the LED device driver:

Host# make KDIR=/home/tl/omapl138/linux-3.3

Figure 3

Copy the button.c and Makefile files from the CD "demo\ driver\ linux-3.3\ button" to any path in Ubuntu, and run the following command from the directory where the button.c and Makefile files are located to compile the keystroke device driver:

Host# make KDIR=/home/tl/omapl138/linux-3.3 CROSS_COMPILE=arm-none-linux-gnueabi-

Figure 5

You can see that the test program image file button_test is generated in the current directory. For specific keystroke testing steps, please refer to the user manual quick experience section.

The device driver module is statically compiled into the kernel

If you need to statically compile the device driver module into the kernel, follow these steps.

Take the LED device driver as an example, put the device driver source code led.c under the CD "demo\ driver\ linux-3.3\ led" directory under the kernel source code "drivers/char" directory, modify the Kconfig menu configuration file under the kernel source code "drivers/char" directory, and add the following under the "menu" Character devices "line:

Figure 6

Config USER_LED:USER_LED is the configuration name of the driver.

Tristate "user led": the name of the driver that appears in the menu bar when configuring the kernel with "make menuconfig".

Depends on ARM: indicate the driver under the ARM platform.

Default y: statically compiled to the kernel image by default.

-supplementary information about the help---: driver to let users know more about the role of this driver.

Modify the Makefile compilation file under the kernel source code "drivers/char" directory, and add the following at the end:

Obj-$ (CONFIG_USER_LED) + = led.o

Figure 7

Obj-$ (CONFIG_USER_LED): "USER_LED" this content must be consistent with what was added in the Kconfig file in the previous step.

+ = led.o: this prefix must be "led". When compiling the driver, the system will look for the led.c file in the "driver/char" directory.

The top-level directory of the kernel source executes the following command to view the device kernel configuration:

Host# make menuconfig ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-

There is a driver configuration option for "user led" under "device drivers- > character devices", as shown below:

Figure 8

The preceding "*" symbol represents the static compilation of the device driver module into the kernel. Save the exit, recompile the kernel, and then use the compiled kernel image to start the development board, you can find that without installing led.ko, you can directly run led_loop.sh to realize the loop lighting of LED.

If you need to compile the device driver module into the form of a kernel module, press the spacebar to change "*" into "M", which means no compilation.

The above is how to get started with the development of Linux device drivers based on OMAPL138. Have you learned any knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.