Re: [users] Re: Re: Re: Re: Re: STM32F103x port


Maureen Helm
 

-----Original Message-----
From: Nashif, Anas [mailto:anas.nashif(a)intel.com]
Sent: Friday, March 11, 2016 8:34 AM
To: Kalowsky, Daniel <daniel.kalowsky(a)intel.com>
Cc: maciek.borzecki(a)gmail.com; Boie, Andrew P <andrew.p.boie(a)intel.com>;
Walsh, Benjamin (Wind River) <benjamin.walsh(a)windriver.com>;
devel(a)lists.zephyrproject.org; users(a)lists.zephyrproject.org
Subject: [devel] Re: [users] Re: Re: Re: Re: Re: STM32F103x port

On 10 Mar 2016, at 13:28, Kalowsky, Daniel <daniel.kalowsky(a)intel.com>
wrote:

-----Original Message-----
From: Nashif, Anas
Sent: Wednesday, March 9, 2016 5:49 PM
To: Boie, Andrew P <andrew.p.boie(a)intel.com>; Kalowsky, Daniel
<daniel.kalowsky(a)intel.com>
Cc: users(a)lists.zephyrproject.org; maciek.borzecki(a)gmail.com;
devel(a)lists.zephyrproject.org; Walsh, Benjamin (Wind River)
<benjamin.walsh(a)windriver.com>
Subject: Re: [devel] Re: [users] Re: Re: Re: Re: Re: STM32F103x port

On 09/03/2016, 19:51, "Boie, Andrew P" <andrew.p.boie(a)intel.com> wrote:

On Wed, 2016-03-09 at 21:35 +0000, Kalowsky, Daniel wrote:
-----Original Message-----
Summing up, what you're basically suggesting is having a
structure like this (assumig that we keep vendor prefix for the time
being):

arch/
arm/
soc/
st_stm32f1/
Kconfig.soc
Kconfig
...
soc.c
st_stm32f2/
...
st_stm32l0/

If we're on the same page then i"ll post some patches tomorrow.
Seems
like an easy fix.
Yes, the only different from what you have right now is having 1
level
less. I
think everything else should stay the same.
I not convinced that is any good. You're essentially going to
create a larger
mess of MCUs in the arch/arm/soc directory.

The goal of keeping everything in a common directory (st_stm32) is
to
enforce maximum sharing between MCUs where possible. For example,
the stm32f1_init is really the same for the STM32F{1 | 2 | 3 | 4 }x
MCUs. Moving this into an upper level "common" area, not only makes
it difficult to find, it just creates confusion as we add in future platforms.

Do we need another layer of abstraction in the build for SoC variants?
Where did you see a new layer in what I said? The current patch and
adding
st_stm32 is adding a new layer. st_stm32 is not an SoC, its an
architecture (just like there is STM8) that has different variants
(M0+, M3, M4, …) that have additional SoCs. st_stm32 is something
comparable to Quark from x86.
So with this patch and looking at the Kconfig variables we have

arch / doc family or architecture / soc variant / soc / board
You're confusing me now. Please state your objection to the proposed
method clearly here.

I am not in favour of adding the stm32 layer. I am all for adding the "SoC series"
or "family layer”.

What this means:

instead of


arch/
arm/
soc/
stm32/
st_stm32f1/
st_stm32f2/


we will just have:

arch/
arm/
soc/
st_stm32f1/ (this would include multiple SoCs from the same series
and the same architecture)
st_stm32f2/


The above model is already used for the atmel_sam3, where SAM3 is the series
or family and ATMEL_SAM3X8E is the actual SoC. Actually, looking at

http://www.atmel.com/products/microcontrollers/arm/sam3x.aspx we should
rename sam3 to sam3x to be more consistent.

If we decide to add one more level, i.e. ATMEL SAM or ST STM32, then we
need to revisit and redesign the hierarchy and mark those being families or
series in Kconfig and stop the mis-use of CONFIG_SOC_XX for three different
levels in the hierarchy.

I think we will need this additional level to support more Kinetis family devices from Freescale/NXP. Many of these devices share common peripherals, differing by number of instances and base addresses for a given instance. Related to that, I also think SOC peripheral drivers should be located under arch/arm/soc. If you moved them here, I could see a structure like this:

arch/
arm/
soc/
kinetis/
drivers/ (peripheral drivers shared across multiple Kinetis SOCs)
mk64f12/ (frdm-k64f12 is the name of the board, not the SOC. This will need to be fixed at some point.)
mk22f12/
mkl27z644/
and many more...

Where each of the mk* folders represents an SOC in the Kinetis family, and instantiates a subset of peripheral drivers that apply to that SOC.



I
share Dan's concerns, I think it may be better to have st_stm32/ SoC
and then subdirectories with variants thereof, with common code at
the toplevel.

This would mean we have inheritance as follows: arch / soc /
soc_variant / board. This would be something fully supported by the
build system, like it knows about arches / boards / socs now.

Not keen on collapsing all this to just soc/.
This the design as we have now (and it was proposed and discussed).
Under soc/ we have frdm-k64f, atmel_sam3 which are SoCs and not sub-
architectures. If you think we need another layer, then we need to
change this across the board and not only for STM32.
Correct. That would be step #2.
No, We make first make it fit in the current structure then take our time and do
it right after some discussion and after getting to an agreement.


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