Initial (placeholder) ESP32 fork and future RP235X support, implem pin capabilities map for determining pin functions #93
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…'s pin capabilities maps; add initial support requirements for RP2350 and ESP32 boards.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Pin capabilities allows a dev to define what functions a pin can apply, with support for overrides based on the board codename if any are available (rn used for the Pico boards) as its pins map seems to contradict the datasheet.
The main benefit is to futureproof in RP2350-series support, with the bonus that the ESP fork firmware can also be supported (with some added as of TeamOpenFIRE/OpenFIRE-Boards#5). ESP currently doesn't have a working pin capabilities descriptor nor any overrides, so for now the ESP boards are disabled in the previewer and will crash when syncing an ESP fork'd board atm. That part should be the responsibility of the fork maintainer.
At least for RP2040 devices, to the user, current pin mapping bits functionality remains the same as before - so I2C channel clashes and mismatches will still be detected as appropriate. This part could probably be disabled for ESP devices since they seem to be able to remap I2C to whichever pins (again, details are ultimately up to the fork's maintainer).