This pulls in embedded-nal 0.7 implementations, and (on both crates)
alterations that decouple riot-wrappers from riot-sys and simplify build
system integration, and do away with the need for passing
RIOT_USEMODULE.
The constants BIG_ENDIAN etc. were not consistently defined. This
bug was not caught by the unit tests, as the preprocessor would
treat undefined macros as being `0` in numeric comparisons, hence
the following test did select the correct implementation:
```C
#if BYTE_ORDER == LITTLE_ENDIAN
/* correct implementation for all currently supported boards */
#endif
```
This adds now an explicit test to the unit tests to ensure that the
magic numbers are consistently the correct values. Hence, this bug
should no longer be able to sneak in.
Co-authored-by: Teufelchen <9516484+Teufelchen1@users.noreply.github.com>
Back when specific control of the Rust version used with RIOT was
needed, CARGO_CHANNEL was added to explicitly set the Rust version with
consideration for CI special cases.
Rust's mechansims of selecting a toolchain can be used instead now.
- Move common code for USART (shared SPI / UART peripheral) to its
own file and allow sharing the USART peripheral to provide both
UART and SPI in round-robin fashion.
- Configure both UART and SPI bus via a `struct` in the board's
`periph_conf.h`
- this allows allocating the two UARTs as needed by the use case
- since both USARTs signals have a fixed connection to a single
GPIO, most configuration is moved to the CPU
- the board now only needs to decide which bus is provided by
which USART
Note: Sharing an USART used as UART requires cooperation from the app:
- If the UART is used in TX-only mode (no RX callback), the driver
will release the USART while not sending
- If the UART is used to also receive, the application needs to power
the UART down while not expecting something to send. An
`spi_acquire()` will be blocked while the UART is powered up.
The documentation on the state `GPIO_DISCONNECT` was a bit vague. The
API doc said it should disconnect the GPIO from all peripherals, the
test also tested them for being electrically disconnected.
The documentation in both the test and the API is extended to point out
that a GPIO indeed SHOULD be in high impedance state, but that user
MUST NOT expect that this requested is honored by every implementation
and for every GPIO pin.
In the test it is also pointed out that failing the test for a GPIO
in the `GPIO_DISCONNECT` state being electrically disconnected is for
some pins expected, and that the test should be just run again with
different GPIOs. The test intentionally tests for a feature not provided
by every GPIO pin rather than warning on a failure: The effort to just
flash and run the test again with different GPIOs is relatively low, but
it does confirm correct behavior of the API.
When using level triggered IRQs, a new IRQ flag may already have been
set while the IRQ callback is executed. Hence, we cannot just toggle
the output, but rather should drive it low/high for a level trigger on
high/low.
Also test `gpio_ll_query_conf()` for the disconnected state as well.
The default pin config is only a place holder anyway. But if it is
invalid at least on AVR most of the firmware is considered unreachable.
This updates the default GPIO config to something that should look
plausible to the compiler for all MCUs supporting GPIO LL, so that
ROM and RAM size in the CI start making sense.
Printing the newline after the state was printed is not optional.
This also moves the call to `gpio_ll_print_conf()` and `puts("")` to
a static function to safe enough ROM so that this still can be flashed
on `nucleo-l011k4`.
This commit optimizes the `gpio_conf_t` type in the following
regards:
- The "base" `gpio_conf_t` is stripped from members that only some
platforms support, e.g. drive strength, slew rate, and disabling of
the Schmitt Trigger are no longer universally available but
platform-specific extensions
- The `gpio_conf_t` is now crammed into a bit-field that is 8 bit or
16 bit wide. This allows for storing lots of them e.g. in
`driver_foo_params_t` or `uart_conf_t` etc.
- A `union` of the `struct` with bit-field members and a `bits` is used
to allow accessing all bits in a simple C statement and to ensure
alignment for efficient handling of the type
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
This application uses `soft_uart` to bit-bang the name of a number of
configured GPIO pins via said pins at 9600 Bd. This way attaching an
USB UART bridge to one pin at a time easily reveals which MCU GPIO
pin a given pin on a board corresponds to. This is useful when no
schematic and no silkscreen labeling is available, or when the
information is misleading or outright incorrect (looking at the
E180-ZG120B-TB).
Reverts the type changes for the array size variables, as `size_t` is needed
in the function calls `fib_get_next_hop` and `fib_get_destination_set`.
Fixes 475a55136a
