8000 Implement machine.USBDevice for ESP32-S3 · Issue #15564 · micropython/micropython · GitHub
[go: up one dir, main page]

Skip to content

Implement machine.USBDevice for ESP32-S3 #15564

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
tom709 opened this issue Jul 28, 2024 · 11 comments
Open

Implement machine.USBDevice for ESP32-S3 #15564

tom709 opened this issue Jul 28, 2024 · 11 comments
Labels
enhancement Feature requests, new feature implementations port-esp32

Comments

@tom709
Copy link
tom709 commented Jul 28, 2024

Description

The ESP32-S3 chip has excellent USB support built-in. Please implement machine.USBDevice for ESP32-S3.

Code Size

No response

Implementation

I hope the MicroPython maintainers or community will implement this feature

Code of Conduct

Yes, I agree

@tom709 tom709 added the enhancement Feature requests, new feature implementations label Jul 28, 2024
@andrewleech
Copy link
Contributor

For this to be possible we need to stop using the Espressif provided USB support and instead use the USB support code in micropython.

I've submitted such a change here, but it's a large change that will need more testing: #15108

Once that's complete then testing builds with the dynamic usb device support should be possible.

@projectgus
Copy link
Contributor

I'd also like to see this supported!

I realised that we might be able to do it another way, but locking the GIL for each of the USB callbacks. But that's also a lot of work, and I like the approach in your PR better.

@TomFahey
Copy link
TomFahey commented Oct 14, 2024

@andrewleech I noticed that your commits were merged last week, and so took the opportunity to compile a couple of micropython images for the Arduino Nano ESP32 and a Waveshare Pico S2.

I've only tested the use of basic USB CDC instantiation (using the
higher level micropython-lib usb-device drivers, which make use of machine.USBDevice) however so far everything has worked flawlessly.

Fantastic job and thank you very much for you efforts here!

@andrewleech
Copy link
Contributor

That's really interesting to hear @TomFahey did you just enable the runtime build config?

#define MICROPY_HW_ENABLE_USB_RUNTIME_DEVICE    (1) // Support machine.USBDevice

@TomFahey
Copy link
TomFahey commented Oct 15, 2024

Pretty much - I also had to add ${MICROPY_DIR}/shared/tinyusb/mp_usbd_runtime.c to

    list(APPEND MICROPY_SOURCE_TINYUSB
          ${TINYUSB_SRC}/tusb.c
          ${TINYUSB_SRC}/common/tusb_fifo.c
          ${TINYUSB_SRC}/device/usbd.c
          ${TINYUSB_SRC}/device/usbd_control.c
          ${TINYUSB_SRC}/class/cdc/cdc_device.c
          ${TINYUSB_SRC}/portable/synopsys/dwc2/dcd_dwc2.c
          ${MICROPY_DIR}/shared/tinyusb/mp_usbd.c
          ${MICROPY_DIR}/shared/tinyusb/mp_usbd_cdc.c
          ${MICROPY_DIR}/shared/tinyusb/mp_usbd_descriptor.c
          ${MICROPY_DIR}/shared/tinyusb/mp_usbd_runtime.c
      )

in the esp32_common.cmake file to get it to compile and also added

    #if MICROPY_HW_ENABLE_USB_RUNTIME_DEVICE
    mp_usbd_deinit();
    #endif

to the soft_reset_exit block in main.c, however I don't know if the latter change is necessary (I was basically just trying to mirror the main.c file in the rp2 port).

EDIT: The compiled firmware works without the change to main.c, but I gather the mp_usb_deinit() call is intended for deinitialising the dynamic usb drivers when performing a soft reset, so it is probably worth including, seeing as the RP2 port follows this behaviour.

@sebromero
Copy link
Contributor

Hi @TomFahey 👋 Would you mind sharing your build? I'd love to test HID support on the Arduino Nano ESP32.

@TomFahey
Copy link
TomFahey commented Oct 16, 2024

Sure, here's the .uf2 image, as well as the separate bootloader.bin, partition-table.bin and micropython.bin binaries. Just FYI, for the flash_args.txt file, for some reason it sets the 1.56MB micropython binary's memory address to 0xf70000 (16,187,392), which obviously doesn't leave enough space to write it in the 16MB flash memory - no clue why? I simply changed the offset to 0x10000 (app0), however, which allowed me to successfully flash the microcontroller and get the micropython interpreter up and running; I thought I'd leave the flash_args.txt file as is, however, just in case there's a good reason for those memory address offsets.

Arduino Nano ESP32.zip

@sebromero
Copy link
Contributor

I flashed the binaries using esptool.py write_flash --flash_mode dio --flash_freq 80m --flash_size 16MB 0x0 bootloader.bin 0x10000 micropython.bin 0x8000 partition-table.bin 0xe000 ota_data_initial.bin
and then ran the HID keyboard example from the usb-device-keyboard library.
Works beautifully ✨ Thanks everyone who contributed to enable USB device support on the S3 ❤️

@sebromero
Copy link
Contributor

If I interpret @dpgeorge's comment here correctly, the next step would be to create a PR that enables the runtime support by default. @TomFahey 's approach works fine for me, so maybe we can proceed with this? Or is there anything else needed from your point of view @andrewleech?

@andrewleech
Copy link
Contributor

Yep you're right, a PR with those changes is the next step!
I'd suggest adding the define next to the existing USB ones in mpconfigport.h surrounded by a #ifndef like many others in that file so boards can override it if needed.

@sebromero
Copy link
Contributor

I'd suggest adding the define next to the existing USB ones in mpconfigport.h surrounded by a #ifndef like many others in that file so boards can override it if needed.

Sounds good 👌 @TomFahey wanna do the honours given that you pretty much already have the changes locally? 🙏

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Feature requests, new feature implementations port-esp32
Projects
None yet
Development

No branches or pull requests

6 participants
0