Currently, Linux software engineers can be roughly divided into two levels:
01
Linux Application Software Engineer:
Mainly writes application software using C library functions and Linux APIs;
Those engaged in this type of development work mainly need to learn: API functions and system calls that comply with the Linux POSIX standard, Linux multitasking programming techniques: multiprocessing, multithreading, inter-process communication, synchronization, and mutual exclusion among multiple tasks, learning embedded databases, and UI programming: QT, miniGUI, etc.
02
Linux Firmware Engineer:
Mainly involved in Bootloader, porting Linux, and designing Linux device drivers.
Generally speaking, the requirements for firmware engineers are higher than those for application software engineers, and among them, Linux device driver programming is one of the more complex parts of Linux programming. The reasons include the following aspects:
1) Device drivers belong to the Linux kernel part, and writing Linux device drivers requires a certain foundation in the Linux operating system kernel; it is necessary to understand some of the Linux kernel’s working mechanisms and system composition.
2) Writing Linux device drivers requires a considerable understanding of hardware principles. In most cases, we write drivers for a specific embedded hardware platform, for example: for a specific host platform, it could be Samsung’s 2410, 2440, or Atmel’s, or Freescale’s, etc.
3) Linux device drivers widely involve synchronization and mutual exclusion control of concurrent processes, which can easily lead to bugs; because Linux itself is a multitasking working environment, it is inevitable that concurrent operations on the same device occur at the same time.
4) Since it is part of the kernel, debugging Linux device drivers is also quite complex. Linux device drivers do not have a good IDE environment for step-by-step debugging, variable viewing, and other debugging aids; Linux drivers work at the same level as the Linux kernel, and once a problem occurs, it can easily cause a complete kernel crash.
In any computer system, whether it is a large server, a PC, or a small device like a mobile phone, MP3/MP4 player, the presence of drivers is indispensable. Without software for hardware, it is a castle in the air; without hardware for software, it is just a pile of scrap metal. Hardware is the underlying foundation, the platform on which all software runs, and the code ultimately implements the logical combination on the hardware.
However, there is a contradiction between hardware and software: to quickly and efficiently complete software function design, application engineers do not want to and are unwilling to care about hardware, while hardware engineers also find it difficult to deal with some applications in software development. For example, when a software engineer calls printf, they do not need to care about how the information is processed, what paths it takes to be displayed in the right place; after a hardware engineer writes a 4*4 keyboard driver, they do not need to care about what processing and operations the application performs after obtaining the key value.
In other words, software engineers need to see a pure software world without hardware, and hardware must be transparently provided to them. Who will implement this task? The answer is the driver program, which literally means: “driving hardware devices to act.” The driver program directly interacts with the hardware, according to the specific form of the hardware device, driving the device’s registers, completing polling, interrupt handling, and DMA communication, ultimately allowing communication devices to send and receive data, display devices to show text and images, and audio devices to store and play sound.
It can be seen that device driver programs act as a hub between hardware and software; therefore, the form of the driver program may be some standard, pre-agreed API functions. The driver engineer only needs to complete the corresponding function filling, and the application engineer only needs to call the corresponding interface to complete the corresponding function. Whether or not there is an operating system, the driver program has its value; however, in a bare-metal situation, the working environment is relatively simple, the tasks completed are relatively single, and the functions completed by the driver program are also relatively simple, while the interface only needs to conform to a unified standard within a small range. However, in the presence of an operating system, this issue is magnified: hardware comes from different companies, varies widely, and every day a large number of new chips are produced and a large number of circuit boards are designed. If there is no good unified standard to regulate this program, the operating system will be designed very redundantly, and efficiency will be very low.
Therefore, every operating system will establish a set of standard architecture to manage these driver programs: Linux, as a model of embedded operating systems, has a highly normative and aggregative driver architecture that not only categorizes and comprehensively manages different hardware devices but also performs unified abstraction for the commonalities of different hardware, minimizing their hardware relevance, greatly simplifying the writing of driver programs, and forming a distinctive driver organizational structure.
The following figure reflects the relationship between application programs, the Linux kernel, drivers, and hardware.
The Linux kernel is divided into five major parts: multitasking management, memory management, file system management, device management, and network management.
Each part has a role in providing API interfaces for application development engineers to use.
Through driver programs, it shields different hardware compositions and completes specific hardware operations.
1.2017 Programming Language Rankings: Python Tops the List!
2.Several Methods for Microcontroller Software Anti-Interference, you can’t say you don’t know anymore~
3.Linux System Sleep and Device Interrupt Handling
4.How to Choose the First Programming Language?
5.Is it too late for me to start learning embedded development in my 30s?
6.Very Useful! Forrester Releases Top Ten Hot AI Technologies
Disclaimer: This article is a network reprint, and the copyright belongs to the original author. If there are any copyright issues, please contact us, and we will confirm the copyright based on the copyright certificate you provide and pay the remuneration or delete the content.