To avoid garbage on reconfiguring the UART console pins, e.g. in initialization of the `arduino` module, pins that are already configured as UART pins must not be initialized.
The TX line is set and temporarily configured as a pull-up open-drain output before configuring it as a push-pull output to avoid a several msec long LOW pulse resulting in some garbage.
Since PR #19100 it is possible to define:
- other pins for `UART_DEV(0)` than the default pins
- different `UART_DEV(0)` pins for the bootloader and RIOT
To allow correct reinitialization of the UART pins used by the bootloader as well as their usage for other purposes, the pin usage for the default UART0 pins and the UART pins used by the bootloader are reset to `_GPIO`. This is done in `uart_system_init` which has to be called earlier in the startup procedure.
The parameters for parity and stop bits was confused, resulting in
the following compilation error with GCC 12.2.0:
/home/maribu/Repos/software/RIOT/cpu/esp_common/periph/uart.c: In function '_uart_config':
/home/maribu/Repos/software/RIOT/cpu/esp_common/periph/uart.c:394:61: error: implicit conversion from 'uart_stop_bits_t' to 'uart_parity_t' -Werror=enum-conversion]
394 | if (_uart_set_mode(uart, _uarts[uart].data, _uarts[uart].stop,
| ~~~~~~~~~~~~^~~~~
/home/maribu/Repos/software/RIOT/cpu/esp_common/periph/uart.c:395:42: error: implicit conversion from 'uart_parity_t' to 'uart_stop_bits_t' -Werror=enum-conversion]
395 | _uarts[uart].parity) != UART_OK) {
| ~~~~~~~~~~~~^~~~~~~
cc1: all warnings being treated as errors
This swaps the parameters.
Fixed delay values are replaced by calculated delays measured in CPU cycles in I2C software implementation. The advantage is that for each ESP SoC only a clock calibration offset has to be specified. The delay measured in CPU cycles are then then derived from current CPU frequency for the given bus speed. The disadvantage is that the calculated delays are not as precise as the predefined fixed delays.
This commit changes periph/uart to use ESP-IDF API for ESP32x SoCs. Furthermore, the MCU_* conditionals are inverted so that they can be tested for ESP8266. In all other cases the MCU is any ESP32x SoC
On the ESP32 it is often not possible with the I2C software implementation to communicate with an AIP31068 based LCD module. Therefore, the I2C hardware implementation is enabled when the AIP31068 driver is used, but it is more buggy than stable. The timing of the two implementations seems to be almost identical. The only difference is that the hardware implementation clears the bus before each access by sending 10 clock pulses on the SCL line while SDA is LOW. Using the same mechanism during I2C initialization for the software implementation solves the communication problem with the AIP31068.
The same software implementation works reliably with the AIP31068 on the ESP8266.
The esp8266 CPU has actually two hardware UART peripherals. UART0 is
used by the boot ROM for flashing and serial output during boot,
typically at a baudrate of 74880 bps until the bootloader or application
sets the more standard 115200 baudrate. This UART0 device has two
possible pins for TXD, GPIO1 and GPIO2, which are both set to TXD by the
boot ROM. esp8266 modules will typically have GPIO1 labeled as the TX
pin, but it is possible to use GPIO2 for that purpose even while
flashing the device with esptool.py.
The second device, UART1, also has two options for TXD, GPIO2 and GPIO7,
and only one option for RXD, GPIO8. However, GPIO7 and GPIO8 are used
by the flash internally so those options are not very useful unless
maybe while running from IRAM with the flash disabled, for example for
a debugger over UART1.
This patch allows boards to override UART{0,1}_{R,T}XD in their
periph_conf.h to configure the uart selection. Defining UART1_TX will
make the UART_DEV(1) device available.
Tested with:
```CFLAGS='-DUART1_TXD=GPIO2' make -C tests/periph_uart BOARD=esp8266-esp-12x flash term```
* Connected one USB-UART to the standard GPIO1 and GPIO3 for flashing
and console. After flashing we see the manual test output at 115200
bps
* Connected a second USB-UART with RX to GPIO2 running at 74880.
Then run on the first console:
```
> init 1 74880
> send 1 hello
```
The word "hello" appears on the second UART connection.
Note that GPIO2 is used during boot for UART0's TX until the application
or bootloader set it to a regular GPIO, so some boot ROM messages at
74880 bps are visible. After running `init 1 74880` it is set to UART1's
TX.
In I2C, clock stretching occurs when the controller stops driving SCL
down but the peripheral continues to drive SCL down until the value of
SDA that is expected to be set by the peripheral is ready. This allows a
peripheral to communicate at a high speed but introduce a delay in the
response (like an ACK or read) in some specific situations. Not all I2C
peripherals require I2C stretching, and in many cases SCL is only an
input to these peripherals.
Clock stretching is the only situation where a peripheral may drive down
SCL, which technically makes SCL an open-drain with a pull-up like SDA.
However, if clock stretching is not needed, SCL can be configured as an
output removing the need for a pull-up and specially, allowing to use
as SCL GPIO pins that otherwise have a pull-down connected. In
particular, GPIO15 in the ESP8266 requires an external pull-down during
boot for the ESP8266 to boot from the flash.
This patch allows a board to define `I2C_CLOCK_STRETCH` to 0 to disable
clock stretching and allowing to use GPIO15 as SCL.
- Add `WORD_ALIGNED` attribute to potentially unaligned allocations
- Use intermediate cast to `uintptr_t` to silence false positives of
`-Wcast-align`
