The first experience of driving programming thought---------------led for embedded Linux driver development

This is the day we start the actual combat! Here by the way, ah, come out to do the basis of development is very important Ah, the foundation is not good, sooner or later is to be bad. Personal deep feeling like this embedded development of C language and microcomputer interface and principle is very dependent on, must have a deep foundation to hold the live, or really like some people say, learned a year embedded feel has not found the door.

Can no longer pull, related to the Linux drive development knowledge gray often wide, and then pull the article will become gray often long. First or back to the LED driver itself, since the Linux was ported to arm, to do the hardware knowledge requirements to drive development has been reduced, many have returned to the software, which is a major feature of system programming, of course, also does not rule out that there are a lot of device drivers need to start from scratch.

Although the LED driver seems very simple, but to describe clearly estimated tens of thousands of words are not necessarily enough, this article from the perspective of beginners, focus on the entire software development process and ideas, without too much limitation and details of the analysis, beginners should first grasp a certain class of programming processes and ideas, so as to get started fast, Progress quickly. As a beginner I have always felt that this is the most efficient entry.

Below we enter the writing of the theme led driver:

Since it is in the Linux system under the development of device-driven, unlike in the past, we set a high level of MCU, the driver developed under the Linux system to work in Linux, must conform to the specifications of the Linux system, Linux under the device is divided into three types of character device/block device /network devices. The above three kinds of equipment can not be exhaustive, so also put forward a miscellaneous equipment as a supplement, see the next online most people have led drive equipment to the miscellaneous equipment, this is why? It turned out to be a friendly arm of the manual put it to miscellaneous equipment, haha, so the miscellaneous equipment version is more popular, Wood has the pursuit of people ah! So what do we do with that kind of equipment? Of course, the miscellaneous equipment, hehe ...

Since the LED we are ready to use it as a miscellaneous device to join the system, should not have a name it, there should be an operation symbol bar ...

Stop, stop your yy, the standard form about this device The great God has helped you to define, specifically it exists in the system include, there is a miscdivice.h.

1 struct miscdevice  {2         int minor; 3         const char *name; 4         const struct File_operations *fops; 5         struct List_head list; 6         struct device *parent; 7         struct device *this_device; 8         const char *nodename; 9         mode_t mode;10};

Well, for the sake of uniform specification, we just need to fill in the content according to the standard! To properly use the structure of this device, each member must be clearly understood. The sky is floating four words f u c k

OK, let's calm down and continue to understand it. Check the next minor the word is secondary, here is the second device number meaning. This is because the miscellaneous equipment in order to save the main device number, the use of the common main device number, the secondary device number to distinguish the way to describe the device, so to see this minor is to be filled! Is worthy of a four-level person, the second directly read it! Oh yes ~

Before doing an understanding, this third in the Linux drive is very important, can be called the core, we have a lot of work around this file_operations to operate, it must be a grand study of the File_operatios this structure.

File_operations the existence of this struct is the foundation of all the devices in Linux as files, and why? Because this is what is popularly said, this structure is a relational mapping of file operations and drive operations, and for system operations functions (such as read/write), there are functions that correspond to the operation of the hardware in this structure. Wow this function is incredibly cool! In this way, we have also figured out another problem, that is, why we can not directly over the operating system to operate the hardware, all because it ah! This structure can be seen in the kernel, as well as in the Linux operating system status. Haha the following several members, first not analysis! We do not use this time, feel that the development of Linux under the driver is really a definitely work Ah!

After seeing the file_operations, we naturally know that it is now possible to tap the code to write the driver as long as the structure is clear! So,let ' s go!

First find this awesome structure in the system catalog Include/linux/fs.h:

View Code

When I know there are so many members of the time, then I peed, but, fortunately, we only need to achieve this time the drive needs! Looking at the driver on the manual, Oh yes ~ this time we only need to study two members ower and IOCTL. As you can see, ower is a struct member or that module, and the IOCTL is a function.

So why is the IOCTL function? It's always important to be clear about this problem! Because we said in front of the file_operations function is a map of the operation of the file, we want to control the LED, the essence is to control the level of the IO port, regardless of its operating system driver or microcontroller drive essence is the same! At this time, I instantly understand the bird, ICCTL is not the abbreviation of IO control? Is it the file's control IO? Because we want to control the LED, so need to control the IO port, to control the IO corresponding system call function is not the IOCTL? What we need to do in the driver is to write the IOCTL function, and then the system can invoke the IOCTL system function to correlate to the real drive function via File_operactions. Oh yes ~ finally all clear!

Now, the core of software is open! Since it is the driver, of course, hardware!

These four LEDs are connected to a fixed four IO ports, something like this is clearly explained on the Development Board schematic, and we have to follow the relationship on the Development Board. The four LEDs occupy an IO Register of GPB5/GPB6/GPB7/GPB8, which is the same as the p0/p1 of our microcontroller, P0/P1 is defined in Reg51.h, and the IO port is also defined as <arch/ Regs-gpio.h>, here we declare these four IO port registers, so that we can operate the IO port to control the LED.

