The hardware abstraction layer must check the current hardware configuration capabilities and limitations, as well as the possible future scalability, and listen to the system software requirements. Simply put, HAL is the "hardware" of our system, and the function of the "hardware" is the API it provides, that is, all upper-level programs do not need to know the details of the hardware and drivers at all, and can only control the hardware through HAL. According to this logic, we usually implement the HAL process as follows:
- Define the scope of the HAL : Analyze the hardware functions required by the upper system and applications according to the requirements. These requirements are the basic modules that the HAL must include, and then analyze whether there are still hardware that is not used by the current system according to the hardware configuration. Functions, these functions may be implemented in next-generation products, we can design the corresponding HAL module API for them, but it is not necessary to implement them first;
- Define HAL API :
- The system engineer explains the system requirements, including how the system handles hardware events.
- The firmware engineer provides the first version of the HAL API definition file according to the hardware function;
- The system engineer and the firmware engineer review the HAL API one by one.
- Before the HAL API project is approved, a detailed report must be made for all software engineers in the project, suggestions are collected, and necessary corrections must be made.
- The firmware engineer implements all HAL functions and performs unit testing of each module;
- The firmware engineer releases the first version of the HAL library, and the system engineer is responsible for the integration test.
So HAL is just an API standard provided by the driver to upper-layer applications.
1. HAL basic design principles
HAL design files are divided into chapters by drivers, and different drivers are designed and written by engineers with different expertise. Therefore, the first chapter of the design document is the basic design principle of HAL, and the second chapter is the shared data structure and constant definition. The following are the design principles:
- Forward compatibility, the API of the new version of HAL can be increased, but cannot be reduced;
- HAL aims to abstract the hardware and should not be directly related to any system. If the OS has special requirements for the driver (Linux has a standard driver writing method), the system team should package a layer of high level driver on top of the HAL according to the requirements.
- Drive modularity to minimize the coupling between drives.
- Each driver is designed separately, but the structure in the chapter must be consistent, mainly including the following information:
- data structure
- API
- Control flow or state machine
- The hardware events that will be generated, and the event delivery process
- Each driver module should try to pack the following APIs to keep the API style of all driver modules consistent:
- Open(): Perform the initialization of the device (including the initialization of the hardware, obtaining the buffer required by the driver, data structure or configuration settings, etc.)
- Enable(): the drive starts to run
- Disable: The drive is suspended
- Close(): Close the hardware device, return the data structure or configuration of the buffer and reset drive.
- Set_Power_mode(): Set the power mode (full run, idle, sleep mode) of the device. Even if the hardware does not require this voltage management, an empty Set_Power_mode function must be designed to maintain the consistency of all drive interfaces.
- Coordination of driver and power management: The driver only provides a mechanism for power management, and the power management strategy is uniformly controlled by the power manager of the system, that is, each driver module in the HAL must meet the requirements of the power manager, for example, must implement Set_Power_mode( ) Such an API.
- Each driver module of HAL must comply with common naming rules and API style.
- Uniformly define the system configuration of HAL: these configurations must be open to the system, yes, the driver modules or functions that are not needed for this project will not be connected. E.g:
#include <hal.h>
#ifdef HAL_WITH_GPS //HAL_WITH_GPS为HAL配置之一，定义在hal.h中
...
#endif2. The communication mechanism between the driver and the system
There are 3 ways of communication between the system and HAL:
- HAL API: The system can directly call the HAL open API.
- ISR and hardware event: When the hardware generates an interrupt, the corresponding ISR will be executed; when the ISR is processed, the hardware event can be abstracted, packaged into a hardware event, and transmitted to the upper system. The methods of transmission are as follows:
- Global variable flag: When the upper program finds that the value of flag has changed, it means that a hardware event has occurred. However, the timeliness of this method is poor, and attention must be paid to the protection of the critical section;
- Calling system functions in the ISR, such as send_message(), wakeup_task(), etc., is a common practice, but it breaks the specification that HAL must be independent of the upper system.
- A good practice is that HAL does not decide the mechanism for transmitting hardware events. Instead, it provides APIs so that the system can "register" the functions (callback function) used to transmit hardware events. ISR will call these functions at appropriate times. As for the system ISR does not know how to handle hardware events.
- Callback: HAL provides an API for registering the callback function, and clearly indicates when to call this callback function. As long as the system passes in the function pointer, HAL will call these callback functions at the above timing. For example, when the HAL is about to shut down, it will call the callback function registered by the system to give the system a chance to do some processing.
3. Drive interface
Let's take Audio as an example of an important driver in HAL and take a look at the driver's interface. According to the design document style specification, the relationship of all APIs in this module must be described first:
For more knowledge, please click and follow:
Embedded Linux&ARM
CSDN Blog
Brief Book Blog
Know the Column