is arduino interested in replacing the current USB stacks with one stack?

[Phillip Torrone]

hi arduino developer list,

we (adafruit) recently did a bunch of work to create an open source, cross-chip USB stack that will let anything with USB peripheral/host use the same USB CDC, HID, MIDI, MSD (etc) code. prior to this people usually hand-crafting a stack per device (based perhaps on the board support package from the vendor) or using a vendor-supplied stack that was not open source:
https://github.com/hathach/tinyusb

we're currently using this stack for nRF52840, SAMD21 and SAMD51 on CircuitPython as well as nRF52840 for Arduino. TinyUSB also has support for STM32F3 and STM32F4 as well as some popular LPCs.

we propose replacing the USB stack for Arduino with TinyUSB - this would make it a lot easier to add new chipsets, and open up the peripherals available. for example, mass storage which is an oft-requested but unavailable class. we'd start with ARM chips and skip AVR's for now. it's a significant task but the USB work is done, and this would make future-versions of ourselves happy when new chips come along.

please let us know if Arduino would be interested in replacing the current USB stacks with one stack.

cheers,
pt and team

[Adrian Godwin]

How far is the LUFA project useful in this direction ?

It seems to provide extensive class support but is very focused on AVR, and has its own infrastructure which perhaps makes it difficult to integrate with an arduino project.

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.

[PTS]

+100 for this. The current state of USB on Arduino is rather frustrating.

How exactly would you propose this transition will work? Is it backwards compatible to legacy code?

[Phillip Torrone]

> From: PTS <timo...@gmail.com>
> +100 for this. The current state of USB on Arduino is rather frustrating.
> How exactly would you propose this transition will work? Is it backwards compatible to legacy code?

we'd probably start with having a compile-time define on what stack to use (adding a menu selection to the boards menu) but given there's a good abstraction level for Serial/HID now, we'd like to stick to the API as close as possible, just the backend would be completely different.

>> From: Adrian Godwin <artg...@gmail.com>
>> How far is the LUFA project useful in this direction ?
>> It seems to provide extensive class support but is very focused on AVR, and has its own infrastructure which perhaps makes it difficult to integrate with an arduino project.

we aren't focused on AVRs so much, the ARM chips are where we think the biggest benefit is, but if someone would like to try adding LUFA to TinyUSB we'd absolutely welcome PR's. LUFA is well written so we think it would fit in nicely :)

cheers,
pt and team

[Andrew Kroll]

Or, you could use my already tested stack, with a ton of drivers...
Yes, it uses malloc, but does so in a way that isn't fatal.

Also works on AVR, larger ones, like 2560.

Already has HID-RAW, MIDI, USB-storage, and support for several USB serial bridges.

Native support for some ARM chips, and EHCI interfaces.

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.

--

Visit my github for awesome Arduino code @ https://github.com/xxxajk

[Roger Irwin]

On Wed, Apr 10, 2019 at 8:53 AM Andrew Kroll <xxx...@gmail.com> wrote:

Or, you could use my already tested stack, with a ton of drivers...

Add my 1C to this ;-)

[Paul Stoffregen]

On 4/9/19 11:53 PM, Andrew Kroll wrote:

Or, you could use my already tested stack, with a ton of drivers...

Which already tested stack is that Andrew?  The one which says "Pre-release" and "EXTREMELY ALPHA!" at the beginning of its readme file?

You've done a lot of truly excellent work.  I have personally read the source code of nearly all widely used Arduino libraries.  Your's really do stand out, on a technical level.

But if you ever want to develop a user base, words that drive humans away in what little documentation you do write, coupled with complex examples and an unusual project structure that almost nobody figures out how to install are not the path to widespread adoption of your software.

[Andrew Kroll]

The real reason it has the alpha tag/warning is because Oleg doesn't want to get swamped with support. Unusual only in the fact that I want to keep all of it in one place, and because I'm not sure if Arduino library manager can handle library dependencies. It's definitely not for the wild yet, but is for developers. Documentation never was my strong point, but if I run doxygen on it, you do indeed get documentation.