Re: STM32F103x port


Pawel Wodnicki <root@...>
 

Hi,

I have been working with Dan's stm32 patch to add support for stm32f4xx and just wanted to share couple of thoughts.
https://gerrit.zephyrproject.org/r/#/c/209/

I would second the idea of adding additional level of hierarchy under st_stm32 soc for functionality specific to the line of ST MCU's.
Just looking at the STM32F chips there is 6 variants not even including STM32L. Organizing soc folders to reflect that hierarchy would help dealing with the variability within the STM32 line of mcu's without cluttering arch/arm/soc/ folder.

arch/arm/soc/st_stm32/
arch/arm/soc/st_stm32/stm32f0xx/
arch/arm/soc/st_stm32/stm32f1xx/
arch/arm/soc/st_stm32/stm32f2xx/
arch/arm/soc/st_stm32/stm32f2xx/
arch/arm/soc/st_stm32/stm32f4xx/
arch/arm/soc/st_stm32/stm32f7xx/

Common functionality could be implemented at the arch/arm/soc/st_stm32/ level, ie:

arch/arm/soc/st_stm32/soc.c:static int st_stm32_init(struct device *arg)

But when needed SOC api could be structured in a hierarchical way, ie:

arch/arm/soc/st_stm32/soc.c:void clock_init(void)

arch/arm/soc/st_stm32/stm32f1xx/soc.c:void clock_init_stm32f1xx(void)
..
arch/arm/soc/st_stm32/stm32f4xx/soc.c:void clock_init_stm32f4xx(void)

As for drivers for specific stm32 peripherals some like the RCC (Reset & Clock Control)
could be handled at the st_stm32 soc top level with #ifdefs but there are some peripherals that use different versions of the hardware IP (GPIO is a good example) and would be easier to handle at the level specific to the MCU soc.

Cheers,
Pawel Wodnicki

Join devel@lists.zephyrproject.org to automatically receive all group messages.