[PATCH v1 2/2] bsps/stm32h7: Configure UART clocks when enabled

[Kinsey Moore]

On Mon, Jul 24, 2023 at 3:30 PM Karel Gardas <karel at functional.vision>
wrote:

>
>   Hello Kinsey,
>
> honestly I don't know what to do about this patch. Let me explain a bit
> history behind STM32h7. It was originally submitted by embedded brains
> guys (Sebastian main, Christian added few things later) supporting the
> only eval board of that time stm32h743-eval(2). Sebastian also added
> support for nucleo with h743zi and Robin Mueller fixed several things on
> that. So this was 2 boards supported. Then I came and added support for
> 3 more boards where two was with 2 BSPs variants each (one for M7 and
> one for M4). Due to amount of code in #ifdef for various boards we (my
> customer and me) have decided to de-cpp code a bit and divide it into
> different supported board directories. Basically we have also followed a
> lead by embedded brains guys and their imxrt bsps family (and boards
> directory). This was accepted and now you have this boards directory
> with different boards providing just as lean as possible configuration
> in C files sharing some common generic in bspstarthooks.c from start
> subdirectory.
>
> So basically the idea was to avoid complex #ifdefs and rather copy clean
> C files around. (as much as possible, realistically).
>
> Now, your patch seems to be going a bit in reverse direction and I do
> not see clearly the motivation behind it, why do you do that this way?
>
> I mean, you edit peripherals clock for stm32h743-eval(2) board BSP.
> AFAIK this file is not reused on any other BSP variant (different board)
> at all.
> The board in question (stm32h743-eval) supports only UART1 on its
> ST-Link or DB-9 canon connection. The UART1 is shared between those two
> mechanisms, which one is used, you define by jumper placed on the board.
> There is no other UART1 connector provided on the board. So I do not see
> reason why you add all other UARTs into #ifdefs for this particular
> board/bsp variant? And hence my question about your motivation and where
> you are heading...
>

Given that, I now understand the confusion. I have a board in hand that
will never see an upstream BSP and I was hoping to be able to configure the
base STM32H7 BSP for it, but what I interpreted as the "base" STM32H7 BSP
is not actually a generic base BSP. I was also contemplating moving more of
the peripheral configuration into shared files since the enable/disable
configuration items are already there and it would be convenient for the
various BSPs to exist as some custom code and then a selection of presets
for those configuration items. I'll have to think about the best way
forward for the project I'm working with.

Kinsey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20230724/49cd49fe/attachment.htm>