ports/rp2: Make pins.csv configurable. #17028
Open
+7
−3
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Allow mpconfigboard.cmake to specify a custom
MICROPY_BOARD_PINS
to override${MICROPY_BOARD_DIR}/pins.csv
.Summary
RP2350 has a "B" variant chip which could conceivably be configured in a board variant (big and small versions) and require its own, separate pins.csv config with the additional pins configured.
This may apply also to W and non-W versions where the CYW43 might need
WL_GPIOn
pins specified but there are otherwise few meaningful changes to justify entirely separate boards.Finally the RM2 module support added by #16057 might need optional
WL_GPIOn
pins configured for traditionally non-W boards with added support for an external wireless module, though this is contentious since those pins wont be available without an attached module.This PR is mostly to address point 3, in an effort to make the changeset in #16057 smaller and easier to review.
But it's also counter-intuitive to have support for variants without support for specifying variant versions of config files.
Testing
TODO! This would need a rebase of #16057 assuming this is even the way we want to approach the problem.
Trade-offs and Alternatives
I don't think there are any real downsides to this feature, though it should probably be reflected across all CMake-based ports.