boards/slwstk6000b-*: split one board for each module #12343
Conversation
|
@basilfx I did the renaming by appending the module. This now split it in two boards. What do you think? This currently does not do any cleanup just refactoring to have separate boards. |
|
This looks good. I think it is a good trade-off between re-use and duplication. I don't own the board to test this, unfortunately. |
|
Ah I expected you had it as you were the contributor. But indeed you were not the one testing it in the PR. What do you think about this change @kaibeckmann ? |
cf5242c to
9de2ec5
Compare
|
Rebased as the dependency was merged. |
|
My bad, I forgot the |
00bc5d1 to
a118fa0
Compare
|
This one also has overlap with #12337 on the blacklisted file so need to be synchronized if merged. |
|
This PR needs a rebase. |
a118fa0 to
db8374d
Compare
Well, I think the original idea behind the module system was, that there are a ton of modules available from silabs. To have a own folder for each, would clutter the boards-folder. If someone makes the support for each. If not (like at the moment) the new structure is better to understand. I tested the pr (compiled, flashed, interacted) on the slwstk6000b-slwrb4150a and slwstk6000b-slwrb4162a. Its working. |
I added the tested flag.
IMO the board, or at least the main component here would be the If these How I think this would grow is that we would add the Because of this I think it might make more sense to have the board names inverted as well, so what do you think? I have only had a quick look at the code and datasheets, so maybe what I'm saying makes no sense or is unfeasible. |
The issue is that in RIOT there is no handling of multiple boards in one directory. It goes more into having one board per directory and put in "common" the redundant part. My issue is the indirection to get to the The way the My short term goal is having one RIOT "board" per module/combination so changed first the name to stay similar to the current one too keep the changes minimal. Changing the current organization and then splitting the modules to a common would be a separate step for me. |
Yes, my comment was just a though on future organization if the directory gets cluttered, and would be handled in different PRs.
I understand the reasoning and the issue addressed here. @basilfx agreed with the changes, and @kaibeckmann had no issue given the current state, we can tackle refactoring when multiple daughter-boards appear. I would go ahead as is, is it ok to squash @basilfx ? |
|
ping @basilfx |
|
Yes, please squash and rebase. |
db8374d to
f4e27ca
Compare
Migrate the board to be implemented with a common/slwstk6000b. It is a pre step for splitting the board for each "BOARD_MODULE".
f4e27ca to
a993218
Compare
|
Squashed and rebased. I reworded the first commit message to say |
|
Two examples were too big for the |
Define one board for each of the available modules.
9d4888a to
1ab5a93
Compare
|
Thank you for the review! |
Contribution description
Define one board for each of the available modules.
Migrate the board to be implemented with a common/slwstk6000b.
This PR currently does not migrate CPU_MODEL, only handles the renaming.
It depends on boards/slwstk6000b: move CPU definiton to Makefile.features #12334Testing procedure
Using these boards still work with the new name, and murdock manages to compile everything.
I unfortunately do not have any of the boards for testing.
Reviewing the build system output
Comparing the output of
info-buildfor both configuration.In the PR
On master:
The difference is only because of the renaming and new common module.
git grep -e SLWSTK6000B slwstk6000b)USEMODULE board_common_slwstk6000bcommon/slwstk6000bdiff output
Issues/PRs references
The riot-devel email where I talked about it https://lists.riot-os.org/pipermail/devel/2019-August/006289.html
Part of Tracking: move CPU/CPU_MODEL to Makefile.features #11477
Depends on boards/slwstk6000b: move CPU definiton to Makefile.features #12334