C preprocessor defines in non-function form are assumed by C2Rust to be
constant if they are an expression and not a statement; the LED_PORT was
the only place in the code where that was wrong, and led to compiler
errors due to the value not being constant.
Altering the internal macro to use function form sidesteps that issue.
The generally preferred alternative of using a `const` is unavailable in
this case because the dereferencing operator is already part of the
vendor header file cpu/stellaris_common/include/vendor/cortex-m4-def.h.
The changed macro is documented as required by doccheck. The doccheck
rule that grandfathered in the LED_PORT macro as allowed undocumented is
not removed because it is also used in other board.h files.
Some increase in binary size is expected due to one bug fix around the
VFS access where a zero-cost version would require threading
non-idiomatic nul-terminated strings through too many abstraction levels
to be practical.
This was previously limited to constfs due to [8], but now that that is
fixed, it can show its full potential of enumerating both directories
and mount points.
[8]: https://gitlab.com/etonomy/riot-wrappers/-/issues/8
This pulls in several updates for which there is no urgent need, but
also no good reason *not* to do them (especially as they may contain bug
fixes, even critical ones).
The read_csr macro returns the CSR value as a `unsigned long`. However,
the format specifier presently treats it as a `uint32_t`. This causes
a -Wformat error to be emitted by Clang 18:
cpu/riscv_common/irq_arch.c:149:49: error: format specifies type 'unsigned int'
but the argument has type 'unsigned long' [-Werror,-Wformat]
149 | printf(" mepc: 0x%" PRIx32 "\n", read_csr(mepc));
In all other tests we added a delay after writing to the output buffer
of GPIO A before expected the input buffer of GPIO B (connected to A)
to reflect the change, but not in test_switch_dir().
This adds the delay here as well to make the test more robust in regard
to GPIO peripherals that react not as fast as the CPU can query them.
It turns out that the feature to switch the GPIO direction quickly
is not only a way to emulate open drain / open source mode for less
sophisticated GPIO peripherals that do not natively support it.
It also enables tri-state output (push-pull high, push-pull low,
high impedance), which is useful e.g. for driven charlieplexed LEDs
quickly.
This changes the API by introducing a `gpio_ll_prepare_switch_dir()`
function that prepares the value used to identify which pins should
be switched to input or to output mode. This is useful for GPIO
peripherals in which the GPIO mode register does not allocate one bit
per pin (so that only the direction is given there), such as the one
for STM32. This allows an STM32 implementation in which preparing the
bitmask needed to modify the direction of pins is not trivial.
