LED will blink for me: Control the light-emitting secondary tube

First, led the implementation principle of the drive:

Control the continuity of the transistor through the high and low levels of the gpc0_3 and gpc0_4 pins, thus controlling the LED light to light off.

Although the Linux driver deals directly with hardware, it is not the Linux driver that writes data directly to the memory in the hardware, but interacts with the native I0 memory (I/O memories, which are located in the kernel space). The so-called 1/0 memory is through a variety of interfaces (PCI, USB, Bluetooth, Ethernet port, etc.) connected to the host (PC, mobile phone) hardware (network card, sound card, camera, etc.) in the host memory mapping.

Second, Writing LED Drivers

1> first we need to feel the result of the LED driver:

Before you test the LED driver, you need to connect the S3C board with a USB cable and then open the power switch on the S3C Development Board. After successful startup, execute the build.sh script file to compile and install the LED driver. If everything goes well, build. The sh script file automatically uploads the S3c6410_leds.ko file to the S3C Development Board and installs it.

You can control the LEDs on the Development Board with the following command:

ADB shell "echo ' 1 ' >/dev/s3c6.410_leds" # Open the 1th LEO, the other LEDs are off

ADB shell "echo ' 1010 ' >/dev/s3c6410_leds" # 1th and 3rd LEDs Open, 2nd and 4th LEDs off

2> Second: Create LED-driven device files, as follows:

1th Step: Initialize the Cdev with the Cdev_init function:

Describing a device file requires a cdev struct. Most member variables of Cdev do not need to be initialized ourselves, as long as the Cdev init function is called to initialize most of the Cdev member variables.

2nd step: Specify the device number

The device number of the Linux device file is the primary device number and the secondary device number. represented by 1 int types (DEVT). The first 12 bits represent the main device number, and the last 20 bits represent the secondary device number. There are two ways to specify the device number:

1. Specify (hard code) directly in the code

2, dynamic distribution.

I.nt alloc_c hrdev_region (dev_t *dev, unsigned baseminor, unsigned count, const char *name) where Dev represents the device number pointer (is an int pointer). The Alloc_chrdev_region function randomly assigns-an unused master device number and assigns a secondary device number according to the Baseminor parameter value.

If you specify a device number directly, you need to register the character device area with the Register_chrdev_region function.

You typically specify the device number by specifying the main device number and the secondary device number, so you need the MKDEV macro to combine the main device number and the secondary device number into a device number, as follows:

Major represents the main device number, minor indicates the secondary device number

int Dev_number =mkdev (m:ajor, minor);

You can use major and minor macros to get the main device number and the secondary device number from the device number, with the following code:

Get the main device number

int major=major (dev_number);

Get the secondary device number

int minor= MAJOR (dev number);

3rd Step: Use the Cdev_add function to add the character device to the character device array in the kernel

The Cdev_add function is used to add a character device to the probes array, which holds the character device you have created.

4th step: Create a struct class using the Class_create macro

The struct class contains some variables related to device files and some callback function pointer variables.

5th step: Create a device file using the Device_create function

Use the following code to flick the Device_create function to create a device file.

Device Create (LEDs class, NULL, dev number, null, DEVICE NAME);

Where the LEDs class represents the struct class, the dev number represents the device name, and device name indicates the names of the devices ' files.

3> uninstalling LED-driven device files

Uninstalling Linux-powered device files is a little simpler--you need to call the Device_destroy, Class_destroy, and Unregister_chrdev_region methods in turn.

4> setting register and initializing LED driver

The ARM processor has multiple registers, by setting the values of different registers. You can set the status of the LED PIN, open or disable the pull-up (pull-up) circuit, and control the light and off of the LEDs.

Attention:

1. LEDs have two pins: Gpbo and GPBI. One of the pins is connected to the GPIO port on the ARM processor, and the other pin is connected to the power supply via a current-limiting resistor: VCC3. When the Gpio port is low, the LEDs generate a voltage difference at both ends, and the LEDs emit current through and glow, whereas when the Gpio port is high, there is no current in the LED and the LED will go off.
2. The control LEDs need to be completed by 3 registers. These 3 registers are Gpmcon (port configuration Register), Gpmdat (port data Register), and Gpmpud (port pull-up circuit register).
3. Each register can use 4 bytes, which is the space occupied by an int type of data.
4. Use the low 16 bits of the Gpmcon register to set the properties of the two ports (GPBO and GPB L) of the LEDs to Output.
5. The low 4-bit control using the Gpmdat register controls the light and off of 4 LEDs.
6. A low 8-bit pull (pull-up) circuit that uses GPMPUD to open 4 LEDs respectively.

It is generally necessary to initialize the above 3 registers when the LED driver is loaded. You can initialize a register by writing an initialization function--à call the LEDS_INIT_GPM function in the Leds_init function.

5> Control LED

LED driver can use the following two ways to control the led:1, through the string control LE D, 2, through the l/0 command control LED;

Second: The LED driver must receive the corresponding data. If the LED is controlled by a string. Need to use. The Fif.e_operations.write function. If you control LEDs with the i/0 command, you need to use the FILE__OPERATIONS.IOCDL function.

6> module parameters for LED driver

