For the other MCUs, we take the input register state instead of the
output register state when the pin is configured as input. Let's do
the same here, as this is a lot more useful and intuitive.
It turns out that the legacy GPIO API and GPIO LL may disagree on what
the GPIO base address is: GPIO LL will use the IOBUS as base address
no matter what, the legacy GPIO API will use the APB as base address
unless `periph_gpio_fast_read` is used.
If the APIs disagree, we need to do impedance matching.
This adds a delay between enabling the ADC and starting to sample
on the SAMD5x MCUs when the internal bandgap reference is used.
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
This changes the API of xfa from
XFA(array_name, prio) type element_name = INITIALIZER;
to
XFA(type, array_name, prio) element_name = INITIALIZER;
this allows forcing natural alignment of the type, fixing failing tests
on `native64`.
Since https://github.com/RIOT-OS/RIOT/pull/20935 gpio_write()
uses a `bool` instead of an `int`. This does the same treatment for
`gpio_read()`.
This does indeed add an instruction to `gpio_read()` implementations.
However, users caring about an instruction more are better served with
`gpio_ll_read()` anyway. And `gpio_read() == 1` is often seen in
newcomer's code, which would now work as expected.
This formats the code to improve readability and apply the coding
convention. This is a whitespace only change that will not change
generated binaries.
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 case both periph_gpio_irq and periph_gpio_ll_irq are used, the
periph_gpio_irq implementation now uses periph_gpio_ll_irq, so that
they can coexist.
clock.c: The MSP430 may need nop instructions after (and in some cases
even before) touching the global interrupt enable bit in the
status register. The assembler generates a warning when in
doubt. Those nops should not be needed in our cases, but maybe
it is better two waste flash for two instructions than having
to live with the warning.
cpu.c: drop unneeded include
The assumption that every MCU has this feature turned out wrong. Hence,
add a feature to allow testing for support of edge triggered IRQs on
both flanks.
The API was based on the assumption that GPIO ports are mapped in memory
sanely, so that a `GPIO_PORT(num)` macro would work allow for constant
folding when `num` is known and still be efficient when it is not.
Some MCUs, however, will need a look up tables to efficiently translate
GPIO port numbers to the port's base address. This will prevent the use
of such a `GPIO_PORT(num)` macro in constant initializers.
As a result, we rather provide `GPIO_PORT_0`, `GPIO_PORT_1`, etc. macros
for each GPIO port present (regardless of MCU naming scheme), as well as
`GPIO_PORT_A`, `GPIO_PORT_B`, etc. macros if (and only if) the MCU port
naming scheme uses letters rather than numbers.
These can be defined as macros to the peripheral base address even when
those are randomly mapped into the address space. In addition, a C
function `gpio_port()` replaces the role of the `GPIO_PORT()` and
`gpio_port_num()` the `GPIO_PORT_NUM()` macro. Those functions will
still be implemented as efficient as possible and will allow constant
folding where it was formerly possible. Hence, there is no downside for
MCUs with sane peripheral memory mapping, but it is highly beneficial
for the crazy ones.
There are also two benefits for the non-crazy MCUs:
1. We can now test for valid port numbers with `#ifdef GPIO_PORT_<NUM>`
- This directly benefits the test in `tests/periph/gpio_ll`, which
can now provide a valid GPIO port for each and every board
- Writing to invalid memory mapped I/O addresses was treated as
triggering undefined behavior by the compiler and used as a
optimization opportunity
2. We can now detect at compile time if the naming scheme of the MCU
uses letters or numbers, and produce more user friendly output.
- This is directly applied in the test app
