stm32/usb: Add support for using TinyUSB stack. #15592
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #15592 +/- ##
=======================================
Coverage 98.54% 98.54%
=======================================
Files 169 169
Lines 21898 21898
=======================================
Hits 21579 21579
Misses 319 319 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Code size report: |
1b2bbff to
a8e3d9d
Compare
Yes, please do allow support for either the STM or TinyUSB stack. |
shared/runtime/pyexec.c
Outdated
| @@ -583,7 +583,7 @@ int pyexec_friendly_repl(void) { | |||
| for (;;) { | |||
| input_restart: | |||
|
|
|||
| #if MICROPY_HW_ENABLE_USB | |||
| #if MICROPY_HW_ENABLE_USB && 0 | |||
| if (usb_vcp_is_enabled()) { | |||
| // If the user gets to here and interrupts are disabled then | |||
| // they'll never see the prompt, traceback etc. The USB REPL needs | |||
There was a problem hiding this comment.
@dpgeorge This block in the shared pyexec code appears to be stm32 specific! Other ports use the MICROPY_HW_ENABLE_USBDEV define and don't define usb_vcp_is_enabled etc.
This little feature to re-enable any disabled interrupts once a device hits repl does sound convenient, would it be worth extending this to all ports? Or does this feel like something users haven't needed and should be removed?
There was a problem hiding this comment.
I reckon we can just remove this. It's pretty hacky and doesn't generalise well to other ports.
1964763 to
4c7f096
Compare
4c7f096 to
12ef683
Compare
12ef683 to
7b072e8
Compare
7b072e8 to
52a6912
Compare
100e19c to
02eb292
Compare
3864708 to
0f058f7
Compare
0f058f7 to
07b5638
Compare
07b5638 to
958eb7b
Compare
958eb7b to
162d4c7
Compare
Signed-off-by: Andrew Leech <[email protected]>
Signed-off-by: Andrew Leech <[email protected]>
Signed-off-by: Andrew Leech <[email protected]>
162d4c7 to
6aef189
Compare
| } | ||
|
|
||
|
|
||
| void pyb_usbd_init(void) { |
There was a problem hiding this comment.
This isn't needed for stm hal, adds code size.
| * @retval None | ||
| */ | ||
| void HAL_PCD_MspInit(PCD_HandleTypeDef *hpcd) { | ||
| void pyb_usbd_init_fs(void) { |
There was a problem hiding this comment.
make these static
Summary
This PR adapts the stm32 port to allow switching from STM USB stack to TinyUSB stack.
Using TinyUSB improves consistancy with other micropython ports and brings in the ability to use the runtime usb definition support recently added to other TinyUSB based ports.
TinyUSB can be enabled in a build with
#define MICROPY_HW_TINYUSB_STACK (1)It's also enabled by default with
MICROPY_PREVIEW_VERSION_2From the command line it can be enabled with:
make -C ports/stm32 BOARD=PYBV11 CFLAGS_EXTRA='-DMICROPY_HW_TINYUSB_STACK=1'Testing
Development and testing so far has been on the STM32WB55 and STM32F765
I've been more recently using and testing this in conjunction with shared/tinyusb: Add support for USB Network (NCM) interface. #16459 on the STM32F765 where the builtin CDC and NCM endpoints are both working very well.
I haven't yet done significant testing of dynamic / runtime usb devices.
Trade-offs and Alternatives
Currently the TinyUSB integration matches other ports for features, so CDC is enabled for repl use and machine.USBDevice support is available by default.
This means however the existing stm32 / pyb usb support has been removed, including pyb.USB_VCP and pyb.usb_mode.
Features like mass storage, hid and a second vcp could in theory be added via
machine.USBDevicehowever this hasn't been tested and is a breaking change for the stm32 port.TODO: test lightsleep behaviour / compared with #8304 (comment)