Discussion: Improving STM32F4 BSP (GSoC) – Design Discussion

[Kirubakaran]

Hi @gedare

I’m Kirubakaran, and I’m currently exploring the STM32F4 BSP as part of preparing my GSoC proposal (Improving the STM32F4 with GPIO, SPI, DMA).While going through the STM32F4 BSP and comparing it with STM32H7, I noticed that the STM HAL code is currently placed inside contrib/ in the RTEMS repository. This works for a fixed version, but I’m trying to understand if this is the best long-term approach, especially if we want to support more STM32 BSPs or different HAL versions.

I was thinking about a possible approach where:

• We keep a default, known-working HAL version inside RTEMS.

• But optionally allow users to override it at configure time, something like:

   ../waf configure --with-stm32-hal=/path/to/hal
  

• The BSP build logic would then use the provided HAL instead of the default one.

• If no override is provided, it could either use the default HAL or fall back to the existing LL/register-level implementation.

The main idea is to make HAL integration more modular and reusable across STM32F4, STM32H7, and potentially other STM32 BSPs.

Does this direction make sense???
Are there any build system or release constraints I should be aware of before going further with this idea??

[gedare]

This project idea has a topic thread already at DIscussing HAL version override for stm32f4 please feel free to join the conversation there.

[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.

[gedare]

I would prefer to consolidate the discussion in a single topic, feel free to reply on the other topic you found.