On 08/01/2021 15:30, Joel Sherrill wrote:
On Fri, Jan 8, 2021 at 6:58 AM Robin Müller <robin.muelle...@gmail.com
<mailto:robin.muelle...@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.
Good, I was about to write something similar. Adding a BSP variant is
simple.
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.
I will add a variant for this board in the next days. It would be nice
if you could test it.
--
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
