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
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
