18756: drivers/usbdev_synopsys_dwc2: add EFM32 support r=chrysn a=gschorcht
### Contribution description
This PR provides the changes for the Synopsys USB OTG IP core DWC2 driver for EFM32 MCUs. It also provides the changes of the board definition for `stk3600` and `stk3700` for testing.
### Testing procedure
`tests/usbus_hid` should work on the EFM32 boards `stk3600` (EFM32LG family) and `stk3700` (EFM32GG family).
It is already tested for a `sltb009a` board (EFM32GG12 family).
### Issues/PRs references
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
The `tinyusb_device` feature introduced with PR #18689 has to be moved from `common/arduino-zero` definition to the `arduino-zero` definition because the common `arduino-zero` features are also used by `wemos-zero` which uses `highlevel_stdio` feature via the `stdio_cdc_acm` module.
weact-f4xcx boards have only a single USB-C connector that is used for `highlevel_stdio` via USBUS CDC ACM so that it conflicts with tinyUSB for the moment.
The `channels` member should not be set to the number of hardware
channels *n*, but to *n* - 1 instead. The last channel is implicitly
used in `timer_read()`. Hence out of *n* hardware channels, only *n* - 1
are available to the application.
This fixes a bug introduced by 4d02e15247
which incorrectly set the channel number to *n* rather than to
*n* - 1.
- All nRF52 timers support 32 bit mode, so use that
- All nRF52 timers support at least 4 channels, the timers NRF_TIMER3
and NRF_TIMER4 even support 6 channels.
- Add a warning that `TIMER_DEV(1)` is used by the IEEE 802.15.4 driver
The peripheral configuration has been completely reworked to resolve
pin conflicts while provided as much of the peripherals as possible.
The changes include:
- Move `I2C_DEV(0)` from PB6/PB7 to PB8/PB9 to solve pin conflict with
`QDEC_DEV(2)`.
- Use pins PB0, PB1, PB4, and PB5 for PWM instead PA8, PA9, PA10, and
PA11
- PA9 and PA10 is in pin conflict with `UART_DEV(0)` which is used
for stdio with `stdio_uart`, PA8 was in conflict with
`QDEC_DEV(0)`, PA11 was in conflict with USB D-
- Use PB6, PB7 as `QDEC_DEV(0)` (previously `QDEC_DEV(2)`), as this is
the only completely conflict free setting
- Use PB4/PB5 instead of PA6/PA7 for QDEC_DEV(1)
- This fixes a pin conflict with `SPI_DEV(0)` MISO (and
`ADC_LINE(4)`)
- Only provide QDEC at PB4/PB5 when PWM is not used to avoid conflict
- Only provide QDEC at PA8/PA9 when UART is not used to avoid conflict
- Use SPI2 (PB15, PB14, PB13, PB12) as `SPI_DEV(0)` instead of SPI1,
use SPI1 (PA7, PA6, PA5, PA4) as `SPI_DEV(1)`
- Only provide `SPI_DEV(1)` if the ADC is not in used to resolve a
pin conflict
- Move PB0 and PB1 at the end of the ADC lines (previously
`ADC_LINE(6)` and `ADC_LINE(7)`, now `ADC_LINE(8)` and `ADC_LINE(9)`)
- Only provide them when PWM is not in use (to resolve pin conflict
with PWM)
- Also do not provide them for the Blackpill boards, which are
missing pins PB0 and PB1 on the headers
To make life of users easier, a Pinout diagram with the new
configuration was added.
The `fs` in the file name means that on-chip FS PHY is configured for USB OTG HS. The file is renamed to `cfg_usb_otg_hs_phy_fs.h`
- to clarify that USB OTG HS is just configured with PHY FS and not HS and FS,
- to allow a configuration of USB OTG FS and HS in one file called `cfg_usb_otg_hs_fs.h` or whatever, and
- to allow a configuration of USB OTG HS with ULPI PHY in a file called `cfg_usb_otg_hs_phy_ulpi.h`.
f
- most were trivial
- missing group close or open
- extra space
- no doxygen comment
- name commad might open an implicit group
this hould also be implicit cosed but does not happen somtimes
- crazy: internal declared groups have to be closed internal
The inverted and non-inverted `LED<num>_ON` and `LED<num>_OFF` macros
are swapped. This didn't reveal in testing as the
`LED<num>_IS_INVERTED` macros where not properly evaluated, due to a
typo in the check. This fixes both.
Using `UART_DEV(0)` (UASRT1) for stdio allows to use the same TTL
adapter that is used for programming via `stm32flash` to be used for
serial, without re-wiring after flashing.
Let boards only define the port and pin number of each LEDs. The common
definitions in `stm32_leds.h` will provide `LED<x>_ON`, `LED<x>_OFF`,
`LED<x>_TOGGLE`, `LED<x>_PIN`, `LED<x>_MASK` and `LED<x>_PORT`.
In addition to code de-duplication, this also makes it easier to use
LEDs in GPIO LL, which can be beneficial for super low overhead
debugging output - e.g. when a bug is timing sensitive and `DEBUG()`
would spent to much time for stdio to reproduce a bug.
Only default to uniflash as default programmer if UNIFLASH_PATH is
set. If this isn't the case, `make flash` fails complaining about
missing `UNIFLASH_PATH` anyway.
This introduces KCONFIG_BOARD_CONFIG and KCONFIG_CPU_CONFIG variable for
boards and CPUs (including common directories) to add default
configuration files to be merged. The current approach, as it uses
Makefile.features, would include boards first, not allowing them to
override CPU configurations.
The peripheral register addresses are fixed, properly aligned addresses. Storing
them as uintptr_t makes live easier when casting them to helper structs, as no
intermediate cast to uintptr_t is needed to silence -Wcast-align.
The module silabs_pic depends on the feature periph_i2c. However, the
dependency resolution just selected the module implementing that
feature which bypasses feature checks.
This fixes the following error:
$ BOARD=arduino-mega2560 make -C tests/pkg_arduino_sdi_12/
[...]
[...]/RIOT/build/pkg/arduino_sdi_12/src/SDI12_boards.cpp:35:16: error: ‘preSDI12_TCCR2B’ defined but not used [-Werror=unused-variable
35 | static uint8_t preSDI12_TCCR2B;
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.
When flashing the ESP8266 with the flash tool it is possible to connect
RTS to the reset line and DTR to GPIO0 to automatically reboot the
device into flash mode and then reboot the device again into normal
mode.
pyterm leaves these two signals unset unless we specify a --set-rts=0 or
1, and the value of these lines would depend on the UART driver.
This patch explicitly sets RTS and DTR to 0 (high level) in the
Makefile.include config so `make term` releases the reset line,
otherwise the device may be left in reset mode after pyterm starts.
