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.
The `SWJ_CFG` field of the `AFIO_MAPR` register is write only and values
read are undefined (random). Hence, using `AFIO->MAPR |= mask;` to
enable flags can corrupt the state of the `SWJ_CFG` (configure it to
an unintended value).
Two helper functions have been introduced:
- `afio_mapr_read()` reads the value, but sanitizes the `SWJ_CFG` field
to zero
- `afio_mapr_write()` writes the given value, but applies the `SWJ_CFG`
configured by the board before writing.
Finally, the `nucleo-f103rb` and `bluepill*`/`blackpill*` boards have
been updated to no longer specify `STM32F1_DISABLE_JTAG`, as this
is handled by the `SWJ_CFG` setting (which defaults to disabling JTAG).
The peripheral configuration has been completely reworked to resolve
pin conflicts while provided as much of the peripherals as possible.
The changes include:
- Move `I2C_DEV(0)` from PB6/PB7 to PB8/PB9 to solve pin conflict with
`QDEC_DEV(2)`.
- Use pins PB0, PB1, PB4, and PB5 for PWM instead PA8, PA9, PA10, and
PA11
- PA9 and PA10 is in pin conflict with `UART_DEV(0)` which is used
for stdio with `stdio_uart`, PA8 was in conflict with
`QDEC_DEV(0)`, PA11 was in conflict with USB D-
- Use PB6, PB7 as `QDEC_DEV(0)` (previously `QDEC_DEV(2)`), as this is
the only completely conflict free setting
- Use PB4/PB5 instead of PA6/PA7 for QDEC_DEV(1)
- This fixes a pin conflict with `SPI_DEV(0)` MISO (and
`ADC_LINE(4)`)
- Only provide QDEC at PB4/PB5 when PWM is not used to avoid conflict
- Only provide QDEC at PA8/PA9 when UART is not used to avoid conflict
- Use SPI2 (PB15, PB14, PB13, PB12) as `SPI_DEV(0)` instead of SPI1,
use SPI1 (PA7, PA6, PA5, PA4) as `SPI_DEV(1)`
- Only provide `SPI_DEV(1)` if the ADC is not in used to resolve a
pin conflict
- Move PB0 and PB1 at the end of the ADC lines (previously
`ADC_LINE(6)` and `ADC_LINE(7)`, now `ADC_LINE(8)` and `ADC_LINE(9)`)
- Only provide them when PWM is not in use (to resolve pin conflict
with PWM)
- Also do not provide them for the Blackpill boards, which are
missing pins PB0 and PB1 on the headers
To make life of users easier, a Pinout diagram with the new
configuration was added.
Using `UART_DEV(0)` (UASRT1) for stdio allows to use the same TTL
adapter that is used for programming via `stm32flash` to be used for
serial, without re-wiring after flashing.
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.
stm32f1 periph_rtc implementation gets a 1s resolution by dividing
CLOCK_LSx by 32768. This only make sense if CLOCK_LSE is set,
otherwise CLOCK_LSI=~40000, which will lead to an imprecise rtc.
The Nucleo-F103RB comes with an internal SWD programmer/debugger. Thus, the JTAG
pins are not going to be used for debugging / programming anyway. The pins are
exposed on the headers, so allowing them to be used as GPIOs make a lot of
sense.
The Bluepill / Blackpill boards only expose the SWD pins on the debug header,
but the JTAG pins (not also used by SWD) are exposed on the GPIO pin headers.
Hence, exposing them as regular GPIOs seems to be a reasonable choice.
- Created new `bluepill-128kib` as 128KiB version of the `bluepill`
- Created new `blackpill-128kib` as 128KiB version of the `blackpill`
- Updated `openocd.cfg` to allow flashing 128KiB of ROM
