In Arduino IDE the on-board LED pin is defined by macro `LED_BUILTIN`. It is used whenever the LED is controlled. To make it easier to use Arduino sketches as they are, `LED_BUILTIN` is defined by using @ref ARDUINO_LED as defined by the board.
This allows using the arduino_pwm feature (which is translated into a
module) without the arduino module; e.g. for only using the Arduino
I/O mapping but not the Arduino API.
- 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.
If module `arduino_serial_stdio` is used and `ARDUINO_UART_DEV` is `UART_UNDEF`, the STDIO is used for `Serial`. It requires that the used `stdio` backend implements `stdio_available`.
Not all boards that provide a Arduino pin layout break out all GPIOs. A good example are Adafruit `feather-m0` boards. GPIOs that are not broken out have to be defined as `GPIO_UNDEF` to preserve the Arduino pin layout. However, GPIO functions lead to a complete system lock on `feather-m0` boards if a pin is used that is defined as `GPIO_UNDEF`. Therefore, at least an assert should blow up in this case.
This fixes building tests/pkg_arduino_sdi_12 for the hifive1b board.
The problem is, in build/pkg/arduino_api/api/Common.h millis is defined
within an extern "C" block. While in sys/arduino/include/arduino.hpp it
was not.
This fixes the error:
$ BOARD=arduino-mega2560 make -C tests/pkg_arduino_sdi_12/
[...]
[...]/RIOT/build/pkg/arduino_sdi_12/src/SDI12.cpp:379:7: error: ‘interrupts’ was not declared in this scope
There is no clear reason why this should be configurable and causes an abstraction of USEMODULE.
The true reason is to make Kconfig easier but it seems having a variable in USEMODULE is a bit strange.
To make it possible to use an Arduino library, a new pseudomodule arduino_lib is introduced. This pseudomodule enables implicitly module arduino but avoids that a sketch is required or generated and compiled. Thus, it is possible to compile and use a package or directory with some source files from an Arduino library in RIOT applications.
Arduino is always enabling C++11 support, so sketches and libs are depending on
it. Every C++ compiler has been enabling C++11 by default for some years now.
Still, Ubuntu's avr-gcc is so **horrible** out of date, that it is not enabled
there. As a simple work around, -std=c++11 is now passed to the C++ compiler if
Arduino is used.
