On 30/01/2022 20:41, Karel Gardas wrote:
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?
I guess there will be no perfect solution. It should be possible to pick up a BSP variant for an evaluation board and run the tests without having to touch BSP option values. It would be nice if the BSP can be configured to run on custom boards without having to change the BSP source code. This means that things should be configurable through BSP options and through application defined configuration data structures.
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...
The patch looks good. Please just split it into a couple of smaller pieces. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
