Re: STM32F103x port

Kalowsky, Daniel <daniel.kalowsky@...>

Hey Pawel,

-----Original Message-----
From: Pawel Wodnicki [mailto:root(a)]
Sent: Tuesday, March 1, 2016 8:26 AM
To: devel(a)
Subject: [devel] Re: Re: Re: STM32F103x port


I have been working with Dan's stm32 patch to add support for stm32f4xx
and just wanted to share couple of thoughts.
Oh wow, didn't realize that DRAFTS were visible to the world. Guess this means I'll need to be more careful about what I put in there. Sorry for the large amount of broken code that was in the patches before.

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)
A lot of this sounds like what Maciek is suggesting as the layout.

As for drivers for specific stm32 peripherals some like the RCC (Reset & Clock
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.
Wind River just submitted a series of drivers for the FRDM-K64F. It might be worth looking at and modeling the STM32 after something similar.

Join to automatically receive all group messages.