It allows linking the component driver to a specific board and provides a set of user-friendly APIs. The API
naming rule is BSP_FUNCT_Action(): ex. BSP_LED_Init(),BSP_LED_On()
The BSP is based on a modular architecture allowing an easy porting on any hardware by just implementing the
low level routines.
2.1.2 Hardware Abstraction Layer (HAL) and low-layer (LL)
The HAL layer provides the low level drivers and the hardware interfacing methods to interact with the upper
layers (application, libraries and stacks). It provides generic, multi instance and function-oriented APIs which
simplify the user application implementation by providing ready-to-use processes. As example, for the
communication peripherals (I2S, UART…), it includes APIs allowing to initialize and configure the peripheral,
manage data transfer based on polling, interrupt or DMA process, and handle communication errors that may
raise during communication. The HAL Drivers APIs are split in two categories:
• Generic APIs which provide common and generic functions to all the STM32 Series
• Extension APIs which provide specific and customized functions for a specific family or a specific part
number
• The low-layer APIs provide low-level APIs at register level, with better optimization but less portability. They
require a deep knowledge of MCU and peripheral specifications. The LL drivers are designed to offer a fast
light-weight expert-oriented layer which is closer to the hardware than the HAL. Contrary to the HAL, LL
APIs are not provided for peripherals where optimized access is not a key feature, or for those requiring
heavy software configuration and/or complex upper-level stack. The LL drivers feature:
– A set of functions to initialize peripheral main features according to the parameters specified in data
structures
– A set of functions used to fill initialization data structures with the reset values corresponding to each
field
– Function for peripheral de-initialization (peripheral registers restored to their default values)
– A set of inline functions for direct and atomic register access
– Full independence from HAL and capability to be used in standalone mode (without HAL drivers) – Full
coverage of the supported peripheral features.
• Dual Core implementation:
– The same HAL/LL drivers support both the single and dual core STM32H7 lines
◦ In the STM32H7 dual core devices all peripherals can be accessed in the same way by the two
cores (Cortex
®
-M7 and Cortex
®
-M4). It means there is no peripherals split or default allocation
between Cortex
®
-M7 and Cortex
®
-M4. For this reason the same peripheral HAL and LL drivers
are shared between the two cores.
◦ Furthermore, some peripherals ( mainly: RCC, GPIO, FLASH, PWR, HSEM..) have additional
dual core specific features:
• “DUAL_CORE” define is used to delimit code (defines , functions, macros.. ) available only
in dual core line.
• “CORE_CM4” define is used to delimit code where we a specific configuration/code portion
for Cortex
®
-M4 core
• “CORE_CM7” define is used to delimit code where we a specific configuration/code portion
for Cortex
®
-M7 core on a dual core line.
2.1.3 Basic peripheral usage examples
This layer contains the examples of the basic operation of the STM32H7 peripherals using either the HAL APIs as
well as the BSP resources.
2.2 Level 1
This level is divided into two sub-layers:
2.2.1 Middleware components
Middleware components are a set of libraries covering USB Host and Device Libraries, STemWin, TouchGFX,
LibJPEG, FreeRTOS, OpenAMP, FatFS, LwIP, mbedTLS, and PDM2PCM audio library. Horizontal interactions
between the components of this layer are performed directly by calling the feature APIs while the vertical
UM2204
Level 1
UM2204 - Rev 5
page 5/25