With https://github.com/RIOT-OS/RIOT/pull/14224 the idle thread became
optional, so the main thread can have either 1 or 2 as PID, depending
if the idle thread is included or not. As this might also change in the
future, it is probably the best to just expect any number.
- Make use of the fact that gpio_init_af() does not need prior call to
gpio_init() for all STM32 families anymore and drop call to gpio_init()
- Initialize the UART periph first, before initializing the pins
- While uninitialized, the UART periph will send signal LOW to TXD. This
results in a start bit being picked up by the other side.
- Instead, we do not connect the UART periph to the pins until it is
initialized, so that the TXD level will already be HIGH when the pins
are attached.
- This results in no more garbage being send during initialization
- Do not set an intermediate mode, prepare correct mode settings in a temporary
variable
- Consistently enabled the GPIO periph in gpio_init_af()
- Previously, STM32 F1 did not require a separate call to gpio_init() prior
to a call of gpio_init_af(), but other STM32 families did
- Now, gpio_init_af() can be used without gpio_init() consistently
- STM32 F1: Do not touch ODR for non input pins
- For input pins, this enables / disabled pull up resistors. For outputs,
this register should remain untouched (according to API doc)
- Add libstdcpp feature to indicate a platform is providing a libstdc++
implementation ready for use
- The existing cpp feature now only indicates a working C++ toolchain without
libstdc++. (E.g. still useful for the Arduino compatibility layer.)
- Added libstdcpp as required feature were needed
- Added some documentation on C++ on RIOT
Replace `volatile` access to pm_blocker by guarding the accesses with
`irq_disable()` ... `irq_restore()`.
`volatile` does only guarantee that no compiler optimizations are performed on
a variable access, but does not provide atomic access. E.g. on systems with
a memory bus of less than 32 bit, the access to pm_blocker cannot be done
with a single CPU instruction. Thus, resorting to disabling IRQs is the easiest
and most portable way to actually achieve atomic access.