1 static unsigned long led_table []= {2         S3C2410_GPB (5), 3         S3C2410_GPB (6), 4         S3C2410_GPB (7), 5         s3c2410_ GPB (8), 6};

It is important to note that the Gpio port connected to the LED can be used for input/output or other functions, and our Development Board is led on a common anode, so we need these gpio ports as output, as long as we low level can let the LED light. Since this IO port has multiple functions, there must be a configuration register associated with it. So we need to define the register for each led as the output.

1 static unsigned int led_cfg_table  []={2         s3c2410_gpio_output,3         s3c2410_gpio_output,4         S3c2410_gpio _output,5         s3c2410_gpio_output,6};

Do all the work ahead, now is the core of the drive. How to control? Is this really a question? At this time suddenly remembered, the front analysis of the file_operations, this thing is not the system and drive the link? Controlling the LED system requires the IOCTL function, so we also need an IOCTL function that is directly connected to the driver in Flie_operations, so we name the function Heatnan_leds_ioctl; the prototype of the function is in front file_ Operaction has been given, a kind of direct form to fill the bright! and the following development ideas are also clear, that is the need for what kind of function directly refer to the file_operactions structure of the parametric model just.

For the LED driver, to implement the application control LED light-up requires the system to call the IOCTL function--to enable the system's IOCTL function to control the hardware--need to establish a real control led driver in the File_operations function- A new control led function (named Heatnan_leds_ioctl here).

First we establish a connection relationship:

1 static struct file_operations dev_fops={2         . Owner = this_module,3         . ioctl= heatnan_leds_ioctl,4};

Once this core bond is established, you must write the HEATNAN_LEDS_IOCTL function!

To write this function you have to understand the two forms of the function, that is, the IOCTL function needs to do homework, the IOCTL in the system function has three parameters, the third parameter is optional, the first parameter represents the operation of the device number, the second parameter represents the Operation command, The third optional parameter can be passed as a parameter with different data types and is not required.

The corresponding IOCTL in the file_operactions has one more parameter, the first two parameters of the system function, the control command is received intact.

View Code

When you look at the code to see there are some such as s3c2410_gpio_setpin functions, you must be in the heart of a sigh! 艹, what about this function?

Why do you have these functions? The reason is that the Linux platform for the arm system is supported, such as these basic functions, when we develop the program can be used, some people think why to use its own writing is not more cool? Personally think from the perspective of learning, but from the development feel still efficient most important, why in the application C + + c more popular, it is because C + + more efficient, more library support, so I think whether it is our software application development or hardware application development, Development of the difficulty must be more and more small, development efficiency is more and more high! Therefore, the platform to provide us with the function can use it!

Once this function is established, we can control the LEDs by indirectly manipulating the HEATNAN_LEDS.IOCTL via the IOCTL function of the operating system.

Here are some of the things that are stylized, the initialization of the module, the exit of the module, and the registration of the device, and some more mundane questions.

Xxxxxxxxxxxxxxxxxxx tired bright, live peeling la,linux drive development feel-rich! @

The following is the entire led driver code, mainly modeled after the data sheet, this time is mainly the introduction of learning and understanding of driving development. Tomorrow is going to go into the drive to get out of the data sheet spicy! The feeling of a good red chicken!

View Code

Finally the TMD finished writing this drive function, but if the thing to end here is also quite perfect ah! In accordance with yesterday's method to successfully put the driver of the modular compilation succeeded in the Development Board,

Results

。。。。。。。。

As a result, burning on the driver test program is really not bright, I use lsmod and dev under the bean found the module is running, the lamp is not bright ...

Later I guess it may be the board of the kernel has led driver, I this led driver and that led drive essence is the same as the name is not the same, it should be a conflict .....

So remove the screen to watch, power on, lights all bright, load my driver, lights all out, oh yes ~ seems I guess there is a reason???????

Well, don't talk about the Sancent! Tidy up your hairstyle and continue tomorrow!

such as Serial line back, be sure to get this problem clear, see is not this! If you encounter this problem, Daniel may share the experience, grey often thanks!

Driving Programming:

1 driver programming a kind of indecisive feeling, in the Linux system programming, the vision stays on the hardware far is not enough, also must pay attention to the Linux system external interface, only then can achieve the external interface and the writing driver interface perfect convergence.

2 feel-driven development like dancing with fetters, basic related functions of the underlying hardware, Linux has been supported, upper-level system interfaces, Linux systems have been developed, what we can do is to re-hardware and system between the reasonable. is a very test of human life! Early feeling is tired, late is probably IQ challenge it!

3 When analyzing Linux drivers, it is possible to use flashback analysis, start with the operating system interface, step-by-step to find and hardware perfect fit point ...

The first experience of driving programming thought---------------led for embedded Linux driver development