This fixes a race in `LED<NUM>_TOGGLE`, which is a read-copy-write
operation. Any access to a GPIO pin on the same GPIO port that
happens concurrently could result in data corruption. Using the
GPIO LL API, which is thread-safe, fixes the issue.
Note: The used GPIO LL functions will work even in when the GPIO LL
module is not used.
This gets rid of a long list of boards with network interfaces and
instead let's boards (or MCUs with peripheral network interfaces)
provide the netif feature.
The apps that before used the long list are not depending on the
feature instead (in case of the default example, this is an
optional dependency).
Co-authored-by: mguetschow <mikolai.guetschow@tu-dresden.de>
Co-authored-by: mewen.berthelot <mewen.berthelot@orange.com>
The macro `ARDUINO_SPI_D11D12D13` is used to refer to the SPI bus
on the pins D11/D12/D13 on Arduino UNO compatible boards. For all
Nucleo64 boards this is `SPI_DEV(0)`, but for this board `SPI_DEV(0)`
is internally connected to the radio. Instead `SPI_DEV(1)` is connected
to the correct pins. This provides the macro explicitly in
`periph_conf.h`, which takes preference over the fallback in
`boards/common/nucleo64` when provided.
- 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.
- most were trivial
- missing group close or open
- extra space
- no doxygen comment
- name commad might open an implicit group
this hould also be implicit cosed but does not happen somtimes
- crazy: internal declared groups have to be closed internal
Let boards only define the port and pin number of each LEDs. The common
definitions in `stm32_leds.h` will provide `LED<x>_ON`, `LED<x>_OFF`,
`LED<x>_TOGGLE`, `LED<x>_PIN`, `LED<x>_MASK` and `LED<x>_PORT`.
In addition to code de-duplication, this also makes it easier to use
LEDs in GPIO LL, which can be beneficial for super low overhead
debugging output - e.g. when a bug is timing sensitive and `DEBUG()`
would spent to much time for stdio to reproduce a bug.
