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
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>
- nRF51: Use `uart_conf_t` for consistency with nRF52
- nRF52832: Use UARTE (UART with EasyDMA) over UART (without DMA), as
done for all other nRF52 family members
- use `UARTE_PRESENT` to detect whether an UARTE can be used, rather
than family names
nRF52833 has POWER_MAINREGSTATUS_MAINREGSTATUS_High, but no POWER->DCDCEN0
register.
This breaks all builds on this MCU.
Fix the ifdef to fix the build.
The internal DC/DC converter is more efficient compared to the LDO
regulator. The downside of the DC/DC converter is that it requires an
external inductor to be present on the board. Enabling the DC/DC
converter is guarded with NRF5X_ENABLE_DCDC, this macro must be defined
if the DC/DC converter is to be enabled.
The driver is claiming it is needed for IPv6 / 6LoWPAN support, which
is not true (the long address is never used for NRFMIN in fact) and
this assumption actually leads to an assertion when compiled as with
the `gnrc_border_router` example.
Instead of using `weak` function definitions, this PR handles
default implementations using `PROVIDES_x` defines, allowing
for cpus/pm realted modules to use their own implementations.
- added vendor header files for nrf52840
- added config for nrf52840
- added additional isr vectors for the nrf52840
- enabled port 1 in GPIO driver
- adapted periph drivers to cope with GPIO driver changes
- adapted the GPIO config of the I2C driver for the nrf51
