Dear RIOT developers,
as part of migrating CPU and CPU_MODEL definition to `Makefile.features` I am facing custom handling of multiple boards in the same directory with sometime creative handling but not a proper build system integration.
There are multiple issues with this:
* none of the alternative boards are ever be compiled in the CI
* when testing, giving multiple variables to specify a board is not really handled
* building the separate boards is not handled with `BUILD_IN_DOCKER`
* custom non standard configuration variables that are not properly handled in the whole build system
The current implementation are currently done through:
* Using a default `CPU_MODEL ?= default_model` however the `CPU_MODEL` variable is not passed to docker
* mulle (2 possibilities)
* pba-d-01-kw2x (3 possibilities)
* cc2538dk (no documentation but I think this one is just a mis-write and not a wanted thing)
* Using a `STM32F103C8_FLASH_HACK` variable to just set a different `CPU_MODEL`. It applies to `bluepill` and `blackpill` but is just documented for the `bluepill`
* An undocumented `BOARD_MODULE` variable that triggers a wildcard then a grep to find `CPU_MODEL` (yes it queries your filesystem for a static mapping). Its generic with many possible values but only implemented for 2 "board modules"
I would like to know who really uses these boards modifications, and what we should do with them.
Why were they implemented in the first place instead of having separate boards? Would have prevented having them merged?
Should we just split all these boards, it would currently result in 5 or 6 boards (depending on the blackpill).
Should we keep support for multiple boards together? if yes, can we limit to only changing `CPU_MODEL` through this variable and remove the other custom handling? Still knowing they would not be automatically tested by CI.
I am willing to take care of the required changes when a direction is decided.
Regards,
Gaëtan - cladmi
Hi Gaëten,
BOARD_MODULE is used by the Silicon Labs SLWSTK6000b because it is one board with many supported CPU daughter boards (different CPU, other radio configs). You would buy that board, but also need to buy this daughter board separately.
A similar approach is used by the EFM32 CPU family. The (incomplete) list of daughter boards is here: https://github.com/RIOT-OS/RIOT/blob/master/boards/slwstk6000b/modules.txt
Kind regards,
Bas
Hi,
I think the question is what mapping you want to have between a board (the
physical hardware) and a RIOT board. If the mapping should be 1:1, than one
physical board could have different CPUs and configurations.
If you however agree with a 1:n mapping, than having different RIOT boards for
each configuration of a board is fine.
With the issues you presented in mind, I'd say a 1:n mapping might be the
solution with the least maintenance overhead, provided that `boards/common` is
heavily used to avoid duplication.
Kind regards,
Marian
Hi Bas,
Hi Gaëten,
BOARD_MODULE is used by the Silicon Labs SLWSTK6000b because it is one board with many supported CPU daughter boards (different CPU, other radio configs). You would buy that board, but also need to buy this daughter board separately.
A similar approach is used by the EFM32 CPU family. The (incomplete) list of daughter boards is here: https://github.com/RIOT-OS/RIOT/blob/master/boards/slwstk6000b/modules.txt
So somehow, the `slwstk6000b` board has no sense on its own. It must be put with a daughter board. We could rename the combinations to
* `slwstk6000b-slwrb4150a`
* `slwstk6000b-slwrb4162a`
There are currently only two supported daughter boards in RIOT if I understand correctly:
https://github.com/RIOT-OS/RIOT/tree/master/boards/slwstk6000b/modules
The issue with relying on a specific configuration variable is that it is not documented and not correctly integrated in the whole system.
The variable is not handled with `BUILD_IN_DOCKER`, `scan-build` and if two boards would be using `BOARD_MODULE`, it would break the parsing done by `info-boards-supported`.
It could be fixed, but it would add an extra specific handling for something that is for me just different "boards" in the RIOT "board" concept. It would also still currently only compile the first combination in CI if no specific handling of multiple boards in one directory is done.
My goal is to keep the functionality without, if possible, the specific handling.
Kind regards,
Gaëtan