Currently, spi_acquire() will always re-configure the SPI bus.
If the configuration did not change, this is entirely uneccecary
and makes SPI operations take longer than needed.
Instead, compare the current configuration with the new configuration
and skip the initialisation if it didn't change since the last call.
The RTC expects to be clocked from a 1kHz source.
Previously it would re-configure GCLK2 from 32kHz to 1kHz when used.
Since GCLK2 is also used by EIC, this would break external interrupts
in strange and unexpected ways.
Dedicate a 1kHz clock to it to avoid the damage.
From the data sheet:
> The COUNT register requires synchronization when reading.
> Disabling the synchronization will prevent reading valid
> values from the COUNT register.
Without this bit enabled, rtt_get_counter() will always return 0.
As analyzed in #12678 there are cases where different reports can be
generated for the different snips of the packet send via the `sock`.
To catch all errors generated by the stack, the sock has to subscribe
for all snips of the packet sent. If any of the snips reports an error
distinct from `GNRC_NETERR_SUCCESS` or the previous one, we report that
status instead of just the first we receive. This way we are ensured to
have the first error reported by the stack for the given packet.
IS_ACTIVE allows to evaluate macro definitions in non-preprocessor
expressions. It takes a macro that may be defined to 1 or not defined at
all and expands to 1 or 0 respectively.
ATmega128RFA1/ATmega256RFR2 do not have a unique CPU ID.
Use the RC oscillator callibration byte as an impromptu CPU ID and rely
on bootlader constants present on all ATmega families for the remaining
bytes.
This way we can provide a faux CPU ID on all ATmega MCUs and typical hobbyists
with no access to JTAG adapters or high voltage programmer capable of writing
the user signature have a good chance that the CPU IDs of their device do not collide.
This reverts commit cf01c743a8.
Adding an unexplained delay seemed wrong in the first place, but it fixed
the display on the MCB2388.
Turns out the display was erroneously operating in 8-bit mode due to the
uninitialized flag register.
Why the delay helped here I don't know.
But with #12634 fixing this, this hack is not needed anymore.
This converts the hard-coded UART driver to the new ways.
- allow the board to configure the RX & TX pins
- allow for more than one UART
- allow setting the baudrate
- implement poweron()/poweroff() functions
