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.
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()`.
This adds the features
- periph_gpio_ll_input_pull_down:
To indicate support for input mode with internal pull down
- periph_gpio_ll_input_pull_keep:
To indicate support for input mode with internal resistor
pulling towards current level
- periph_gpio_ll_input_pull_up:
To indicate support for input mode with internal pull up
- periph_gpio_ll_disconnect:
To indicate a GPIO can be disconnected
- periph_gpio_ll_open_drain:
To indicate support for open drain mode
- periph_gpio_ll_open_drain_pull_up:
To indicate support for open drain mode with internal pull up
- periph_gpio_ll_open_source:
To indicate support for open source mode
- periph_gpio_ll_open_source_pull_down:
To indicate support for open source mode with internal pull down
- 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.
