[PATCH] bsps/arm/stm32f4 Optimize get pin and change from HAL to LL

[Cedric Berger]

Hello,

On 07.07.22 09:35, Duc Doan wrote:
> Actually my project is focused on STM32F4, but it is nice that the code
> could be extensible to H7. However, I can't think of a good way to use
> that code with H7 right now; do you think that the code can be copied
> and pasted to H7 BSP? Or is there a better way to share the code among
> all STM32 BSPs?

I've a lot of experience with STM32 dev, but not with RTEMS, so I'm not 
the best person to answer that question.

If you want to expand support for the H7 now, maybe Karel or someone 
else on the list can point you to the right way.

What I can say by reading your "[PATCH 4/4]" file is that I don't see 
what would not work for the H7. If it compiles on H7, it's likely to 
work as is (except for the GPIO port lists, you'd need other ifdefs like 
you do for STM32F429X, or maybe just keep 
stm32f4_gpio_init/stm32f4_gpio_deinit separate for F4 and H7).

Maybe it's as simple as renaming the identifiers from stm32f4_gpio => 
stm32_gpio for clarity for most functions, and declaring these files in 
the H7 scripts.

BTW: by rereading your "[PATCH 4/4]" file I noticed that there is 
something else you need to be careful:

I don't know how the lifecycle of init/deinit is intended to work, but 
the stm32f4_gpio_deinit() function is dangerous:

The problem is that if you disable the clock of, say, GPIOA, it will 
also make all alternate function IPs that uses these pins stop working.

So if you are using the HAL for example for the Ethernet IP, the board 
I'm working with will also call the following functions in it's 
initialization routine:

HAL_ETH_MspInit()
{
     ...
     __HAL_RCC_GPIOG_CLK_ENABLE();
     __HAL_RCC_GPIOC_CLK_ENABLE();
     __HAL_RCC_GPIOA_CLK_ENABLE();
     ...
}

So your "stm32f4_gpio_deinit" routine will make all IPs that share the 
pins with the GPIO port also stop working.

The trivial fix is of course to make "stm32f4_gpio_deinit" do nothing.

Cedric