Since https://github.com/RIOT-OS/RIOT/pull/20935 gpio_write()
uses a `bool` instead of an `int`. This does the same treatment for
`gpio_read()`.
This does indeed add an instruction to `gpio_read()` implementations.
However, users caring about an instruction more are better served with
`gpio_ll_read()` anyway. And `gpio_read() == 1` is often seen in
newcomer's code, which would now work as expected.
This adds the board specification of the Adafruit Metro M4 Express [1].
The significance of this board is that it is compatible with both
classical SPI Arduino Shields using the ISP header for SPI
(such as `shield_w5100`) and more recent shields using D11/D12/D13 as
SPI (such as `shield_llcc68`).
[1]: https://learn.adafruit.com/adafruit-metro-m4-express-featuring-atsamd51/overview
If the timer at the head of a ztimer clock's timer list is re-scheduled
(ztimer_set() called on an already set timer) and the timer is no longer
at the head after being re-scheduled, clock-ops->set() is never called
from inside ztimer_set(), and the underlying timer is left with an ISR
scheduled to expire at the timer's old time. The intended behavior is
that the clock's lower level timer should always be set to expire at the
time of the clocks head timer.
This patch changes ztimer_set() to call _ztimer_update(), which sets the
lower level timer according to the current list of timers, rather than
setting the timer directly inside of ztimer_set().
Some calls to `coap_build_hdr()` were done with the target buffer for
the header and the source buffer for the token overlapping:
They reuse the buffer that held the request to assemble the response in.
We cannot use `memcpy()` in this case to copy the token into the target
buffer, as source and destination would (fully) overlap.
This commit makes reusing the request buffer for the response a special
case: `memcpy()` is only used to copy the token if source and
destination address of the token differ.
An alternative fix would have been to use `memmove()` unconditionally.
But `memmove()` does not make any assumption about the layout of target
and source buffer, while we know that the token either will already be
at the right position (when reusing the request buffer for the response)
or be in a non-overlapping buffer (when generating a fresh token). This
approach is more efficient than `memmove()`.
