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


Boie, Andrew P
 

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

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