[PATCH] add STM32H7 BSP variant to support STM32H7B3I-DK board
Karel Gardas
karel at functional.vision
Sun Jan 30 19:41:53 UTC 2022
Hello Sebastian,
I guess you will be in charge of reviewing this patch. Please allow me
to explain motivation behind it plus add some questions.
You know I'd like to update STM32H7 HAL to the latest code provided by
STMicro to be able to use it on my stm32h735g-dk board. Before doing
that I'd like to have some reference working point of the current RTEMS
HEAD. The problem is that so far supported nucleo board is unavailable
anymore and stm32h743-eval(2) board is hard to find and not in the price
range of hobby hacking anymore.
So I purchased stm32h7b3i-dk which should be supported by HEAD HAL and
this BSP variant is kind of what I needed to do in order to get that
working.
Generally speaking I have two questions with regarding to code:
1) I'm not sure about balance between adding parameters into the yaml
files and between simply #ifdefing code for different bsp variants. E.g.
U(S)ART config is clear, this belongs to yaml, power supply too. But
then what about AHB clock divider? What about flash latency? Those are
just one liners so they may go to yaml too (although not that user
related), but then what about all those oscilator and peripherals
configuration bits? I've rather #ifdefed those. So the question is: what
to put into yaml and what to keep in C.
2) system_stm32h7xx.c -- although this file should support several mcus
from h7 family it looks like it is generated just for one particular
board configuration. I've done some experiments, installed STMCubeIDE
and generated few demos for few boards and compared the file:
system_stm32h7xx.c -- it's the same name but different or slightly
different content between demos. In submitted code I #ifdefed bsp
variant code, but I'm not sure if we should not rename the file to
system_stm32h743.c and create a new file for every MCU variant and then
use yaml logic to conditionally include only the file related to
selected variant/mcu variant. What's your opinion on that?
The submitted BSP variant code was tested by compiling all three BSP
variants and by running stm32h7b3i-dk variant on my board. Only
hello/ticker/paranoia/unlimited/malloctest were tested but provided no
visible error/failure. IMHO submitted code may be committed as it is and
question/issue to be solved later when adding/replacing with new HAL and
adding new BSP variant to support h735g-dk board. But you are the man in
charge here so you decide that...
Thanks,
Karel
More information about the devel
mailing list