[PATCH] This patch adds support for a STM32H7 variation

[Joel Sherrill]

On Fri, Jan 8, 2021 at 6:58 AM Robin Müller <robin.mueller.m at gmail.com>
wrote:

> Hi Sebastian,
>
> That would also be a way. The question is whether all other board
> variation should be included as well.
> There are 12 boards listed in the STM32CubeH7 repository example
> applications and I have not checked which pin and HSE values
> these boards use or if there are any other important differences.. I would
> guess that it will not be necessary to add 12 BSPs for each
> board variation because some board settings will be identical, but maybe
> it would make sense to determine the board differences and look where
> it makes sense to add new BSPs..
>

Are they really 12 BSPs or just build variants of this one BSP family?

If just variants, I have come full circle on how I feel about having lots
of BSP variants. I have seen multiple cases over the past few months where
a new user only realized their board was supported because it shows up as a
variant or it was explicitly mentioned in the user facing documentation by
model. Either we explicitly have a variant with the model name or the list
of models is in the guide with explicit instructions on how to build for
them. We have the precedence on the Leon3 that we added variants to match
specific hardware because it simplified the presentation to users. Little
practical difference in the code but it makes a better user presentation.

I know adding variants adds time to the full build sweep but I no longer
care. It is just more time in the background on fast servers. None of us
are killing time waiting for all the BSPs to do a test build.

The important thing is that search engines find the board someone is
searching for and find that RTEMS supports it. This is the only
marketing/advertising we have as a project. I think we have to be conscious
that Google indexes our manuals and that if we support something, putting
it in the documentation both helps users and helps market RTEMS.




> In any case, I don't really know how to add BSPs (yet), my patch was just
> the quickest way I could think of to make the Nucleo board work
> correctly (at least console and clock, what I've tested so far) out of the
> box with the correct config.ini settings.
>

I'm thrilled you got it to work. I'd be in favor of BSP variants so people
do not have to edit the config.ini for these variations. It is obscure
knowledge of what to change and easier if it is captured as a variant.

--joel

>
> Kind Regards
> Robin
>
>
> On Fri, 8 Jan 2021 at 06:35, Sebastian Huber <
> sebastian.huber at embedded-brains.de> wrote:
>
>> Hello Robin,
>>
>> thanks for the updated patch. I am not sure if we should address the
>> problem with a STM32H743ZI_NUCLEO option. An alternative would be to add
>> a new BSP variant, e.g. stm32h743zi_nucleo, and two new options
>> STM32H7_HSE_FREQUENCY and STM32H7_USART3_USE_GPIOD_PIN_8_PIN_9 with a
>> default value determined by the BSP variant.
>>
>> --
>> embedded brains GmbH
>> Herr Sebastian HUBER
>> Dornierstr. 4
>> 82178 Puchheim
>> Germany
>> email: sebastian.huber at 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 at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210108/29138e0d/attachment.html>