On 9 Mar 2016, at 09:48, Maciek Borzecki <maciek.borzecki(a)gmail.com> wrote:

Hi,

I've pushed another set of updates. Hopefully I have not missed any
comments that were added to the previous versions.

I took the liberty of rebasing Daniel's patch on top of current
master, and so rebasing all of my patches on top of this one.

There are 2 major changes since the previous version.

One is extending of pinmux integration for STM32F1. That includes
structures that define alternate functions for IO pins plus some
helpers for selecting pin's function in a more convenient fashion.

The second change is adding UART_1 and UART_2 ports that map to USART2
and USART3 respectively.

Hopefully it'll be possible to merge at least some of these patches to
master.

Updated Changes:
https://gerrit.zephyrproject.org/r/645 st_stm32/stm32f1: introduce
STM32F1x SoC family

Maybe I was misunderstood in my email about the structure. I was suggesting to move the SoCs directly under soc/ and ski[ the st_stm32 level. If we are to do things the same way across architecture we would need to group all quarks under intel_quark.

Also, the st_ prefix is probably being used because we have ti_ and fsl_ for some of the existing SOCs. Maybe it is the right time now to drop the vendor part completely. (unrelated to this change, but we need to fix this with existing SOCs under arch/arm)

As more SOCs and boards are being added it is important to keep things consistent. The current structure allows adding a new SOC or board by just adding the files and structure and without changing any other files, we should keep it this way.



Anas

https://gerrit.zephyrproject.org/r/647 clock_control/stm32f10x:
introduce new driver for STM32F10x RCC
https://gerrit.zephyrproject.org/r/648 soc/stm32f1: add GPIO
registers mapping
https://gerrit.zephyrproject.org/r/649 pinmux/stm32: add common
driver for STM32 pinmux
https://gerrit.zephyrproject.org/r/650 serial/stm32: add new driver
for STM32 UART
https://gerrit.zephyrproject.org/r/651 gpio/stm32: add common driver
for STM32 GPIO
https://gerrit.zephyrproject.org/r/652 boards/stm32_mini_a15: add
new board
https://gerrit.zephyrproject.org/r/653 samples/drivers/disco: add
'disco' sample program
https://gerrit.zephyrproject.org/r/698 arch: arm: move nmi to common
location
https://gerrit.zephyrproject.org/r/711 clock_control/Kconfig: move
quark_se entries to separate file
https://gerrit.zephyrproject.org/r/712 clock_control: extend API
with clock rate query operation
https://gerrit.zephyrproject.org/r/713 soc/stm32f1/gpio: implement
GPIO support
https://gerrit.zephyrproject.org/r/714 soc/stm32f1/pinmux: implement
STM32 pinmux integration
https://gerrit.zephyrproject.org/r/715 boards/nucleo_f103rb: add new
board

Cheers,

On Wed, Mar 9, 2016 at 6:54 PM, Nashif, Anas <anas.nashif(a)intel.com> wrote:

On 9 Mar 2016, at 09:48, Maciek Borzecki <maciek.borzecki(a)gmail.com> wrote:

Hi,

I've pushed another set of updates. Hopefully I have not missed any
comments that were added to the previous versions.

I took the liberty of rebasing Daniel's patch on top of current
master, and so rebasing all of my patches on top of this one.

There are 2 major changes since the previous version.

One is extending of pinmux integration for STM32F1. That includes
structures that define alternate functions for IO pins plus some
helpers for selecting pin's function in a more convenient fashion.

The second change is adding UART_1 and UART_2 ports that map to USART2
and USART3 respectively.

Hopefully it'll be possible to merge at least some of these patches to
master.

Updated Changes:
https://gerrit.zephyrproject.org/r/645 st_stm32/stm32f1: introduce
STM32F1x SoC family

Maybe I was misunderstood in my email about the structure. I was suggesting to move the SoCs directly under soc/ and ski[ the st_stm32 level. If we are to do things the same way across architecture we would need to group all quarks under intel_quark.

Also, the st_ prefix is probably being used because we have ti_ and fsl_ for some of the existing SOCs. Maybe it is the right time now to drop the vendor part completely. (unrelated to this change, but we need to fix this with existing SOCs under arch/arm)

As more SOCs and boards are being added it is important to keep things consistent. The current structure allows adding a new SOC or board by just adding the files and structure and without changing any other files, we should keep it this way.

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.

Cheers,
--
Maciek Borzecki

On 09/03/2016, 16:13, "Maciek Borzecki" <maciek.borzecki(a)gmail.com> wrote:

On Wed, Mar 9, 2016 at 6:54 PM, Nashif, Anas <anas.nashif(a)intel.com> wrote:

On 9 Mar 2016, at 09:48, Maciek Borzecki <maciek.borzecki(a)gmail.com> wrote:

Hi,

I've pushed another set of updates. Hopefully I have not missed any
comments that were added to the previous versions.

I took the liberty of rebasing Daniel's patch on top of current
master, and so rebasing all of my patches on top of this one.

There are 2 major changes since the previous version.

One is extending of pinmux integration for STM32F1. That includes
structures that define alternate functions for IO pins plus some
helpers for selecting pin's function in a more convenient fashion.

The second change is adding UART_1 and UART_2 ports that map to USART2
and USART3 respectively.

Hopefully it'll be possible to merge at least some of these patches to
master.

Updated Changes:
https://gerrit.zephyrproject.org/r/645 st_stm32/stm32f1: introduce
STM32F1x SoC family

Maybe I was misunderstood in my email about the structure. I was suggesting to move the SoCs directly under soc/ and ski[ the st_stm32 level. If we are to do things the same way across architecture we would need to group all quarks under intel_quark.

Also, the st_ prefix is probably being used because we have ti_ and fsl_ for some of the existing SOCs. Maybe it is the right time now to drop the vendor part completely. (unrelated to this change, but we need to fix this with existing SOCs under arch/arm)

As more SOCs and boards are being added it is important to keep things consistent. The current structure allows adding a new SOC or board by just adding the files and structure and without changing any other files, we should keep it this way.

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.

Anas

Cheers,
--
Maciek Borzecki

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? 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/.

--
Andrew Boie
Staff Engineer - EOS Zephyr
Intel Open Source Technology Center

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

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.


Anas

--
Andrew Boie
Staff Engineer - EOS Zephyr
Intel Open Source Technology Center

On Thu, 2016-03-10 at 01:49 +0000, Nashif, Anas wrote:

 

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).

Of course, but I don't know if at the time we were thinking about
supporting a bunch of variants of a particular microcontroller that are
almost the same. I think this is an opportunity for iterative
refinement.

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.

My train of thought was that if there are closely related variants of a
SoC/MCU, then subdirectories would be appropriate for them. I don't
think another layer would be a requirement for every board. For
something like atmel_sam3 the variant and the soc would be the same
value: SOC=atmel_sam3 SOC_VARIANT=atmel_sam3

It might also be useful to use a diffrent word than "soc" as the term
for the second level under arch, maybe a term that could apply to MCU
or SOC. We shouldn't feel rigidly bound by this hierarchy, just when it
makes sense to do so (i.e. a bunch of variants that are very very
similar which I believe is the case here)

arch/arm/soc/
frdm_k64f/
<code for frdm_k64f>
atmel_sam3/
<code for atmel_sam3>
st_stm32/
<common code for all st_stm32 variants>
st_stm32f1/
<stm32f1-specific bits>
st_stm32f2/
<stm32f2-specific bits>
....


Andrew

On Thu, Mar 10, 2016 at 02:46:02PM -0500, Boie, Andrew P wrote:

On Thu, 2016-03-10 at 01:49 +0000, Nashif, Anas wrote:

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).

Of course, but I don't know if at the time we were thinking about
supporting a bunch of variants of a particular microcontroller that are
almost the same. I think this is an opportunity for iterative
refinement.

Question: if they're almost the same, do we really need an extra
directory layer, or simply have different files for the parts that
differ in the same directory ? That would prevent directory
proliferation...

That said, I don't really have a problem with multiple directory layers
if it keeps things clear, and more importantly, if it prevents code
duplication.

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.

My train of thought was that if there are closely related variants of a
SoC/MCU, then subdirectories would be appropriate for them. I don't
think another layer would be a requirement for every board. For
something like atmel_sam3 the variant and the soc would be the same
value: SOC=atmel_sam3 SOC_VARIANT=atmel_sam3

I don't think we want to go back to variants. We had those at some
point for BSPs, which were the equivalents of SoCs, and the variants
represented the boards really. If we need a variant, that's probably a
sign that we need an extra layer between SoCs and architectures. Like
SoC "family" ?

It might also be useful to use a diffrent word than "soc" as the term
for the second level under arch, maybe a term that could apply to MCU
or SOC. We shouldn't feel rigidly bound by this hierarchy, just when it
makes sense to do so (i.e. a bunch of variants that are very very
similar which I believe is the case here)

arch/arm/soc/
frdm_k64f/
<code for frdm_k64f>
atmel_sam3/
<code for atmel_sam3>
st_stm32/
<common code for all st_stm32 variants>
st_stm32f1/
<stm32f1-specific bits>
st_stm32f2/
<stm32f2-specific bits>
....

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
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.

On Fri, 2016-03-11 at 22:41 +0000, Maureen Helm wrote:

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.

Something that also occurred to me: we have the same issue with our
boards/ directory. As Zephyr gets put on more and more boards we're
going to find ourselves with different variants of each board. I imagine
new board revs, or that week they used a different peripheral part
because of BOM cost, etc. So eventually I think we'll also have board
configurations in-tree that are *almost* the same except for a few
parameters...could share the same board.c, etc

--
Andrew Boie
Staff Engineer - EOS Zephyr
Intel Open Source Technology Center

On Fri, Mar 11, 2016 at 3:34 PM, Nashif, Anas <anas.nashif(a)intel.com> wrote:

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
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.

Do we have a consensus on this matter then? Did you get a chance to
discuss this internally?

Cheers,
--
Maciek Borzecki

On 14 Mar 2016, at 08:18, Maciek Borzecki <maciek.borzecki(a)gmail.com> wrote:

On Fri, Mar 11, 2016 at 3:34 PM, Nashif, Anas <anas.nashif(a)intel.com> wrote:

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
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.

Do we have a consensus on this matter then? Did you get a chance to
discuss this internally?

We are looking into this and will send a proposal to address this by EOD.

Anas

Cheers,

On 14/03/2016, 22:46, "Kalowsky, Daniel" <daniel.kalowsky(a)intel.com> wrote:

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

<..snip..>

Do we have a consensus on this matter then? Did you get a chance to
discuss this internally?

Sorry I was out of the office today, and most likely delayed Anas's hope of delivering a solution by EOD. That said, he reviewed the patch online, and for some reason Gerrit won't take my response.

Anas correctly highlights that your initial patch should not advertise the support for the STM32F{ 2 | 3 | 4} MCUs, those should be added when that support comes in. I completely overlooked this, sorry about that.

I am working right now on defining a new layer in Kconfig and reorganising Kconfig for this purpose and will take the STM32 changes and propose better structure for all architectures and existing SoCs.

Anas

On Tue, Mar 15, 2016 at 3:50 AM, Nashif, Anas <anas.nashif(a)intel.com> wrote:

On 14/03/2016, 22:46, "Kalowsky, Daniel" <daniel.kalowsky(a)intel.com> wrote:

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

<..snip..>

Do we have a consensus on this matter then? Did you get a chance to
discuss this internally?

Sorry I was out of the office today, and most likely delayed Anas's hope of delivering a solution by EOD. That said, he reviewed the patch online, and for some reason Gerrit won't take my response.

Anas correctly highlights that your initial patch should not advertise the support for the STM32F{ 2 | 3 | 4} MCUs, those should be added when that support comes in. I completely overlooked this, sorry about that.

I am working right now on defining a new layer in Kconfig and reorganising Kconfig for this purpose and will take the STM32 changes and propose better structure for all architectures and existing SoCs.

Cool, I'll wait for your changes then.

I have a couple of updates lined up already, namely support for
interrupts on UART and GPIO input (might suquash that with the GPIO
patch anyway). There's also some initial support for EXTI and GPIO
interrupts, though this might require a number of iterations as the
STM32's way of handling this does not map that well to the GPIO driver
API.

Cheers,
--
Maciek Borzecki