-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
boards,sys/arduino: major clean up #19759
Conversation
b783a36
to
63d4fd7
Compare
c906367
to
e89e40a
Compare
@kfessel I split the |
- 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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good cleanup PR:
- improves organisation
- readability
- completeness
maribu ran some tests, i trust his testing (no one will have all boards)
->
bors merge |
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 <marian.buschsieweke@posteo.net>
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! |
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 <marian.buschsieweke@posteo.net>
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 <marian.buschsieweke@posteo.net>
Contribution description
arduino_pinmap.h
toarduino_iomap.h
arduino_pinmap.h
that just includesarduino_iomap.h
is provided for backward compatibilityarduino_board.h
into the new file as trivial macros, so that they can also be used outside of sketchesarduino_board.h
arduino_board.h
andarduino_iomap.h
now provide the exact same information, just in a different formatarduino_board.h
is provided instead that just uses the info inarduinio_iomap.h
and provides them in the format the code insys/arduino
expects itarduino_pins
:ARDUINO_PIN_0
etc. are availablearduino_analog
:ARDUINO_A0
etc. are availablearduino_pwm
:ARDUINO_PIN_13_PWM_DEV
etc. are availablearduino_dac
:ARDUINO_DAC0
etc. are availablearduino_uart
:ARDUINO_UART_D0D1
or similar are availablearduino_spi
:ARDUINO_SPI_ISP
or similar are availablearduino_i2c
:ARDUINO_I2C_UNO
or 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