8th: Make the Development Board sound: Buzzer

8th: Make the Development Board sound: Buzzer

One, Linux-driven code reuse

There are many ways to reuse Linux-driven code. The standard C program can be used in the way. Put the code you want to reuse in a different file (declared in the header file). If you want to use certain features, include the appropriate header files (this is called static reuse). You can also use another way of dynamic reuse, where a Linux driver can use resources from another Linux driver (functions, variables, macros, and so on). This section describes the code reuse methods in detail.

1. Compiling is a Linux driver with multiple files

There is not much code for Linux drivers, and there is nothing wrong with putting all the code in a file, but for complex Linux drivers it is necessary to use multiple source code files to store different function codes, which facilitates code categorization and management. Of course, if the Linux driver to use the third-party source code, then you have to compile multiple source code files, and eventually become the. ko files or compiled into the Linux kernel (it is estimated that no one will copy the third-party prairie code into a file and then compile).

2.Linux Driver Module dependencies (export symbols)

Code reuse can be divided into two types: static and dynamic. The method described in the previous section is static reuse of code, which is a code-level reuse that compiles the code that needs to be reused and the consumer who uses the code, eventually generating an executable file or library (. Ko,. So, and so on).

In this section you will describe another way of code sharing: module dependencies, also known as export symbols. If you can only use a sentence to explain how to use the export symbols to implement the code, this sentence is "in a driver module using another driver module in the exported symbols (Tsuneaki, variables, functions, etc.)."

Second, forcibly uninstall the Linux drive

If you write a ljnux driver that is logically correct, it can be loaded and unloaded normally, but in some cases, some programs may have an exception condition. The Linux driver may not uninstall properly. In this section you will learn how to place these drivers that cannot be uninstalled.

Scenario 1: Initialization function crashes

Because the initialization function of the Linux driver (through a function specified by the MODULE_INIT macro) crashes, it causes the initialization function to fail to return normally. The performance of this situation is that the current Linux driver module is not used by any other Linux driver module, but the display has been quoted once.

Scenario 2: The Unload function is blocked

When uninstalling the Linux driver using the Rmmod command, the system invokes the Unload function (the function specified by the MODULE_EXIT macro), and the Linux driver is unloaded only if the Unload function successfully returns to the elbow. If the Unload function is blocked (possibly due to a dead loop, concurrency, etc.), the Rmmod command is also blocked. In other words, the code to unload the Linux driver module will never be executed. The performance of this situation is that an execution of the RMMOD command will stop there and never return to the operating prompt of the system.

Three, buzzer (PWM) drive experiment

The PWM drive is similar to the LED driver implementation process and may be simpler. In this chapter it is only to demonstrate how to divide a Linux driver into multiple implementation files before using a relatively simple PWM driver.

Summarize:

Through the study of this chapter, we can master the common code reuse mode of Linux driver. In addition, this chapter introduces a method of forcibly uninstalling Linux drivers. This way, you can eliminate the pain of restarting the machine.

8th: Make the Development Board sound: Buzzer