<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 8, 2021 at 6:58 AM Robin Müller <<a href="mailto:robin.mueller.m@gmail.com">robin.mueller.m@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Sebastian,</div><div><br></div><div>That would also be a way. The question is whether all other board variation should be included as well.<br></div><div>There are 12 boards listed in the STM32CubeH7 repository example applications and I have not checked which pin and HSE values</div><div>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<br>board variation because some board settings will be identical, but maybe it would make sense to determine the board differences and look where <br>it makes sense to add new BSPs..<br></div></div></blockquote><div><br></div><div>Are they really 12 BSPs or just build variants of this one BSP family? </div><div><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>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 <br></div><div>correctly (at least console and clock, what I've tested so far) out of the box with the correct config.ini settings.<br></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>--joel </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div><br></div><div>Kind Regards<br></div><div>Robin<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 8 Jan 2021 at 06:35, Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello Robin,<br>
<br>
thanks for the updated patch. I am not sure if we should address the <br>
problem with a STM32H743ZI_NUCLEO option. An alternative would be to add <br>
a new BSP variant, e.g. stm32h743zi_nucleo, and two new options <br>
STM32H7_HSE_FREQUENCY and STM32H7_USART3_USE_GPIOD_PIN_8_PIN_9 with a <br>
default value determined by the BSP variant.<br>
<br>
-- <br>
embedded brains GmbH<br>
Herr Sebastian HUBER<br>
Dornierstr. 4<br>
82178 Puchheim<br>
Germany<br>
email: <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
phone: +49-89-18 94 741 - 16<br>
fax:   +49-89-18 94 741 - 08<br>
<br>
Registergericht: Amtsgericht München<br>
Registernummer: HRB 157899<br>
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler<br>
Unsere Datenschutzerklärung finden Sie hier:<br>
<a href="https://embedded-brains.de/datenschutzerklaerung/" rel="noreferrer" target="_blank">https://embedded-brains.de/datenschutzerklaerung/</a><br>
<br>
</blockquote></div>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a></blockquote></div></div>