[riot-devel] Working on port to SODAQ Autonomo (SAMD21)

Kaspar Schleiser kaspar at schleiser.de
Wed Jun 15 11:42:55 CEST 2016


Hey,

On 06/15/2016 09:15 AM, temmihoo at gmail.com wrote:
> Soc and mcu family relations and naming schemes should be respected as well. 

Well, there's always the tradeoff between consistency within RIOT and
consistency with whatever a vendor does to sort it's MCU variants.

I must say that I prefer the RIOT naming scheme, which is more or less
unified over all the vendors. If not because we as RIOT developers have
it easier to navigate in quite a large code base, then because a large
part of RIOT's appeal is the abstraction of actual hardware it offers,
across a wide range of platforms.

> The relationships do not need to be elaborately reflected in build
> automation as just following the naming schemes is enough to tell the
> reader how they are related.

Well, we do have a build matrix with ~5k entries. Build automation goes
a long way, and the more we can declare using conventions, the less we
have to maintain.

> I'm personally more familiar with ST and their Nucleo64 family of 
> boards and STM32 family of MCU, so I cannot suggest anything
> specific detail for this particular discussion.

I think that state reflects that of many RIOTers: there's a lot of
experience with one (or some) MCU families, and less to none with others.

When bringing up a new MCU family, I usually do my first steps with the
platform, so the vendor's family relations are not clear yet. It is
usually only when adding the second member of a family that I can assess
how similar they are.

Add to that the complication that sometimes we add support for a
specific MCU before other family members are available or even announced.

So I think the way we currently do it is sound, which is incrementally
adding common folders as soon as it makes sense (saves duplicate code,
...), using a scheme similar (if not consistent) across supported
boards/MCUs.

But as I'm probably biased, do others feel that the folder scheme should
more reflect a vendor's scheme?

Kaspar



More information about the devel mailing list