All Aspects of Embedded Linux Driver Development

② Understanding ARM Architecture Processors

Two books are recommended:

2. Selectively read ; read the relevant section when you want to understand a specific area.

4. Root File System

03

Five Methods for Driver Program Design

1. Use Design Patterns

Design patterns are solutions to problems that frequently occur in software. Developers can choose to waste precious time and budget reinventing a solution from scratch or select the most suitable one from their toolbox. When microprocessors first appeared, low-level drivers were already mature, so why not utilize existing mature solutions?

Driver design patterns can be roughly divided into the following four categories: Bit bang, polling, interrupt-driven, and direct memory access (DMA).

Bit bang mode: When the microcontroller has no peripherals to execute functions, or when all peripherals have been used, and a new request arises, developers should choose the Bit bang design mode. Bit bang mode solutions are efficient but often require a lot of software overhead to ensure their implementation. Bit bang mode allows developers to manually complete communication protocols or external behaviors.

Polling mode is used to simply monitor events in a polling scheduling manner. Polling mode is suitable for very simple systems, but many modern applications require interrupts.

Interrupts allow developers to handle events as they occur without waiting for the code to check manually.

DMA (Direct Memory Access) mode allows other peripherals to handle data transfer requirements without driver intervention.

2. Understand Real-Time Behavior

A real-time system’s ability to meet real-time requirements depends on its driver programs. Poorly written drivers are inefficient and may cause uninformed developers to abandon system performance. Designers need to consider two characteristics of drivers: blocking and non-blocking. A blocking driver will prevent any other software from executing until it completes its work. For example, a USART driver can load a character into the transmission buffer and wait until it receives a transmission end flag before proceeding to the next operation.

On the other hand, non-blocking drivers generally utilize interrupts to achieve their functionality. The use of interrupts can prevent the driver from intercepting other software’s execution while waiting for an event to occur. The USART driver can load a character into the transmission buffer and then wait for the main program to issue the next instruction. The setting of the transmission end flag will trigger an interrupt to allow the driver to proceed to the next operation.

Regardless of the type, to maintain real-time performance and prevent failures in the system, developers must understand the average execution time of the driver and its worst-case execution time. A complete system may face larger safety issues due to a potential risk.

Why reinvent the wheel when time and budget are tight? In driver program development, reuse, portability, and maintainability are key requirements for driver design. Many of these features can be illustrated through the design and use of a hardware abstraction layer (HAL).

The hardware abstraction layer (HAL) provides developers with a way to create a standard interface to control the microcontroller’s peripherals. Abstraction hides implementation details and instead provides visual functions, such as Usart_Init and Usart_Transmit. This method allows any USART, SPI, PWM, or other peripherals to have common characteristics supported by all microcontrollers. Using HAL hides the details of lower-level, specific devices, allowing application developers to focus on application needs rather than how the underlying hardware works. At the same time, HAL provides a container for reuse.

4. Refer to Data Manuals

Microcontrollers have become increasingly complex over the past few years. Previously, to fully understand a microcontroller, one needed to master a single data manual of about 500 pages. Nowadays, a 32-bit microcontroller typically comprises a portion of data manuals, datasheets for the entire microcontroller series, hundreds of datasheets for each peripheral, and all errata. Developers wishing to master this content fully need to understand thousands of pages of documents.

Unfortunately, all of these data manuals are what a driver program truly needs to be implemented reasonably. Developers must collect and sort the information contained in each data manual from the beginning. Typically, each of them needs to be accessed for the peripherals to start and run. Key information is scattered (or hidden) across each type of data manual.

5. Beware of Peripheral Failures

Recently, I had the opportunity to port a series of microcontroller drivers to other microprocessors. Manufacturers and data manuals indicated that the PWM peripherals were the same between the two microcontroller series. However, the reality was that there were significant differences when running the PWM driver. The driver only worked on the original microcontroller and was ineffective on the new series of microcontrollers.

After repeatedly reviewing the data manuals, I found a completely unrelated note in the data manual indicating that the PWM peripheral would be in a fault state when powered on and needed to clear a flag hidden in a register. At the start of driver implementation, confirm any potential faults of the peripheral and check for errors in other seemingly unrelated registers.

Advice from Experts on Embedded Driver Development

Reflections of Self-Learners in Embedded Drivers

It may be related to being taught as a child not to be a bookworm; as a child, obedient and serious children are greatly influenced by the education of elders. Many influences, if you do not carefully observe yourself, you cannot perceive these ingrained concepts. In my growth process, the education from these elders only formed my viewpoints when I thoroughly recognized that a certain concept was incorrect, but these viewpoints are just a drop in the ocean among all values.

