Hi Bas,
On 8/26/19 3:34 PM, Bas Stottelaar wrote:
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
Kind regards,
Bas
Op 26 aug. 2019 om 14:41 heeft Gaëtan Harter <[email protected]> het
volgende geschreven:
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
_______________________________________________
devel mailing list
[email protected]
https://lists.riot-os.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
[email protected]
https://lists.riot-os.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
[email protected]
https://lists.riot-os.org/mailman/listinfo/devel
