This has the following advantages:
- faster and leaner when C11 atomics are not efficient (e.g. on LLVM
this is almost always the case, as LLVM will only use efficient
atomics if it doesn't has to bail out to library calls even for
exotic things)
- Even for GCC e.g. on the nucleo-f429zi this safes 72 B of .text
for examples/filesystem despite runtime checks added for
over- and underflow
- less pain in the ass for C++ and rust users, as both C++ and
c2rust are incompatible with C11 atomics
- adds test for overflow of the open file counter for more robust
operation
- adds `assumes()` so that underflows are detected in non-production
code
This commit changes the link about supported boards in the README from the wiki page to the RIOT-OS website.
Since the wiki is not up to date.
See also [this pull request](https://github.com/RIOT-OS/riot-os.org/pull/109/files) that fixed the same link on the website.
This patch adds calls to be able to peek at items other than just the
oldest item in a cib based FIFO. It also adds an "unsafe" peek to match
the existing "unsafe" put and get functions.
The CoAP thread stack size needs to be the same as the main
thread stack size to accommodate the EDHOC stack requirements.
This was lost when moving to the common CoAP server code.
The `Makefile.ci` was intended to be read and generated by command
line utilities and the contents should look exactly like this:
```
BOARD_INSUFFICIENT_MEMORY += \
board_a \
board_b \
... \
#
```
No fancy schmancy, no `include`, no nothing. This fixes the format.
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.
When it is difficult to navigate a function, it is overdue to split
it up :D
Also, no need to test for feature `gpio_ll_irq` in `test_irq()` *and*
before calling `test_irq()`.
- 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>
Also the LF is display inside the [...].
Now it is more obvious what characters came in on the RX port of the UART.
Here is an example:
2024-01-20 20:57:41,368 # send 1 ati
2024-01-20 20:57:41,368 # UART_DEV(1) TX: ati
> 2024-01-20 20:57:41,393 # Success: UART_DEV(1) RX: [ati\r\r\n]
2024-01-20 20:57:41,398 # Success: UART_DEV(1) RX: [SARA-N310-00X-00\r\n]
2024-01-20 20:57:41,399 # Success: UART_DEV(1) RX: [\r\n]
2024-01-20 20:57:41,399 # Success: UART_DEV(1) RX: [OK\r\n]
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
The CC2538-CC2592-DK is one of the few readily available and
affordable boards featuring a legacy CC2538 MCU. This should make
maintaining RIOT support for that legacy MCU more affordable :-)