This dislike for superficial understanding is extreme in today’s society because many things you learn are not starting from zero. For instance, the programming languages you use are high-level rather than low-level or machine code, so my entire learning process is very slow. Let’s say, as mentioned earlier, I have been learning for more than half a year, but I have been in embedded systems for two years now, meaning that I have spent over a year in stagnation during the learning period.

Learning embedded systems, or modern computer programming, requires you to accept its settings and models. Conversely, when you truly accept its settings and models and remember them, I believe you have learned well.

Yesterday, I had another moment of rebirth. Recently, I have been working on drivers, and I almost gave up on continuing down the embedded path due to an LCD driver. Last night, unable to sleep, I opened learning videos and lay in a room that had been dark for a long time, probably around 3 or 4 o’clock in the morning. Previously, I had been learning to write driver source code, which was almost no different from bare-metal programming, just using some kernel registration interface functions.

Recently, I wanted to switch things up because many device drivers come pre-installed in the kernel, and there are device drivers for various platforms. I thought if I could familiarize myself with the programming of the kernel’s built-in drivers, I would only need to modify them when writing a driver for a specific device in the future. Through studying the LCD platform device driver, I understood its programming ideas and even recognized this idea, which made me question the significance of learning to write drivers from scratch; why not directly teach how to modify kernel source drivers?

So I continued to modify the kernel driver source code according to the book, but the issue was that the book stated their modifications ran successfully, yet no matter how I debugged, I failed. I repeatedly checked whether my modifications matched those in the book, and after many checks, I still didn’t find any differences. However, I discovered that the kernel source code in the book had slight differences from the source code I was using (of course, the book didn’t provide all the source code, just the modified parts nearby). This is the discovery that these unrelated source codes and my source code had slight differences, such as my source code containing some additional settings (which seemed unimportant).

After confirming that my modifications matched the book but still failed, I compared them with the successfully running self-written driver and gradually found that I had not activated the device and did not illuminate the backlight. It seemed that there were also issues with the register settings after memory allocation because the addresses were calculated using various macro definitions, and I was unsure whether the final calculated addresses matched my register addresses, as the final addresses calculated in the driver source code were virtual addresses. So I compared the self-written driver and made small modifications, but I still didn’t succeed before going to bed.

I wanted to learn in a way that I could confidently identify issues at a glance and easily resolve them. I admit I have been a bit impatient. However, after a night of desperate thinking and struggle, I seem to have come to an understanding: Why do embedded learning videos teach writing drivers from scratch?

Now let me discuss the issues with self-written drivers and kernel driver source code:

Self-written Drivers:

The program is simple and concise; it can only drive a specific device. If the device changes and support for another model is needed, you need to modify that driver again; if the system needs to support two types of LCDs simultaneously, it will become complex, and the simplicity advantage of the kernel driver will decrease significantly; if you want the driver to support multiple devices, then self-written drivers will lose their simplicity advantage compared to kernel driver source code due to differences in programming ideas.

Kernel Built-in Driver Source Code:

① From the system perspective, variable and macro definitions are used extensively; some macro definition values are designed to allow different values to be called at different stages, turning a simple assignment into multiple calculations to check whether the value meets usage requirements. Since we are not the coders of that driver, we are unclear about the benefits of this approach. Perhaps the kernel driver source code developers consider this an approach to reduce overall system code, making it more concise. For each device, assigning specific values would add hundreds of lines of code for all devices in the system. So it is better to let each device calculate suitable values based on various platforms for a certain macro, while similar calculations are integrated together to reduce the number of lines of code in the system. Thus, the driver source code in the system is an integration of the system developers’ work, based on the overall framework of the system.

② The kernel built-in driver also contains some code for compatibility with previous versions. For instance, when hardware memory resources were scarce, methods like using palettes were needed to reduce memory usage during program execution. This can also increase the complexity of the code; this step, while not necessary, if not handled well, may cause the LCD driver to fail to work normally.

③ The program is complex; to accommodate multiple device models, it adds different device drivers more simply. The kernel abstracts and separates the driver into platform management, driver code (hardware-independent code), and device code (hardware-related code). When users add new device drivers, they only need to check the matching information in the platform management section and provide a hardware device-related code (in a specified format) file.

Now, let’s evaluate from the perspective of a driver developer rather than a system developer.

① Self-written drivers are concise and have clear points. For driver developers, this is useful because regardless of which kernel version or chip platform you are using, you can easily confirm the status of the hardware device. If the self-written code passes, you can use the parameters used in the self-written code to cross-check and modify the kernel, then test it again. If it fails, you can first shield the extra settings in the kernel, compile it, and find the error location based on the prompts to make modifications. Because these extra settings can be problematic if set incorrectly; it is challenging to locate the error.

