01
Use design patterns
A design pattern is a solution used to deal with problems that recur in software. Developers can choose to waste precious time and budget to re-invent a solution from scratch, or choose a solution from his solution toolbox that is most suitable for solving the problem. At the beginning of the microprocessor, the underlying driver was already very mature, so why not use the existing mature solutions?
Driver design patterns are 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 internal peripherals to perform functions, or when all internal peripherals have been used, and there is a new request at this time, the developer should choose the Bit bang design mode. The bit bang mode solution is very efficient, but usually requires a lot of software overhead to ensure its ability to implement. Bit bang mode allows developers to manually complete communication protocols or external behaviors.
The polling mode is used to simply monitor events in a polling scheduling mode. Polling mode is suitable for very simple systems, but many modern applications require interrupts.
Interrupts allow developers to handle events when they occur, instead of waiting for the code to manually check.
The DMA (Direct Memory Access) mode allows other peripherals to handle data transfer requirements without driver intervention.
02
Understand real-time behavior
Whether a real-time system can meet real-time requirements depends on its driver. Drives with poor writing capabilities are inefficient and may cause unsuspecting developers to give up system performance. The designer needs to consider two characteristics of the drive: blocking and non-blocking . A blocking driver prevents any other software from performing operations until it has completed its work. For example, a USART driver can load a character into the transmission buffer, and then wait until the end of transmission indicator is received before proceeding to the next step.
On the other hand, non-blocking drives generally use interrupts to achieve their functions. The use of interrupts can prevent the driver from intercepting the execution of other software while waiting for an event to occur. The USART driver can load a character into the transmission buffer and wait for the main program to issue the next command. The setting of the transmission end flag will cause the interrupt to end, allowing the driver to proceed to the next step.
Regardless of the type, in order to maintain real-time performance and prevent failures in the system, developers must understand the average execution time of the driver and the worst-case execution time. A complete system may cause greater security problems because of a potential risk.
03
Reuse design
Why reinvent the wheel when time and budget are tight? In driver development, reuse, portability, and maintainability are key requirements for drive design. Many of the features can be explained through the design and use of the hardware abstraction layer.
The hardware abstraction layer (HAL) provides a way for developers to create a standard interface to control the peripherals of the microcontroller. The abstract hides the implementation details, and instead provides visualization functions such as Usart_Init and Usart_Transmit. This method is to allow any USART, SPI, PWM or other peripherals to have common features that all microcontrollers support. Use HAL to hide the details of the underlying and specific devices, allowing application developers to focus on the needs of the application instead of focusing on how the underlying hardware works. At the same time, HAL provides a reusable container.
04
Reference data sheet
Microcontrollers have become more and more complex in the past few years. In the past, a complete understanding of a microcontroller required a single data sheet consisting of approximately 500 pages. Nowadays, a 32-bit microcontroller usually contains a data sheet consisting of a partial data sheet, a data sheet of the entire microcontroller series, hundreds of data on each peripheral, and all errata sheets. Developers need to understand thousands of pages of documents if they want to fully grasp the content of this part.
Unfortunately, all of these data sheets are what a driver can really reasonably achieve. Developers must collect and sort the information contained in each data sheet from the beginning. Usually each of them needs to be accessed in order for the peripheral to start and run. The key information is scattered (or hidden) in each type of data book.
05
Beware of peripheral failure
Recently, I just had the opportunity to port a series of microcontroller drivers to other microprocessors. Both the manufacturer and the data sheet indicate that the PWM peripherals are the same between the two series of microcontrollers. However, the actual situation is that there is a big difference between the two when running the PWM driver. The driver can only work on the original microcontroller, but it is invalid on the new series of microcontrollers.
After reading the data sheet repeatedly, I found in a completely unrelated footnote in the data sheet that the PWM peripheral will be in a fault state when it is powered on, and a flag bit hidden in the register needs to be cleared. At the beginning of the driver implementation, confirm the possible failures of the peripheral and check other seemingly unrelated register errors.
1. The domestically-made alternatives are intangible? Come back to the Zhaoyi Innovation Live Class!
2. Can the open source RISC-V be the antidote to China's "core shortage"?
3. Raspberry Pi Pico: MCU for only $4
4. There are many reasons why MCU supports AI function~
5. In 2020, 20 software engineering principles I learned~
6. The application of state machine ideas in embedded development~
Disclaimer: This article is reproduced online, and the copyright belongs to the original author. If you are involved in copyright issues, please contact us, we will confirm the copyright based on the copyright certification materials you provide and pay the author's remuneration or delete the content.