Discussion: Improving STM32F4 BSP (GSoC) – Design Discussion

[Kirubakaran]

Hi @gedare,

I came across the discussion here about managing STM32 HAL outside the RTEMS repository:

Creating RSB recipe for HAL management

Hello @kiwichris, I’m working on improving the STM32F4 BSP and the current discussed approach to integrate HAL is to move STM32CubeHAL management out of rtems.git and into the RSB. The idea would be to treat STM32Cube HAL as an external dependency managed by the RSB, rather than vendoring snapshots directly in the RTEMS source tree. I’d like to better understand how such a HAL package should be structured in the RSB. I’ve a few questions: Whats the recommended way to track HAL versions Are …

To better understand how HAL could fit into the BSP, I tried compiling a minimal set of STM32F4 HAL sources (GPIO/RCC) outside of RTEMS using the CMSIS headers. I was able to build them into a static library (libstm32f4hal.a). From what I observed, the HAL itself does not depend on RTEMS — it only requires the toolchain, CMSIS headers, and a configuration file (stm32f4xx_hal_conf.h).

While testing this, I also noticed that HAL expects a few system hooks such as HAL_GetTick() and HAL_Delay(), which would likely need to be provided by the BSP or mapped to RTEMS services.

This made me wonder whether building HAL as a separate library (possibly via the RSB) and linking it from the BSP drivers would be the intended direction.

Before going further, I wanted to ask if this aligns with the architecture you had in mind when discussing HAL management outside the RTEMS repository, or if there are additional constraints I should consider.