Article Word Count: 6000 Content Index: ⭐⭐⭐⭐⭐
What to Learn in Embedded Driver Development
✍Embedded Systems Generally Include the Following Four Directions:
Embedded Hardware Development:Familiar with circuit knowledge, very familiar with various common components, mastering development capabilities in analog and digital circuit design. Proficient in embedded hardware knowledge, familiar with hardware development models and design patterns, familiar with ARM 32-bit processor embedded hardware platform development, and possessing product development experience.
Skilled in common hardware design tools: Protel/PADS (PowerPCB)/Cadence/OrCad. Generally requires 4-8 layers of high-speed PCB design experience.
Embedded Driver Development:Proficient in Linux operating systems, system architecture, computer organization principles, and data structure-related knowledge. Familiar with embedded ARM development, at least mastering Linux character driver program development.
Capable of porting development for microcontrollers and ARM embedded processors, understanding hardware schematics, able to independently complete related hardware driver debugging, possessing solid hardware knowledge, and able to write software drivers according to chip manuals.
Embedded System Development:Master Linux system configuration, proficient in processor architecture, programming environment, instruction set, addressing methods, debugging, assembly, and mixed programming; master Linux file system creation, familiar with various file system formats (YAFFS2, JAFFS2, RAMDISK, etc.);
Familiar with the embedded Linux boot process, familiar with modifying Linux configuration files; master the entire process of kernel reduction, kernel porting, cross-compilation, kernel debugging, Bootloader writing, root file system creation, and integration deployment of Linux systems; familiar with setting up the Linux software development environment (cross-compilation of library files and environment configuration, etc.);
Embedded Software Development:Proficient in the concepts and installation methods of the Linux operating system, basic commands, management configuration, and editors, including VI editor, GCC compiler, GDB debugger, and project management tools; proficient in advanced programming knowledge of C language, including functions and program structure, pointers, arrays, commonly used algorithms, and library function usage, as well as the basic content of data structures, including linked lists, queues, etc.; mastering the basic ideas of object-oriented programming and the basics of C++ language;
Proficient in program design under embedded Linux, proficient in the embedded Linux development environment, including system programming, file I/O, multi-process and multi-threading, network programming, GUI programming, databases; familiar with programming common graphics libraries such as QT, GTK, miniGUI, fltk, nano-x, etc.
The daily activities of the company depend on its scale; larger companies generally only let you be responsible for one module, so you need to be proficient in that area. If the company is relatively small, you might need to do a bit of everything. You should also understand some hardware aspects.
✍The Biggest Difference Between Embedded and Pure Software is:
Pure software focuses on learning a programming language, such as C, C++, Java, or even Python; in essence, a language is just a tool, similar to learning English, French, or Japanese.
However, embedded learning involves both software and hardware; simply put, it is about creating systems and products, emphasizing not just the specific language tools but more on how to decompose a product into specific actionable software and hardware, as well as smaller units.
Many people ask whether to choose driver development or application development for future employment. The only advice is to choose based on interest, and driver and application development are not strictly separated.
When we talk about drivers, we are not limited to hardware operations; there are also concepts like operating system principles, process sleep/wake scheduling, etc. To write a good application and effectively solve problems encountered in applications, everyone should understand this knowledge.
The development path for applications, in my opinion, is to become proficient in the business. For example, in the communication industry, IPTV industry, and mobile phone industry, one should have a deep understanding of industry demands.
Driver development cannot simply be termed as “doing drivers”; it can be referred to as “building underlying systems”. If done well, this can apply across all industries. For example, if a person has worked for several years on mobile phones, IPTV, and conference TVs, these products are indistinguishable to him because he only works on the underlying systems.
When applications encounter issues that cannot be resolved, he can provide suggestions from the kernel perspective and offer tools. The development direction for the underlying systems should be to become a technical expert.
In fact, whether to focus on the underlying systems or applications does not have a clear boundary. Having experience in the underlying systems and then moving to applications will feel more solid. With business experience, understanding the underlying systems will quickly allow one to form a team.
What Does Embedded Linux Include at the Bottom Level?
✍Embedded Linux consists of four main components: bootloader, kernel, drivers, and root file system.
It is a somewhat complex bare-metal program. However, understanding and writing this bare-metal program is not easy. The convenient tools available on Windows have weakened our programming capabilities. Many people start with embedded systems using ADS, KEIL. Can you answer these questions?
Q: When powered on, where does the CPU fetch instructions to execute?
A: Generally from Flash memory.
Q: However, Flash memory is generally read-only and cannot be directly written to. If global variables are used, where are these global variables?
A: Global variables should be in memory.
Q: Who puts the global variables into memory?
A: Friends who have used ADS or KEIL for a long time, can you answer this? This requires “relocation”. In ADS or KEIL, the relocation code is written by the company that created these tools for you. Have you ever read it?
Q: With such a large memory, how do I know which address to read the “content originally in Flash” into memory?
A: This address is determined by the “linker script”; in ADS, there is a scatter file, and KEIL has a similar file. But have you ever studied it?
Q: You say relocation is copying the program from Flash to memory, can this program read from Flash?
A: Yes, it needs to be able to operate Flash. Of course, there are more than just these, such as setting clocks to make the system run faster, etc.
Let’s stop here for self-questioning; for this bare-metal program called bootloader, there are actually three key points:
Operations on hardware require looking at schematics and chip manuals. This requires certain hardware knowledge; you are not required to design hardware, but at least be able to read it;
You are not required to understand analog circuits, but you should be able to understand digital circuits.
This ability can be learned in school; two books, Microcomputer Principles and Digital Circuits, are sufficient. If you want to learn quickly, you might as well skip this part; if you don’t understand, just GOOGLE or post on forums. Additionally, you definitely need to read the chip manual; don’t look for Chinese versions, just read the English ones. It is very painful at first, but later you will find that once you are familiar with those grammar and vocabulary, reading any chip manual becomes very easy.
Understanding of ARM Architecture Processors
Understanding of ARM architecture processors can be found in Du Chunlei’s , which covers assembly instructions, exception modes, MMU, etc. Only these three areas need to be understood.
Basic Concepts of Programs:Relocation, Stack, Code Segment, Data Segment, BSS Segment, etc.
The basic concepts of programs; ideally, you should read about compiler principles. Unfortunately, such books are absolutely cryptic. Unless you are a super genius, it is better not to read them.
For bootloader, you can first read , then write programs to experiment with various hardware, such as GPIO, clocks, SDRAM, UART, NAND. Once you understand them all, putting them together will make it easy to understand u-boot.
To summarize, understanding hardware schematics and reading chip manuals require you to find the information yourself.
For those who want to learn quickly, skip kernel learning and directly learn how to write drivers. To become an expert, you must deeply understand the kernel. Note that it is about understanding the scheduling mechanisms, memory management mechanisms, file management mechanisms, etc.
Drivers consist of two parts: operations on the hardware itself and the framework of the driver program. Again, hardware knowledge is crucial; you need to understand schematics and read chip manuals, and practice a lot.
Operations on Hardware Itself
Regarding driver frameworks, some books introduce them. LDD3, the , written by foreigners, introduces many concepts worth reading. However, its role is limited to introducing concepts. Before starting, you can use it to familiarize yourself with these concepts.
Framework of Driver Programs
Try to write a driver for all the hardware involved on your development board. If you encounter problems, start by “painfully thinking”; during this thought process, you will connect many unrelated pieces of knowledge and ultimately achieve understanding.
Have you ever thought about these two questions:
Q: For products made with Linux, some are used for monitoring, some for mobile phones, and some for tablets. After the kernel starts and mounts the root file system, which application should be started?
A: The kernel does not know and does not care which user program should be started. It only starts the init application, corresponding to /sbin/init.
Clearly, this application needs to read the configuration file and start the user program (monitoring, manual interface, tablet interface, etc. This question reminds us that the contents of the file system have some conventions, such as needing /sbin/init and having configuration files.
Q: Have you ever thought about who implements the printf function used in your hello, world program?
A: This function is not implemented by you; it is implemented by a library function. When it runs, it needs to find the library.
This question reminds us that the file system must also contain libraries. A simple self-questioning ends here; to gain deeper insights, you can look at busybox’s init.c to understand what the init process does.
Five Methods for Driver Program Design
Design patterns are solutions to problems that recur in software. Developers can choose to waste valuable time and budget reinventing a solution from scratch or select the most suitable solution from their toolbox. When microprocessors first appeared, low-level drivers were already mature, so why not leverage existing mature solutions?
Driver program design patterns can be broadly categorized into the following four types: Bit bang, polling, interrupt-driven, and direct memory access (DMA).
Bit bang mode: When a microcontroller lacks peripherals to execute functions, or when all peripherals are already in use and a new request arises, developers should choose the Bit bang design pattern.
The Bit bang mode solution is efficient but often requires significant software overhead to ensure its 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 schedule. 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 manually check.
DMA (Direct Memory Access) mode allows other peripherals to handle data transfer needs without driver intervention.
Understanding Real-Time Behavior
Whether a real-time system can meet real-time requirements depends on its drivers. Poorly written drivers are inefficient and may cause unaware developers to abandon system performance.
Designers need to consider two characteristics of drivers: blocking and non-blocking. A blocking driver prevents any other software from executing until its work is completed. For example, a USART driver may load a character into the transmission buffer and wait until the transmission end flag is received before proceeding to the next operation.
On the other hand, non-blocking drivers generally use interrupts to achieve their functionality. The use of interrupts can prevent drivers from intercepting other software’s execution while waiting for an event to occur.
USART driver programs 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 that allows 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 and worst-case execution time of drivers. A complete system may face greater 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 hardware abstraction layers.
The hardware abstraction layer (HAL) provides developers with a way to create a standard interface to control the peripherals of microcontrollers. Abstraction hides implementation details and instead provides visual functions, such as Usart_Init and Usart_Transmit. This approach allows any USART, SPI, PWM, or other peripherals to have common characteristics supported by all microcontrollers.
Using HAL hides underlying, device-specific details, 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.
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 around 500 pages.
Nowadays, a 32-bit microcontroller typically includes data manuals for parts, entire microcontroller series, hundreds of documents for each peripheral, and all errata sheets. Developers need to understand thousands of pages of documents to fully grasp this content.
Unfortunately, all of these data manuals are necessary for a driver program to be implemented reasonably. Developers must collect and organize information contained in each manual from the beginning.
Usually, each of them needs to be accessed to get the peripherals to start and run. Key information is dispersed (or hidden) in each type of data manual.
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 series of microcontrollers.
However, the reality is that there are significant differences when running the PWM driver. The driver only works on the original microcontroller and is ineffective on the new series of microcontrollers.
After repeatedly reviewing the data manuals, I discovered in an unrelated footnote that the PWM peripheral is in a fault state when powered on and requires clearing a flag hidden in the register. At the start of driver implementation, confirm potential failures of peripherals and check other seemingly unrelated register errors.
Advice from Experts on Embedded Driver Development
For future development, in addition to considering breadth, it is more important to pay attention to the depth of knowledge.
For example, if you have worked on network drivers, are you only staying at the surface level of writing drivers, or have you deeply understood the network structure of the Linux kernel and the TCP/IP protocol?
In Linux development, you often have to utilize existing resources; there is no need to reinvent everything. The key is whether you understand the underlying aspects behind the original author’s work after turning it into your driver.
You should not just make it work. When writing drivers, consider performance issues and provide testing methods (of course, you can use many existing tools, such as netperf for testing network performance).
When you have written Flash drivers, you may know how important Flash performance can be at times.
In the self-cultivation of C programs, have you considered some aspects of software engineering, such as the maintainability and scalability of programs? For example, for an LCD driver, does it only require a few modifications to switch from Sharp to NEC?
For different brands of Flash, how can you make the Flash driver more flexible?
The drivers you are currently working on are not considered very core components. If you want better development, consider advancing towards audio, video, and networking; you should pay attention to what talents the industry needs. Each of the above requires a strong foundation; for instance, video requires understanding MPEG4, H264, etc., which takes about 1 to 2 years to enter the industry. Therefore, I suggest not to just bury your head in work but to pay appropriate attention to current applications.
Disclaimer: The content of this article comes from the internet, and the copyright belongs to the original author. If there are copyright issues, please contact us for removal.
《Tencent Executive: My Programming Skills Took Off During My Four Years at University and Successfully Landed a Job at Tencent?》
《Will Traditional Embedded C Programmers Disappear Under New Programming Development Models?》
《What? Still Not Clear on the Differences Between Microcontroller Development and Linux Development?》
Every day, the hardworking little creator,
[Share, Like, Follow]Can I have a duck
