HAL and LL drivers’ overview

The HAL (Hardware Abstraction Layer) drivers consist of a set of driver modules, each associated to a standalone peripheral. In some cases, a module is dedicated to a peripheral’s functional mode. For example, several modules exist for the USART peripheral: the UART driver module, the USART driver module, and the SMARTCARD driver module.

HAL Main Features

  • Cross-Family Portable APIs: These cover common peripheral features as well as family or device-specific peripheral features.

  • API Programming Models: Most HAL drivers implement three API programming models: polling, interrupt, and DMA.

  • RTOS Compliant APIs: Fully reentrant APIs. with appropriate check and return “BUSY” at function entry in case of the requested operation is not possible. Systematic usage of timeouts in polling mode.

  • Peripheral Multi-Instance Support: This allows concurrent API calls for multiple instances of a given peripheral (e.g., USART1, USART2).

  • User-Callback Functions: Most HAL drivers implement rely on user-callback functions for asynchronous programming models, sush as Peripheral interrupt events and Error events.

  • Peripheral System-Level Initialization/De-Initialization: This includes clock, GPIOs, interrupt, and DMA, which are done at the application level using the appropriate HAL system driver (e.g., HAL RCC, HAL GPIO, HAL Cortex, HAL DMA). These initialization sequences are performed before configuring the given HAL driver. Note that CubeMX2 offers code generation capabilities for these initialization sequences, and peripheral clock enabling can be performed intrinsically during initialization if the feature is enabled in the configuration file.

  • Bus Services: AcquireBus and ReleaseBus services (for bus-type drivers like I2C, SPI, etc.) ensure safe hardware access to prevent concurrent access to driver processes and handle objects.

  • Timeouts for Blocking Processes: Timeouts can be simple counters or time-based.

For a given HAL peripheral driver, all APIs are implemented within a single stm32tnxx_hal_ppp.c file. The corresponding stm32tnxx_hal_ppp.h header file provides an interface to the application layer with the available APIs. The HAL APIs are classified into three categories:

  • Common Functions: These are generic APIs common to all STM32 Cube Firmware packages. They provide a user-friendly and functional aspect-oriented interface to the application, similar to generic functions available in most public solutions with standardized APIs. The common APIs allow upper firmware components to call these services with light configuration affecting only the peripheral instances, while the low-level interfaces’ implementation in high-level firmware components remains consistent.

  • STM32 Series-Specific Functions: These APIs apply only to all device part numbers within a given STM32 series.

  • Device-Specific Functions: These APIs are defined by specific features relative to a given part number and are delimited by different conditional defines (peripheral version, feature support, peripheral availability, etc.).

Unlike Low-Layer drivers (see HAL Low-Layer section), HAL drivers are functionality-oriented rather than IP/HW oriented.