The tramp assembly was missing a `.note.GNU-stack` section,
meaning the compiler was forced to assume that we require
an executable stack.
Fix this by adding the necessary section.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
The underlying peripheral can only read from RAM. This uses the
existing infrastructure (already needed to work around the lack of a
hardware support for I2C_NOSTART) to unconditionally copy any to-be-sent
data into RAM.
- 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.
