On Wed, Mar 2, 2016 at 2:49 AM, Kalowsky, Daniel
<daniel.kalowsky(a)intel.com> wrote:

-----Original Message-----
From: Maciek Borzecki [mailto:maciek.borzecki(a)gmail.com]
Sent: Tuesday, March 1, 2016 11:19 AM
To: Brandewie, Dirk J <dirk.j.brandewie(a)intel.com>
Cc: Kalowsky, Daniel <daniel.kalowsky(a)intel.com>;
devel(a)lists.zephyrproject.org; users(a)lists.zephyrproject.org
Subject: Re: [devel] Re: Re: STM32F103x port

On 03/01 10:17, Dirk Brandewie wrote:

On 02/29/2016 02:26 PM, Kalowsky, Daniel wrote:

-----Original Message-----

First suggestion, create an arch/arm/soc/stm32, and use the Kconfig to
allow selecting of the various flavors of the STM32 chip. This would
be similar to what you've already got with the Kconfig.soc.stm32f103ve
file, merged with the values from your Kconfig.soc. Then keeping the
Kconfig to the pieces generic to all the STM32 portions (i.e. flash
size, base address, etc).

Thoughts?

Makes sense. I think we should also add another 'MCU family' level of
hierarchy. We would have then:

arch/
arm/
soc/
stm32/
stm32f1xx/
<soc specific>
stm32f2xx/
<soc specific>
stm32f4xx/
<soc specific>

I'm not opposed to this.

Ben/Dirk any commentary?

Having thought about it for 10 seconds it seems reasonable :-) To the
greatest extent reasonable please avoid link time binding of SOC specifc
code into the generic stm32 code. We don't want to the next guy to
wonder which init() function is called.

Do you mind taking a look here
https://github.com/bboozzoo/zephyr/tree/bboozzoo/stm32f103-next-soc-
layout-change
and sending some feedback?

The branch implements this layout:
arch/
arm/
soc/
stm32/
Kconfig <-- includes family specific Kconfigs
Kconfig.soc <-- SOC family selection under 'General platform..'
stm32f1x/

Only one x? I'll admit to being relatively new to the STM32 family so it's not clear to me if 10x and 1xx will make any difference. Same goes for other STM32F models. I'm not sure the sub-directories are needed yet. Still digesting this one.

Single 'x' as in 'everything that comes after the i-1 character' :)

As for the models, I'm not aware of any non STF32F10x MCUs, however
all of these are collectively referred to as STM32F1
series/family. The core is different between F[0-4] families, F1 are
all Cortex-M3, F0 are Cortex-M0[+], F3/4 are Cortex-M4.

Within a family, the MCUs differ wrt. to clock and peripherals
present. Then within a subfamily (?), ex. STM32F103xx, the MCUs differ
again, for instance there's no DAC in STM32F103xB, but there are 2
DACs in STM32F103x[CDEFG]. Again, the xB line only has 3 UARTs, while
other variants have 5 ports.

The last letter indicates the amount of flash and SRAM (dubbed as
high- low- medium- density int the specs).

The one but last letter, ex. STM32F103VE - V indicates the pin
count. This will influence pin remapping and in the case of packages
with very few pins, it will indicate that certain peripherals may have
been left out.

A quite elaborate part number coding scheme. That's why I included per
family subdirectories and Kconfig.soc.<mcumodel> in my proposal.

Makefile
Kconfig.soc.family <-- list of possible MCUs in this family
general defaults

Having done some minor toying around with Kconfig today, I decided to use Kconfig.soc to just declare the generic STM32 family. From there, the Kconfig is used to better tune to which family type, but that most likely isn't enough granularity. Looks like you and I had done some similar work, as I just uploaded my minor tinkering from today.

Cheers,
--
Maciek Borzecki