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.
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.
When the driver for the mpu9150 has been renamed to mpu9x50, the
corresponding macro in the MSB-IoT board was forgotten to be renamed
as well. This fixes the issue.
This PR sets the DMA configuration for the UART peripherals on the
stm32f4 boards to the undef value to disable the DMA. This to prevent
from accidentally configuring the DMA to stream 0 channel 0 when
enabling DMA.
There is no hardware limitation for custom boards based on STM32 to uses
SPI bus with signals coming from different PORT and alternate functions.
This patch allow alternate's function definition per pin basis, thus enable
the support of SPI bus signals routed on differents PORT.
Signed-off-by: Yannick Gicquel <ygicquel@gmail.com>
- Adjusted `#define`s to match the naming convention of `cc110x_params.h`
- Enable the `cc110x` module if `netdev_default` or `gnrc_netdev_default` is
used
- removed neccessity to define empty `DAC_NUMOF 0` for each STM
base board
- adapted all board configs to this
- joined stm32f2 to use common DAC driver
- improved code of DAC driver