boards,sys/arduino: major clean up #19759
Merged
Conversation
This file contains 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
maribu
added
State: WIP
maribu
requested review from
MrKevinWeiss,
aabadie,
jia200x,
leandrolanzieri,
dylad,
fjmolinas,
gschorcht and
basilfx
as code owners
github-actions
bot
added
Area: doc
github-actions
bot
added
Area: tests
maribu
force-pushed
the
arduino-features
branch
2 times, most recently
from
b783a36
to
63d4fd7
Compare
maribu
added
CI: full build
maribu
removed
CI: full build
maribu
force-pushed
the
arduino-features
branch
3 times, most recently
from
c906367
to
e89e40a
Compare
|
@kfessel I split the |
kfessel
reviewed
Jun 26, 2023
- Rename all `arduino_pinmap.h` to `arduino_iomap.h`
- An empty `arduino_pinmap.h` that just includes `arduino_iomap.h`
is provided for backward compatibility
- Move all info from `arduino_board.h` into the new file as trivial
macros, so that they can also be used outside of sketches
- The new name reflects the fact not just pin mappings, but also
other I/O features such as PWMs are mapped
- Drop all `arduino_board.h`
- `arduino_board.h` and `arduino_iomap.h` now provide the exact
same information, just in a different format
- a generic `arduino_board.h` is provided instead that just
uses the info in `arduinio_iomap.h` and provides them in the
format the code in `sys/arduino` expects it
- Add fine grained features to indicate for mappings
- availability of mappings for analog pins, DAC pins, PWM pins,
UART devices, SPI/I2C buses to the corresponding RIOT
identification can now be expressed:
- `arduino_pins`: `ARDUINO_PIN_0` etc. are available
- `arduino_analog`: `ARDUINO_A0` etc. are available
- `arduino_pwm`: `ARDUINO_PIN_13_PWM_DEV` etc. are available
- `arduino_dac`: `ARDUINO_DAC0` etc. are available
- `arduino_uart`: `ARDUINO_UART_D0D1` or similar are available
- `arduino_spi`: `ARDUINO_SPI_ISP` or similar are available
- `arduino_i2c`: `ARDUINO_I2C_UNO` or similar are available
- mechanical/electrical compatibility with specific form factors
can now be expressed as features:
- `aruino_shield_nano`: Arduino NANO compatible headers
- `aruino_shield_uno`: Arduino UNO compatible headers
- `aruino_shield_mega`: Arduino MEGA compatible headers
- `aruino_shield_isp`: ISP header is available
This provides the groundwork to implement shield support as modules
that can rely on the I/O mappings, rather than having to provide a
configuration per board.
kfessel
approved these changes
Jun 26, 2023
|
bors merge |
bors bot
added a commit
that referenced
this pull request
Jun 26, 2023
19759: boards,sys/arduino: major clean up r=maribu a=maribu
### Contribution description
- Rename all `arduino_pinmap.h` to `arduino_iomap.h`
- An empty `arduino_pinmap.h` that just includes `arduino_iomap.h` is provided for backward compatibility
- Move all info from `arduino_board.h` into the new file as trivial macros, so that they can also be used outside of sketches
- The new name reflects the fact not just pin mappings, but also other I/O features such as PWMs are mapped
- Drop all `arduino_board.h`
- `arduino_board.h` and `arduino_iomap.h` now provide the exact same information, just in a different format
- a generic `arduino_board.h` is provided instead that just uses the info in `arduinio_iomap.h` and provides them in the format the code in `sys/arduino` expects it
- Add fine grained features to indicate for mappings
- availability of mappings for analog pins, DAC pins, PWM pins, UART devices, SPI/I2C buses to the corresponding RIOT identification can now be expressed:
- `arduino_pins`: `ARDUINO_PIN_0` etc. are available
- `arduino_analog`: `ARDUINO_A0` etc. are available
- `arduino_pwm`: `ARDUINO_PIN_13_PWM_DEV` etc. are available
- `arduino_dac`: `ARDUINO_DAC0` etc. are available
- `arduino_uart`: `ARDUINO_UART_D0D1` or similar are available
- `arduino_spi`: `ARDUINO_SPI_ISP` or similar are available
- `arduino_i2c`: `ARDUINO_I2C_UNO` or similar are available
- mechanical/electrical compatibility with specific form factors can now be expressed as features:
- `aruino_shield_nano`: Arduino NANO compatible headers
- `aruino_shield_uno`: Arduino UNO compatible headers
- `aruino_shield_mega`: Arduino MEGA compatible headers
- `aruino_shield_isp`: ISP header is available
This provides the groundwork to implement shield support as modules that can rely on the I/O mappings, rather than having to provide a configuration per board.
Co-authored-by: Marian Buschsieweke <[email protected]>
|
Build failed: |
|
Haven't seen that glitch in a while. I cannot say I missed it... bors retry |
|
bors retry |
|
Build succeeded! The publicly hosted instance of bors-ng is deprecated and will go away soon. If you want to self-host your own instance, instructions are here. If you want to switch to GitHub's built-in merge queue, visit their help page. |
|
🎉 thx! |
This was referenced Jun 28, 2023
bors bot
added a commit
that referenced
this pull request
Jul 20, 2023
19839: pkg/arduino_adafruit_sensor: fix dependencies r=maribu a=maribu ### Contribution description This fixes the dependencies of the `arduino_adafruit_sensor` package, which previously relied on the `arduino` feature. This feature no longer exists, as it was split into more fine granular features. However, the module should never have used that feature directly in the first place, but rather just use the arduino module. This in turn depends on the correct features. ### Testing procedure `tests/arduino_adafruit_sensor` should again be supported by boards that have the features required by the `arduino` module. ### Issues/PRs references Fallout of #19759 Co-authored-by: Marian Buschsieweke <[email protected]>
bors bot
added a commit
that referenced
this pull request
Jul 20, 2023
19840: pkg/arduino_adafruit_sensor: fix dependencies [backport 2023.07] r=benpicco a=maribu # Backport of #19839 ### Contribution description This fixes the dependencies of the `arduino_adafruit_sensor` package, which previously relied on the `arduino` feature. This feature no longer exists, as it was split into more fine granular features. However, the module should never have used that feature directly in the first place, but rather just use the arduino module. This in turn depends on the correct features. ### Testing procedure `tests/arduino_adafruit_sensor` should again be supported by boards that have the features required by the `arduino` module. ### Issues/PRs references Fallout of #19759 Co-authored-by: Marian Buschsieweke <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Contribution description
arduino_pinmap.htoarduino_iomap.harduino_pinmap.hthat just includesarduino_iomap.his provided for backward compatibilityarduino_board.hinto the new file as trivial macros, so that they can also be used outside of sketchesarduino_board.harduino_board.handarduino_iomap.hnow provide the exact same information, just in a different formatarduino_board.his provided instead that just uses the info inarduinio_iomap.hand provides them in the format the code insys/arduinoexpects itarduino_pins:ARDUINO_PIN_0etc. are availablearduino_analog:ARDUINO_A0etc. are availablearduino_pwm:ARDUINO_PIN_13_PWM_DEVetc. are availablearduino_dac:ARDUINO_DAC0etc. are availablearduino_uart:ARDUINO_UART_D0D1or similar are availablearduino_spi:ARDUINO_SPI_ISPor similar are availablearduino_i2c:ARDUINO_I2C_UNOor similar are availablearuino_shield_nano: Arduino NANO compatible headersaruino_shield_uno: Arduino UNO compatible headersaruino_shield_mega: Arduino MEGA compatible headersaruino_shield_isp: ISP header is availableThis provides the groundwork to implement shield support as modules that can rely on the I/O mappings, rather than having to provide a configuration per board.
Testing procedure
CI + lots of code review ...
In the long term the peripheral self testing shield will allow automatic testing for some of the I/O mappings for Arduino UNO compatible boards. But this PR would be required first for any soft of meaningful shield support in RIOT first.
Issues/PRs references
None