-
Notifications
You must be signed in to change notification settings - Fork 2.1k
pkg/tinyusb: add tinyUSB as package #18592
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @gschorcht That's a pretty nice package !
I took a quick glance at it. I think I have a supported ST boards somewhere in my basement so I should be able to run some tests. But I cannot test on ESP side.
I'll dive further when I'll run some tests.
@gschorcht I give this PR a try with a |
Hm, I have tested it with a |
If it sucks here, the Synopsys DWC2 core seems to be not available at this point. I will check. |
@dylad Could you please check the
or
in function RIOT/pkg/tinyusb/hw/hw_stm32.c Lines 36 to 37 in 369f8c0
|
@gschorcht
just after the Got this output:
|
I've replaced |
I've made some progress with: |
Ah, I see, the peripheral configuration includes |
c21869f
to
8cdd96b
Compare
* ... | ||
* // initialize the tinyUSB stack including used peripherals and | ||
* // start the tinyUSB thread | ||
* tinyusb_setup(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this not auto-init'ed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you mind if we add this in a followup PR ?
This PR is already in good shape.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this not auto-init'ed?
Good question. If it is possible to create a thread during the auto-init and the scheduler is already running, it should be possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have a local commit that implements auto-initialization. It only needed a few changes:
pkg/tinyusb/Makefile.dep | 2 ++
pkg/tinyusb/contrib/tinyusb.c | 13 +++++++++++++
pkg/tinyusb/doc.txt | 6 ++++--
sys/auto_init/include/auto_init_priorities.h | 6 ++++++
tests/pkg_tinyusb_cdc_msc/main.c | 4 ----
5 files changed, 25 insertions(+), 6 deletions(-)
Should I provide it or should we add this in a followup PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See commit 1879a1c.
* | ||
* tinyUSB is an open-source cross-platform USB Host/Device stack for | ||
* embedded systems. | ||
* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How does tinyUSB relate to the usbus native RIOT modules? Is it (or can it be) used on top of the existing usbus? Or is it mutually exclusive? (E.g. because the set of supported hardware is distinct -- and what when one gains support for a device another has?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tinyUSB and USBUS are mutually exclusive.
tinyUSB provides both the USB stack and the lowlevel driver whereas usbus depends on periph_usbdev
FWICT, tinyUSB has more features and support more lowlevel peripherals than usbus/periph_usbdev but as @gschorcht pointed out here, it looks like tinyUSB uses more RAM/ROM than our stack.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How does tinyUSB relate to the usbus native RIOT modules?
As @dylad said, tinyUSB includes the USB host and device stack as well as device drivers for a variety of platforms. Also, the stack supports many more device classes than usbus
.
Is it (or can it be) used on top of the existing usbus? Or is it mutually exclusive? (E.g. because the set of supported hardware is distinct -- and what when one gains support for a device another has?)
tinyUSB device driver use the same hardware as periph_usbdev
. So either tinyUSB or usbus
can be used. But, theoretically, it should be possible to implement an interface to use the tinyUSB stack on-top of a periph_usbdev
device driver or to use usbus
on top of a tinyUSB device driver. This would require to map the interface of tinyUSB device drivers to the periph_usbdev
interface.
FEATURES_CONFLICT_MSG += "Only one standard C library can be used." | ||
|
||
FEATURES_CONFLICT += periph_gpio_irq:periph_gpio_ll_irq | ||
FEATURES_CONFLICT_MSG += "Only one GPIO IRQ implementation can be used" | ||
FEATURES_CONFLICT_MSG += "Only one GPIO IRQ implementation can be used." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this belong to another PR ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, it's such a small change that improves readability. Since we are touching the file anyway, I thought we could improve it. Without this small change, the message looks like this:
Rationale: Only one standard C library can be used Only one GPIO IRQ implementation can be used Package tinyUSB is not yet compatible with periph_usbdev.
That is, the message is completely unstructured.
With this small change, the message looks like this:
Rationale: Only one standard C library can be used. Only one GPIO IRQ implementation can be used. Package tinyUSB is not yet compatible with periph_usbdev.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is, the problem is that all messages are simply strung together without punctuation.
Got tinyUSB working on my SAME54-XPRO 😍 |
I got USB OTG HS with external ULPI PHY working on |
Now that I am experimenting with the USB OTG HS port with UPLI HS PHY on the board The reason is that tinyUSB needs one driver for the USB device stack according to the API defined in To use bothe the USB OTG FS and the USB OTG HS port for the device stack, we have to change the logic. Defining |
Ah, now I got it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Last comment on my side. Feels free to squash at the same time.
#define TINYUSB_TUH_RHPORT 0 | ||
#endif | ||
|
||
#define HSE_VALUE CLOCK_HSE |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this define here ?
Could you add a comment about that if it's really needed please ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this define here ?
Hm, it could be a leftover from trying to use tinyusb/src/portable/st/synopsys/dcd_synopsys.c
as a driver. I have removed it. Let's see if Murdock is happy. If so, it was just a leftover. If not, Murdock will tell us why.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed, Murdock has the answer ! This was not a leftover.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, it's not really to me, why this is required for this one board only.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah ok, I see. stm32f723e-disco
is the only board that uses a STM32F723 for which the CMSIS defines USB_HS_PHYC
, that is, the internal UTMI HS PHY is used. Interesting, this will help us to support also UTMI in RIOT's Synopsys DWC2 driver for OTG HS interfaces (PR #18679).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BTW, according to the schematic, the stm32f723e-disco
is also a board with USB OTG FS as well as USB OTG HS connector. The internal UTMI HS PHY is used with the USB OTG HS interface.
The current state looks good to me, we can prepare something later to enable support for both controllers at the same time. |
Some error checks had to be removed to get `make info-boards-supported` working.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK.
Code looks good, tested work on stm32f429i-disc1
and I trust @gschorcht testing on ESP32.
Here we go. |
@dylad Thanks for reviewing, testing and merging. |
Contribution description
This PR adds tinyUSB open-source cross-platform USB Host/Device stack for embedded systems as package.
The initial intention was to add USB support for ESP32-S2 and ESP32-S3 since the tinyUSB stack includes a hardware driver for these ESP32x SoCs. The ESP-IDF also uses tinyUSB for USB support, but integrates tinyUSB. Instead of using the tinyUSB from ESP-IDF, this PR adds tinyUSB as a package to be able to use it for other platforms like STM32 and nRF. STM32 support is also provided by this PR.
Testing procedure
Compile and flash the test application
tests/pkg_tinyusb_cdc_msc
.It should be possible to use any STM32 board that also supports feature
periph_usbdev
This application uses the tinyUSB device stack to emulate a mass storage device (MSC) with a communication interface (CDC).
Once the application is flashed, the device should be mounted when it is
connected to a host. That is,
TinyUSB MSC
in the operating system and/dev/ttyACM0
on Linux.It should then be possible
The test application uses LED0, if present, to indicate the status of the device by blinking at different frequencies.
Issues/PRs references