cpu/esp32: add periph_usbdev for ESP32-S2 and ESP32S3

[gschorcht]

Contribution description

This PR adds periph_usbdev driver for ESP32-S2 and ESP32-S3.

It is an alternative to PR #18592 for using ESP32x USB peripherals with RIOT's usbus modules. It does not make PR #18592 obsolete as the tinyUSB stack provides a complete host and device stack.

Please note:

• Since ESP32x SoCs integrate the same Synopsys DWC2 IP core as STM32 as USB peripherals, the driver is just a copy of cpu/stm32/periph/usbdev_otg.c, where the identifiers stm32_* and STM32_* have simply been replaced by esp32_* and ESP32_* respectively. Only the function _usbdev_init has been slightly changed.
• The file cpu/esp32/vendor/include/usbdev_esp32.h is just an excerpt of file stm32/cmsis/f7/include/stm32f767xx.h because the STM32F767xx uses the same Synopsys DWC2 IP core version and is therefore compatible with ESP32x SoCs.

Testing procedure

1. Flash tests/usbus_hid

   BOARD=esp32s3-devkit make -C tests/usbus_hid flash term
   

   Use the dmesg command and check the USB HID devices was found

   [1230033.363705] usb 1-2.4: USB disconnect, device number 91
   [1230033.625919] usb 1-2.4: new full-speed USB device number 92 using xhci_hcd
   [1230033.732624] usb 1-2.4: New USB device found, idVendor=1209, idProduct=7d01, bcdDevice= 1.00
   [1230033.732627] usb 1-2.4: New USB device strings: Mfr=3, Product=2, SerialNumber=4
   [1230033.732629] usb 1-2.4: Product: esp32s3-devkit
   [1230033.732630] usb 1-2.4: Manufacturer: RIOT-os.org
   [1230033.732631] usb 1-2.4: SerialNumber: A5894EECB420ECF1
   [1230033.739837] hid-generic 0003:1209:7D01.00D9: hiddev2,hidraw5: USB HID v1.10 Device [RIOT-os.org esp32s3-devkit] on usb-0000:00:14.0-2.4/input0

   and that there is a new /dev/hidrawX device to which you can write as root characters that are echoed in console window, for example:

   # echo -n "Hello" > /dev/hidraw5
   

   main(): This is RIOT! (Version: 2022.10-devel-619-gca66ff-cpu/esp32/periph_usbdev)
   RIOT USB HID echo test
   Write input to the hidraw device under /dev/hidrawX, and see if it gets echoed here
   USB_HID rx_cb: Test argument 
   Msg received via USB HID: 
   Hello
   

2. Flash tests/usbus_ecm

   BOARD=esp32s3-devkit make -C tests/usbus_hid flash term
   

   On the host computer, using tools such as ethtool must show the USB CDC ECM interface as link detected:

   # ethtool enp0s20u9u4
   Settings for enp0s20u9u4:
           Current message level: 0x00000007 (7)
                                  drv probe link
           Link detected: yes

   You should be able to ping the ESP32x node from the host and vice versa using the IPv6 address of the USB CDC ECM interface.

Issues/PRs references

[maribu]

Since ESP32x SoCs integrate the same Synopsys DWC2 IP core as STM32 as USB peripherals, the driver is just a copy of cpu/stm32/periph/usbdev_otg.c, where the identifiers stm32_* and STM32_* have simply been replaced by esp32_* and ESP32_* respectively. Only the function _usbdev_init has been slightly changed.

How about introducing a folder cpu/periph/synopsys/ and place the driver there?

[gschorcht]

Since ESP32x SoCs integrate the same Synopsys DWC2 IP core as STM32 as USB peripherals, the driver is just a copy of cpu/stm32/periph/usbdev_otg.c, where the identifiers stm32_* and STM32_* have simply been replaced by esp32_* and ESP32_* respectively. Only the function _usbdev_init has been slightly changed.

How about introducing a folder cpu/periph/synopsys/ and place the driver there?

Indeed, it already worked with some #ifdefs MCU_* for STM32 as well as ESP32. Probably it could also be used for EFM32 and GD32. According to tinyUSB, it also uses the DWC2 driver for these MCUs. But then it should have a more general namespace.

Wouldn't driver/synopsys_dwc2 be a better place for a driver?

The question is whether we should continue with this PR an separate drivers for now to support USB on the ESP32x SoC in the short term and de-duplicate the code later by merging them.

[benpicco]

How much work would it be to move this to a common place instead? Apart from clock setup, are there any esp32/stm32 specific changes to the code?

[gschorcht]

How much work would it be to move this to a common place instead?

Not very much. The most difficult problem will be to deal with the differences in the peripheral configuration. ESP32 needs only a small subset, in fact only the type of OTG controller and the peripheral address. Probably, we can use inheritance as for other data types like usbdev_t.

Apart from clock setup, are there any esp32/stm32 specific changes to the code?

No.

[benpicco]

This can be closed now, right?

[gschorcht]

Closed in favor of PR #18644