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:
Of course, but I don't know if at the time we were thinking about
IThis the design as we have now (and it was proposed and discussed).
share Dan's concerns, I think it may be better to have st_stm32/
then subdirectories with variants thereof, with common code at the
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/.
supporting a bunch of variants of a particular microcontroller that are
almost the same. I think this is an opportunity for iterative
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
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
Under soc/ we have frdm-k64f, atmel_sam3 which are SoCs and not sub-My train of thought was that if there are closely related variants of a
architectures. If you think we need another layer, then we need to
change this across the board and not only for STM32.
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)
<code for frdm_k64f>
<code for atmel_sam3>
<common code for all st_stm32 variants>