Every embedded application software will at some point access the lowest level firmware and perform some hardware control. The design and implementation of drivers are crucial to ensure that a system can meet its real-time requirements. Here are 5 tips that every developer should consider when designing drivers. Let’s explore the relevant content together.
Design patterns are solutions to problems that frequently occur in software. Developers can either waste valuable time and budget reinventing a solution from scratch or choose the most suitable solution from their toolbox. When microprocessors first emerged, low-level drivers were already quite mature, so why not leverage existing proven solutions?
Driver design patterns generally fall into the following four categories: Bit bang, polling, interrupt-driven, and Direct Memory Access (DMA).
Bit bang mode: When a microcontroller has no peripherals to perform a function, or when all peripherals are already in use and a new request arises, the developer should opt for the Bit bang design pattern. The Bit bang solution is quite efficient but typically requires significant software overhead to ensure its implementation capabilities. Bit bang mode allows developers to manually implement 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 check manually.
DMA (Direct Memory Access) mode allows other peripherals to handle data transfer needs without the intervention of the driver.
Whether a real-time system can meet its 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 it completes its work. For example, a USART driver may load a character into the transmission buffer and then wait until it receives a transmission end flag before proceeding to the next operation.
On the other hand, non-blocking drivers typically use interrupts to achieve their functionality. The use of interrupts can prevent the driver from intercepting the execution of other software while waiting for an event to occur. A USART driver can load a character into the transmission buffer and then wait for the main program to issue the next command. The setting of the transmission end flag causes an interrupt to finish, allowing 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 the driver. 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 development, reuse, portability, and maintainability are key requirements of 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 peripherals of a microcontroller. 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 possess the common characteristics supported by all microcontrollers. By using HAL to hide the underlying, device-specific details, application developers can 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 sheet composed of about 500 pages. Nowadays, a 32-bit microcontroller typically includes data sheets for parts, documentation for the entire microcontroller series, hundreds of documents for each peripheral, and all errata. Developers need to understand thousands of pages of documents to fully grasp this content.
Unfortunately, all these data sheets are essential for a driver to be implemented reasonably. Developers must collect and sort through the information contained in each data sheet from the outset. Typically, each of them needs to be accessed to get the peripherals started and running. Key information is scattered (or hidden) within each type of data sheet.
Recently, I had the opportunity to port a series of microcontroller drivers to other microprocessors. Manufacturers and data sheets indicated that PWM peripherals were the same between these two microcontroller series. However, the reality was that there was a significant difference when running the PWM driver. The driver only worked on the original microcontroller and was ineffective on the new series.
After repeatedly reviewing the data sheets, I found in a completely unrelated footnote that the PWM peripheral would be in a fault state upon power-up and required a flag hidden in a register to be cleared. At the start of the driver implementation, confirm the potential faults of the peripherals and check other seemingly unrelated register errors.
1. 2017 Programming Language Rankings: Python Tops the List!
2. Several Ways to Improve 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 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 and pay remuneration or delete the content based on the copyright certificate you provide.