Re: STM32F103x port

Pawel Wodnicki <root@...>


I have been working with Dan's stm32 patch to add support for stm32f4xx and just wanted to share couple of thoughts.

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.


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.

Pawel Wodnicki

Join to automatically receive all group messages.