Self-written drivers are useful in this regard because they allow you to eliminate the likelihood of unrelated failure issues and identify error locations with less code. If you confirm that your settings meet the necessary requirements for that device and it still fails, you can confidently suspect a hardware issue. If the self-written code succeeds, it can also serve as a standard for modifying kernel drivers.

② The kernel driver source code’s support for managing multiple device models is the reason I use it. First, understand the device driver structure for this version of the platform; if adding model support, you can use the parameters and settings from the self-written driver. If it is the first time starting this type of device, you need to check the integrity of the structure. If the structure is complete, and the parameters are correct, but it still shows an error, then simplify the kernel driver source code to the straightforward settings of the self-written driver. Ultimately, it transforms into a self-written driver based on the kernel driver architecture. If it still fails, it is undoubtedly a structural issue.

How to Write Embedded Linux Device Driver Programs?

1. The Concept of Linux Device Driver

System calls are the interface between the operating system kernel and application programs, while device driver programs are the interface between the operating system kernel and machine hardware. Device drivers shield hardware details from application programs, so that in the eyes of application programs, hardware devices are merely device files, and application programs can operate hardware devices as if they were ordinary files. Device drivers are part of the kernel and perform the following functions:

4. Detect and handle errors occurring with the device.

Under the Linux operating system, there are three main types of device files: character devices, block devices, and network devices. The main difference between character devices and block devices is that when a read/write request is issued to a character device, the actual hardware I/O generally occurs immediately. In contrast, block devices use a portion of system memory as a buffer; when a user process requests a device, if the request can be satisfied, the requested data is returned. If not, a request function is called to perform the actual I/O operation. Block devices are primarily designed for slow devices such as disks to avoid consuming excessive CPU time waiting.

It has been mentioned that user processes interact with actual hardware through device files. Each device file has its file attributes (c/b), indicating whether it is a character device or a block device. Additionally, each file has two device numbers: the first is the major device number, which identifies the driver program, and the second is the minor device number, which distinguishes different hardware devices using the same device driver program. For example, if there are two floppy disks, the minor device number can be used to differentiate them. The major device number of the device file must match the major device number applied for during driver registration; otherwise, the user process will not be able to access the driver program.

Finally, it is essential to mention that when a user process calls a driver program, the system enters kernel mode, where preemptive scheduling no longer occurs. This means the system must complete the sub-function of your driver program before it can proceed with other tasks. If your driver program enters an infinite loop, unfortunately, you will have to restart the machine, followed by a lengthy fsck.

Let’s write the simplest character device driver program. Although it does nothing, it will help us understand how Linux device drivers work. Input the following C code into the machine, and you will obtain a real device driver program.

Since user processes interact with hardware through device files, the methods of operating device files involve some system calls such as open, read, write, close, etc. Note, it is not fopen or fread. But how do we associate system calls with the driver program? This requires understanding a very critical data structure:

struct file_operations {int (*seek) (struct inode *, struct file *, off_t, int); int (*read) (struct inode *, struct file *, char *, int); int (*write) (struct inode *, struct file *, off_t, int); int (*readdir) (struct inode *, struct file *, struct dirent *, int); int (*select) (struct inode *, struct file *, int, select_table *); int (*ioctl) (struct inode *, struct file *, unsigned int, unsigned long); int (*mmap) (struct inode *, struct file *, struct vm_area_struct *); int (*open) (struct inode *, struct file *); int (*release) (struct inode *, struct file *); int (*fsync) (struct inode *, struct file *); int (*fasync) (int, struct file *, int); int (*check_media_change) (struct inode *, struct file *); int (*revalidate) (dev_t dev); }

Each member of this structure corresponds to a system call. User processes utilize system calls for operations such as read/write on device files. The system call finds the corresponding device driver program through the major device number of the device file, then reads the function pointers of this data structure, and subsequently hands control over to that function. This is the basic principle of how Linux device drivers work. Therefore, the main task of writing a device driver program is to write sub-functions and fill in the various fields of file_operations.

Now let’s start writing the subprograms.

#include <linux/types.h> Basic type definitions#include <linux/fs.h> Related header files for file systems#include <linux/mm.h> #include <linux/errno.h> #include <asm/segment.h> unsigned int test_major = 0; static int read_test(struct inode *inode, struct file *file, char *buf, int count){ int left; User space and kernel spaceif (verify_area(VERIFY_WRITE, buf, count) == -EFAULT ) return -EFAULT; for(left = count ; left > 0 ; left--) { __put_user(1, buf, 1); buf++; } return count; }

This function is prepared for the read call. When read is called, read_test() is invoked, writing 1 to the entire user buffer. buf is a parameter of the read call. However, when read_test is called, the system enters kernel mode. Therefore, the buf address cannot be used; instead, __put_user() must be used, which is a function provided by the kernel for transmitting data to users. Additionally, there are many similar functions. Please note that before copying data to user space, buf must be verified for usability. This is done using the verify_area function to validate that BUF is usable.