Using a module parameter: The Linux driver specifies a module parameter that requires the use of a Module_param Cname, type, perm) macro. Where name represents the parameter name, type represents the parameter type, and perm represents read/write permissions.

The types of parameters supported by Module_param include Byte, short, ushort (unsigned short), int, uint (unsigned int), long, ulong (unsigned long), charp (character pointer), BOOL, and Invbool (boolean inverse).

Therefore: Modify the LED driver code to add a module parameter for the LED driver:

The first is to define a variable (leds_state) that holds the parameter value of the module,--àmodule_param the information about the module parameter--à modify the code of the Leds_init function, and change the parameter value of the LEDS_INIT_GPM function to Leds_state (because the module parameter values are the opposite of the rules for led driver control LEDs).

Extended:

Use the following command to test the module parameters of the LED driver:

# adb shell Insmod/data/1ocal/s3c6410_leds.ko leds_state=3 lights up two LEDs near the battery

Use the following command to see the contents of the Leds_state file as 3:

# adb Shell Cat/sys/module/s3c6410_leds/parameters/leds_state

Use the following command to change the contents of the Leds_state file to 5

# adb Shel L ' echo 5 >/sys/module/s3c6410_leds/parameters/leds_ State ' After modifying the contents of the Leds_state file. The Leds_state value in the LED driver code will change to 5.

Using the module parameters we need to note:

1. Use pointer-type data when specifying the array length by the 3rd parameter of the Module_param_array macro;

2. If the Linux driver contains multiple module parameters, these parameters need to be enclosed in single or double quotation marks;

3. Specify the parameter values for the array type, and no spaces before or after commas.

7>led lamp complete code writing.

Third, Test LED Driver

In this chapter of the learning process, the test method has been mentioned earlier, here is a more complex method: You can send a string to the LED device file, you can also send i/0 control commands. Its testing methods include executable program testing, NDK testing, and Java testing.

1> General Program for writing test I/O control commands

LED drivers have two ways of interacting with device files:

Write directly to string data and I/O control commands, respectively.

Writing data directly to a device file can be done using the command line, or through the write function. However, the i/0 control command can only be emitted through the IOCLL function.

Note: There are many ways to compile your Android source code, such as using a separate cross compiler, ANDROIDADK, and so on. If the Android source code compiled, to ensure that the native Android source code, and in the /development directory for the IOCTL directory to establish a symbolic link, the symbolic link name must be the IOCTL.

1. In the IOCTL directory there is a build_android.sh script file, the reader can directly run the script file using Adroid source code to compile the IOCTL "premise: according to Build_ The path in the android.sh file determines the location of the Android source code, or modifies the Android source code path in the build_android.sh file "-----à first compile the test_ The ioctl file----à uploads the generated ioctl file to the "/data/local" Directory of the Development Board, and finally executes the IOCTL command.

Note: The command line parameters of the IOCTL must be at least 3 (extra ignored), and if the command line parameters are less than 3, the usage hints for the IOCTL command are output.

2. Executables running on the Development Board can also be developed in the Eclipse integration environment. Since the IOCTL is generic, 1 Eclipse projects should be built separately for each program that needs to be tested, when we test a program, for example: LEDs. We need to create an Eclipse directory to store the content of the Eclipse project. In addition, 1 script files are created separately for each test program, and the last command passes 3 parameters for the IOCTL command, which is as follows:

adb shell '/data/loctal/ioctl/dev/s3c6410_leds 1.2 '//The third LED is lit.

2> using NDK to test LED drivers

NDK Program tests and executable program tests are similar. Only the NDK library can be called by a Java program, and an executable program in an Android system cannot be called directly in a non-root state. So if you want to test Linux drivers in an Android app, the most straightforward way is to use the NDK.

3> using Java test LED driver

Because the JDK does not provide an API for sending I/O commands, using Java can only test the LED driver by sending a control string.

Four, Led Drive Porting

The ability of the Android system to function properly depends largely on whether Android can recognize the hardware of the current device, such as display, Wi-Fi, GPS, GSM, Bluetooth, various sensors, and so on, the work of identifying these devices is primarily done by the Linux driver. Linux drivers must be compiled under the currently used Linux kernel to be installed on the current Linux or Android system. The simplest porting of LED drivers is to compile them under different Linux kernel versions.

For example: Led Driver for example:

The LED driver controls the LED's light-out by setting the Gpmdat register. The low 4 bits of the Gpmdat register control 4 LEDs respectively. 0 indicates the LED is turned on and 1 indicates the LED is turned off. This is the setup on the OK64 1 0 Development Board. If the LED driver is to be ported to another s3c6410-based development, and the target board is exactly the same as the GPMDA1 of the OK6410 Development Board, the low 4-bit representation of the Register, that is, 1 means turn on the led,0 to turn off the LED, then the LED driver The code will be changed accordingly. The first thing to change is the Leds_init function. After the LED driver is loaded, the default state of 4 LEDs is set with OxE. On the new Development Board, it is necessary to turn OxE into OXL.

We also need to modify the code that controls the LEDs, for example, the following code is used to send the control string. The code where the switch LEDs are generated needs to be swapped.

Note: It is important to migrate Linux as far as possible without modifying the Linux driver interface when modifying the source code of the Liunx driver.

LED will blink for me: Control the light-emitting secondary tube