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
- `gpio_ll_toggle()` now is race-free
- avoid using a look up table but branch to the two different registers
in the `gpio_ll*()` functions
- in most cases the GPIO port is a compile time constant and the
dead branch is eliminated by the optimizer, making this vastly
more efficient
- some MCUs do only have a single port, in which case
`GPIO_PORT_NUM(port)` is known to return `0` even if `port` is
not known, resulting in one of the branch being eliminated as
dead branch no matter what
- in case it really is unknown at compile time which port to work
on, the branch can still be implemented efficiently by the
compiler e.g. using a conditional move; likely more efficient
than fetching a value from the look up table.
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>
19450: cpu/esp32: fix compilation issues with GCC 12.2 r=benpicco a=gschorcht
### Contribution description
This PR provides the changes in `cpu/esp32` and `cpu/esp_common` to fix the compilation issues with GCC v12.2. It is required as the first step in the preparation of the upgrade to ESP-IDF version 5.1.
**Please note**: Insead of fixing the ESP-IDF 4.4 code itself by a big bunch of patches to fix the compilation problems with GCC v12.2, it temporarily disables some warnings. The reason is that the ESP-IDF 5.1 requires GCC v12.2 and should be fixed for this compiler version by the vendor.
### Testing procedure
Green CI
The change were already tested with all ESP-specific modules like `esp_now`, `esp_wifi`, `esp_spi` and `esp_ble` for all supported ESP platforms.
### Issues/PRs references
Prerequisite for https://github.com/RIOT-OS/riotdocker/pull/227
Fixes issue #19421
19476: native/syscalls: rename real_clock_gettime to clock_gettime r=benpicco a=Teufelchen1
### Contribution description
When compiling RIOT for native using a recent LLVM and enabling ASAN, one might encounter "Duplicated symbol".
This is due to a name clash with `real_clock_gettime()` in compiler-rt from [LLVM](f50246da65), I renamed RIOTs `real_clock_gettime` and just default to the posix function `clock_gettime`. The wrapper existed, most likely, for consistency only.
(The best solution would probably to convince the LLVM folks to declare their symbol as `static` and refactor a bit)
### Testing procedure
Passing CI should be enough.
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Teufelchen1 <bennet.blischke@haw-hamburg.de>
Since the USB OTG FIFO sizes are partly defined in 32-bit words and partly in bytes, the documentation of the of the USB OTG FIFO size definitions is extended by the respective unit.
19079: cpu/esp32: add periph_flashpage support r=kaspar030 a=gschorcht
### Contribution description
This PR provides the `periph_flashpage` support for ESP32x SoCs.
For byte-aligned read access to constant data in the flash, the MMU of all ESP32x SoCs allows to map a certain number of 64 kByte pages of the flash into the data address space of the CPU. This address space is called DROM. Normally the whole DROM address space is assigned to the section `.rodata`. The default flash layout used by all ESP32x SoCs is:
| Address in Flash | Content |
|:-----------------------|:-----------|
| `0x0000` or `0x1000` | bootloader |
| `0x8000` | parition table |
| `0x9000` | `nvs` parition with WiFi data |
| `0xf000` | `phy_init` partition with RF data |
| `0x10000` | `factory` partition with the app image |
The factory partition consists of a number of 64 kByte pages for the sections `.text`, `.rodata`, `.bss` and others. The `.text` and `rodata` sections are page-aligned and are simply mapped into the instruction address space (IROM) and the data address space (DROM), respectively. All other sections are loaded into RAM.
If the `periph_flashpage` module is used, the `periph_flashpage` driver
- decreases the size of the `.rodata` section in DROM address space by `CONFIG_ESP_FLASHPAGE_CAPACITY`,
- adds a section `.flashpage.writable` of size `CONFIG_ESP_FLASHPAGE_CAPACITY` at the end of DROM address space that is mapped into data address space of the CPU,
- reserves a region of size `CONFIG_ESP_FLASHPAGE_CAPACITY` starting from `0x10000` in front of the image partition `factory` and
- moves the image partition `factory` by `CONFIG_ESP_FLASHPAGE_CAPACITY` to address `0x10000 + CONFIG_ESP_FLASHPAGE_CAPACITY`.
The new flash layout is then:
| Address in Flash | Content |
|:-----------------------|:-----------|
| `0x0000` or `0x1000` | bootloader |
| `0x8000` | parition table |
| `0x9000` | `nvs` parition with WiFi data |
| `0xf000` | `phy_init` partition with RF data |
| `0x10000` | flashpage region |
| `0x10000 + CONFIG_ESP_FLASHPAGE_CAPACITY` | `factory` partition with the app image |
This guarantees that the flash pages are not overwritten if a new app image with changed size is flashed. `CONFIG_ESP_FLASHPAGE_CAPACITY` has to be a multiple of 64 kBytes.
~The PR includes PR #19077 and PR #19078 for the moment to be compilable.~
### Testing procedure
The following tests should pass.
```
USEMODULE='esp_log_startup ps shell_cmds_default' BOARD=esp32-wroom-32 make -j8 -C tests/periph_flashpage flash term
```
```
USEMODULE='esp_log_startup ps shell_cmds_default' BOARD=esp32-wroom-32 make -j8 -C tests/mtd_flashpage flash term
```
### Issues/PRs references
Depends on PR #19077
Depends on PR #19078
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
18752: nanocoap_sock: deprecate nanocoap_get() r=benpicco a=benpicco
19100: cpu/esp_common: allow configuration of UART0 r=benpicco a=gschorcht
### Contribution description
This PR
- fixes the issue for ESP32 SoCs that UART0 signals can't be routed to arbitrary GPIOs and
- allows the configuration of the UART device used by the bootloader.
The UART interface and its configuration used by the STDIO are defined in RIOT using the define `STDIO_UART_DEV` and the configuration of the corresponding UART device in `periph_conf.h`.
However, the bootloader compiled directly in ESP-IDF uses its own definitions `CONFIG_ESP_CONSOLE_UART_*` for the UART configuration. To be able to use a consistent UART configuration in RIOT and the bootloader, e.g. to see the output of the 2nd stage bootloader, these `CONFIG_ESP_CONSOLE_UART_*` can be defined via a set of KConfig variables in RIOT (not yet implemented in Kconfig):
- `CONSOLE_CONFIG_UART_NUM` defines the UART device to be used by the bootloader and by `STDIO_UART_DEV`
- `CONSOLE_CONFIG_UART_RX` and `CONSOLE_CONFIG_UART_TX` define the GPIOs to be used by the bootloader and should be the GPIOs as defined in `periph_conf.h` for the corresponding UART device.
### Testing procedure
Any ESP32 node should still work with `stdio_uart` and the default configuration. To test an alternative configuration, use
```
CFLAGS='-DUART1_TXD=5 -DUART1_RXD=4 -DCONFIG_CONSOLE_UART_NUM=1 -DCONFIG_CONSOLE_UART_TX=5 -DCONFIG_CONSOLE_UART_RX=4' USEMODULE=esp_log_startup BOARD=esp32-wroom-32 make -C tests/shell flash
```
The bootloader output and the STDIO should be routed to UART1 at GPIO4 and GPIO5.
### Issues/PRs references
Prerequisite for PR ##18863
19104: tests/periph_uart: only exclude STDIO_UART_DEV if stdio_uart is used r=benpicco a=benpicco
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de>
Using the vendor `memory.ld.in` instead of a static `memory.ld`, from which the actual used `memory.ld` is generated with the C preprocessor, allows to use the configuration in `sdkconfig.h` as well as Kconfig to use a custom memory layout. For example, it is no longer necessary to maintain different `memory.ld` files for the ESP32 BLE module, since the memory layout is now defined from the values of the configuration.
Since `esp_can.h` is included by main `cpu/esp32/include/periph_cpu.h` after the include of the specific `periph_cpu_$(CPU_FAM)`, it is not necessary to include `esp_can.h` in each specific `periph_cpu_$(CPU_FAM)`.
When using Bluetooth LE, the former UART interrupt number 5 is occupied by the ESP32 Bluetooth Controller. Therefore, another interrupt number has to be used for UART.
This define does not belong to the defines in `sdkconfig_*.h` that are used for the ESP-IDF SDK. It is therefore moved to the corresponding `periph_cpu_*.h` file.