static int write_test(struct inode *inode, struct file *file, const char *buf, int count){ return count; } static int open_test(struct inode *inode, struct file *file ){MOD_INC_USE_COUNT; Increment module count to indicate that the current kernel has a device loaded into the kernelreturn 0; } static void release_test(struct inode *inode, struct file *file ){ MOD_DEC_USE_COUNT; }

struct file_operations test_fops = {  read_test,  write_test,  open_test,  release_test,};

The main body of the device driver program can be considered complete. Now, the driver program needs to be embedded within the kernel. The driver program can be compiled in two ways. One is to compile it into the kernel, and the other is to compile it into modules. If compiled into the kernel, it will increase the kernel size, require modifications to the kernel source files, and cannot be dynamically unloaded, making debugging inconvenient. Therefore, it is recommended to use the module method.

int init_module(void){ int result; result = register_chrdev(0, "test", &test_fops); Register the entire interface for device operationsif (result < 0) { printk(KERN_INFO "test: can't get major number
"); return result; } if (test_major == 0) test_major = result; /* dynamic */return 0; }

void cleanup_module(void){ unregister_chrdev(test_major, "test"); }

An extremely simple character device can be considered written; let’s name the file test.c.

Now compile:

$ gcc -O2 -DMODULE -D__KERNEL__ -c test.c 

-c indicates the output specified name, automatically generating the .o file.

The file test.o is the device driver program.

If the device driver program has multiple files, compile each file using the command above, then

ld -r file1.o file2.o -o modulename

The driver program has been compiled; now let’s install it into the system.

$ insmod -f test.o

If the installation is successful, you can see the device test in the /proc/devices file, along with its major device number. To uninstall, run:

$ rmmod test

The next step is to create the device file.

mknod /dev/test c major minor

c indicates character device, major is the major device number, which can be found in /proc/devices.

Use the shell command

$ cat /proc/devices

to obtain the major device number; you can add the above command line into your shell script.

The minor device number can be set to 0.

#include <stdio.h> #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> main() {     int testdev;     int i;     char buf[10];     testdev = open("/dev/test", O_RDWR);    if ( testdev == -1 )     {         printf("Cann't open file 
");         exit(0);     }    read(testdev, buf, 10);     for (i = 0; i < 10;i++)         printf("%d
", buf[i]);     close(testdev); }

The above is just a simple demonstration. A truly practical driver program is much more complex and needs to handle issues such as interrupts, DMA, I/O ports, etc. These are the real challenges. The above provides a framework and principle for writing a simple character device driver; more complex writing requires serious study of the Linux kernel’s operating mechanisms and the specific mechanisms of device operation, etc. I hope everyone thoroughly masters the methods of writing Linux device driver programs.

Analysis of Embedded Driver Structure

In fact, for the structures introduced above, the roles of the elements can be inferred from their names, so there is no need for further elaboration. Writing a driver module essentially involves filling the aforementioned structures, writing corresponding functions based on the device’s functionalities and purposes, and linking them to the structure’s pointers. Finally, write an entry and an exit (which are the init and exit in module programming) is all that is needed. Generally, the entry program is about registering platform_device and platform_driver (of course, this applies specifically to drivers written in platform mode).

08

Recommended Embedded Books

Microcomputer Principles, Digital Circuits, university textbooks.

2. Books on Linux:

, the one written by foreigners

When doing drivers, you will definitely need to use kernel-related materials or need to cooperate with certain modules in the kernel, so you must understand how certain parts of the kernel are implemented. Ultimately, you should have a good grasp of the overall framework of the Linux kernel.

These are all improvements, things you need to summarize in your repeated development. If you do not summarize, you will always start from scratch (or you will never understand why others’ code is written that way when you modify it and it works, and that’s it), and you will never improve. In the end, you will feel that you are nothing and understand nothing.

One more point to clarify: many people are engaged in Linux development but do not use Linux systems as their working platform. In such cases, it is challenging to understand the implementation mechanisms of the Linux kernel and why certain methods are used for implementation.

If you have never used a Linux system, it is impossible to implement a project that conforms to Linux’s operational mechanisms. Even if your project succeeds, it will definitely not be optimal or adhere to Linux’s usage habits (including kernel extensions and application implementations).

Therefore, I want to say that you must regularly summarize what you have done during this period, what you have gained from it, and what you should look at to do similar work better in the future; secondly, you must at least use Linux as your regular working platform in your development environment and not rely on virtual machines or servers. Only by fully understanding how to use Linux can you develop projects that conform to its rules.

Copyright statement: This article comes from the internet, free to convey knowledge, and the copyright belongs to the original author. If there are copyright issues, please contact me for deletion.