I’m interested in improving the stm32f4 BSP. I’ve added myself to the tracking list and have successfully run rtems on my nucleo f446ze a couple months back.
I’ve made an MR(#901) that extends the BSP to select linker scripts per variant via option defaults. This should make handling f4 variants easier for users going forward.
I have prior experience working with the stm32 involving timers, CAN bus, SPI, DMA for USART, etc.
I’d appreciate guidance on what the next steps should be. What should I do next in terms of scoping the project? What should I try or learn about?
I would suggest that you identify what areas might be most interesting for you to work on. Identifying the current state of support for the stm32 is an important part of developing your application proposal, along with showing that you have the knowledge and skills to make improvements to that current state.
I’ve spent some time reviewing the current STM32F4 BSP implementation as well as the STM32H7 BSP to better understand how the BSP should be implemented.
From what I see, the STM32F4 BSP currently provides minimal peripheral support and includes a basic GPIO driver implemented at the register level. The stm32h7 bsp integrates STM’s HAL layer and wraps it behind a cleaner interface.
STMicroelectronics provide the HAL and CMSIS files in this repository
Based on this, I’m thinking the first improvement would be HAL integration for GPIO:
Import the required STM32F4 HAL driver files and CMSIS device headers from st’s github repo into contrib/bsps/arm (following issue 5294).
Add a configuration option to enable the HAL.
Add the necessary initialization functions(clk enable, HAL config).
Implement a generic GPIO interface (eg set_pin, get_pin, read_pin) with proper status returns.
After GPIO, SPI would be the next logical implementation. We can follow the h7 bsp and use RM0090 for reference.
I plan to start by integrating minimal HAL backend GPIO support before the coding period to better understand the structure so we can expand incrementally later.
Does this seem like the right track? Should I scope out any other features?
Yes, this seems OK. The situation with HAL imports is still not satisfying to me. I would like it if we had a better long-term solution for managing HALs that would allow users to select whatever version of whatever HAL they want to use and “import” that into their build of RTEMS. That’s captured in the issue #5282. A project that works toward a better resolution of how we manage HAL imports (besides dumping arbitrary versions into rtems.git/contrib) could be quite valuable. The STM32F4 HAL could be a good candidate for working out the details.
Okay so I’ve done some research on how other RTOS’s handle this situation.
I am currently thinking of a modular HAL integration where
HAL is isolated from core RTEMS repo
A known good version is provided in a seperate repository as a mirror/submodule
Users can choose to override using a config option while building RTEMS. Something like --with-stm32f4-hal=/path/to/hal to select whatever HAL they wish to use.
We could also attempt to verify version compatibility during build.
I agree that the STM32F4 BSP could be used as a prototype to validate this mechanism before generalizing to other BSPs.
What do you think of this approach? Do we have any other ideas that we have considered before?
Embedding git submodules within rtems.git is not desirable.
I think offering a way to override the version that is embedded within rtems.git/contrib might be a suitable solution. This topic probably deserves its own topic thread on the forum here.
We can work towards an override for the hal version that the user wants. We can add a config option and also basic checks to ensure the user preferred HAL version is compatible with the bsp.
I agree this likely deserves a dedicated thread to discuss the details of the override mechanism.
From here, would you recommend that I start drafting my proposal or are there additional details that you’d suggest I clarify first?
I would suggest you start a new thread to discuss the problem and solution design you’re thinking about for managing HAL code. I’m not sure how it will make sense to “add a config option” so it will be good to clarify your ideas and get some discussion going in parallel to working on your proposal.
I noticed that @joel and @gedare are listed as potential mentors in the original issue. I wanted to confirm whether that is still the case for this project.
I’ve begun drafting my proposal for STM32F4 improvements and the recently discussed RSB based HAL management.
Once I have a draft ready in the next few days, I’d greatly appreciate feedback if you’re available to review it. I want to make sure the scope of the project is aligned well with what would be most valuable for RTEMS.
Hey @gedare, I’ve added my proposal link to the tracking page. I would really appreciate any feedback if you have the time to review it.
Also I wanted to check if there have been any updates on the mentor front.