Skip to content
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

[USB] Features request list #687

Open
8 tasks
fpistm opened this issue Oct 8, 2019 · 37 comments
Open
8 tasks

[USB] Features request list #687

fpistm opened this issue Oct 8, 2019 · 37 comments
Labels
enhancement New feature or request

Comments

@fpistm
Copy link
Member

fpistm commented Oct 8, 2019

This issue aims to list all USB requests:

@senceryazici
Copy link

Like i've mentioned in #817 i'm looking foward for USB Host implementation, spesifically ACM VCP implementation. I basically need to create virtual serial port and talk to device through that.

Also, when the library is implemented I'll be happy to share my project as an example for the library maybe ?
Thank you

matthijskooijman added a commit to 3devo/Arduino_Core_STM32 that referenced this issue Jan 22, 2020
This adds support for the DFU runtime protocol, which allows resetting
into the bootloader using a DFU command. This allows e.g. dfu-util to
handle the complete firmware upload, including the needed reset.

This consists of a number of changes:
 - An extra interface is added to the USB configuration descriptor. This
   descriptor has two parts (interface descriptor and functional
   descriptor) which together indicate to a host that this device
   supports DFU.
 - Control packets to this new interface are detected by the CDC code an
   forwarded to a new USBD_DFU_Runtime_Control() function.
 - This new function handles the DFU GET_STATE, GET_STATUS and
   DFU_DETACH commands. The former are optional, but simple enough, the
   latter is mandatory and handles resetting into the bootloader.
 - The CDC device descriptor is changed to become a composite device
   (CDC and DFU). This allows operating systems (in particular Windows,
   Linux did not really need this) to identify two different subdevices,
   and install different drivers for each (on Windows, this is serusb
   for the CDC part and WinUSB/libusb for the DFU part). Without this,
   dfu-util on Windows could not access the DFU commands when the serial
   driver was loaded.

   Because the CDC functionality already exposes two interfaces (which
   together form a single serial port), an IAD (Interface Association
   Descriptor) is inserted before these interfaces to group them
   together in a single subdevice. No IAD is needed for the DFU
   interface, since it is just a single interface.

   To become a composite device, the device class must be changed from
   CDC to a composite device class. This was originally class 0/0/0, but
   together with the IAD, a new EF/2/1 deviceclass was also introduced,
   which is used now.

Note that this only adds descriptors and a command handler on the
default control endpoint, so no extra (scarce) endpoints are used by
this, just a bit of memory.

This commit is still a bit rough, because:
 - The DFU descriptors and code are now pulled in directly by the CDC
   code (and HID is not supported yet). Ideally, there should be some
   kind of pluggable USB library where different interfaces can be
   registered independent of each other (see also
   stm32duino#687).
 - The interface number is hardcoded in the DFU descriptor.
 - The reset to bootloader happens immediately, while it might be better
   to wait a short while to allow the current USB transaction to
   complete.
 - The DFU attributes in the descriptor are hardcoded (while they should
   probably match the values exposed by the bootloader, so probably be
   defined by boards.txt).
 - DFU support is unconditionally advertised, while not all boards might
   support DFU.
matthijskooijman added a commit to 3devo/Arduino_Core_STM32 that referenced this issue Jan 23, 2020
This adds support for the DFU runtime protocol, which allows resetting
into the bootloader using a DFU command. This allows e.g. dfu-util to
handle the complete firmware upload, including the needed reset.

This consists of a number of changes:
 - An extra interface is added to the USB configuration descriptor. This
   descriptor has two parts (interface descriptor and functional
   descriptor) which together indicate to a host that this device
   supports DFU.
 - Control packets to this new interface are detected by the CDC code an
   forwarded to a new USBD_DFU_Runtime_Control() function.
 - This new function handles the DFU GET_STATE, GET_STATUS and
   DFU_DETACH commands. The former are optional, but simple enough, the
   latter is mandatory and handles resetting into the bootloader.
 - The CDC device descriptor is changed to become a composite device
   (CDC and DFU). This allows operating systems (in particular Windows,
   Linux did not really need this) to identify two different subdevices,
   and install different drivers for each (on Windows, this is serusb
   for the CDC part and WinUSB/libusb for the DFU part). Without this,
   dfu-util on Windows could not access the DFU commands when the serial
   driver was loaded.

   Because the CDC functionality already exposes two interfaces (which
   together form a single serial port), an IAD (Interface Association
   Descriptor) is inserted before these interfaces to group them
   together in a single subdevice. No IAD is needed for the DFU
   interface, since it is just a single interface.

   To become a composite device, the device class must be changed from
   CDC to a composite device class. This was originally class 0/0/0, but
   together with the IAD, a new EF/2/1 deviceclass was also introduced,
   which is used now.

Note that this only adds descriptors and a command handler on the
default control endpoint, so no extra (scarce) endpoints are used by
this, just a bit of memory.

This commit is still a bit rough, because:
 - The DFU descriptors and code are now pulled in directly by the CDC
   code (and HID is not supported yet). Ideally, there should be some
   kind of pluggable USB library where different interfaces can be
   registered independent of each other (see also
   stm32duino#687).
 - The interface number is hardcoded in the DFU descriptor.
 - The reset to bootloader happens immediately, while it might be better
   to wait a short while to allow the current USB transaction to
   complete.
 - The DFU attributes in the descriptor are hardcoded (while they should
   probably match the values exposed by the bootloader, so probably be
   defined by boards.txt).
 - DFU support is unconditionally advertised, while not all boards might
   support DFU.
matthijskooijman added a commit to 3devo/Arduino_Core_STM32 that referenced this issue Jan 23, 2020
This adds support for the DFU runtime protocol, which allows resetting
into the bootloader using a DFU command. This allows e.g. dfu-util to
handle the complete firmware upload, including the needed reset.

This consists of a number of changes:
 - An extra interface is added to the USB configuration descriptor. This
   descriptor has two parts (interface descriptor and functional
   descriptor) which together indicate to a host that this device
   supports DFU.
 - Control packets to this new interface are detected by the CDC code an
   forwarded to a new USBD_DFU_Runtime_Control() function.
 - This new function handles the DFU GET_STATE, GET_STATUS and
   DFU_DETACH commands. The former are optional, but simple enough, the
   latter is mandatory and handles resetting into the bootloader.
 - The CDC device descriptor is changed to become a composite device
   (CDC and DFU). This allows operating systems (in particular Windows,
   Linux did not really need this) to identify two different subdevices,
   and install different drivers for each (on Windows, this is serusb
   for the CDC part and WinUSB/libusb for the DFU part). Without this,
   dfu-util on Windows could not access the DFU commands when the serial
   driver was loaded.

   Because the CDC functionality already exposes two interfaces (which
   together form a single serial port), an IAD (Interface Association
   Descriptor) is inserted before these interfaces to group them
   together in a single subdevice. No IAD is needed for the DFU
   interface, since it is just a single interface.

   To become a composite device, the device class must be changed from
   CDC to a composite device class. This was originally class 0/0/0, but
   together with the IAD, a new EF/2/1 deviceclass was also introduced,
   which is used now.

Note that this only adds descriptors and a command handler on the
default control endpoint, so no extra (scarce) endpoints are used by
this, just a bit of memory.

This commit is still a bit rough, because:
 - The DFU descriptors and code are now pulled in directly by the CDC
   code (and HID is not supported yet). Ideally, there should be some
   kind of pluggable USB library where different interfaces can be
   registered independent of each other (see also
   stm32duino#687).
 - The interface number is hardcoded in the DFU descriptor.
 - The reset to bootloader happens immediately, while it might be better
   to wait a short while to allow the current USB transaction to
   complete.
 - DFU support is unconditionally advertised, while not all boards might
   support DFU.
@oofus
Copy link

oofus commented Apr 8, 2020

Is there any progress on implementing PlugableUSB ? Is it even going to happen ?

@fpistm
Copy link
Member Author

fpistm commented Apr 8, 2020

Hi @oofus ,
Time is always the missing ingredients. So, currently, there is no progress on this.
Any contribution are welcome 😉

@oofus
Copy link

oofus commented Apr 11, 2020

Hi @fpistm
Thanks for the answer, at least I know the current status now.

Using and implementing are two quite different things. Just being willing to "give it a go" shouldn't be the criteria by which you pass an interview. You don't want any of my code near the core libraries !!!

Cheers

@HamidSaffari
Copy link

HamidSaffari commented Jun 4, 2020

Hi there.
Would you tell us where we can find some examples of that USB Middleware library.
Or write us one example code like read/write from a mass strong host device by using the MSC lib.
even for STM32CubeIDE so we can start porting it for Arduino.
Also is there any way that we use the Arm Mbed APIs with Arduino_Core_STM32 core?
Here is USBMSD API and functions for the mbed.

@HelloDB
Copy link

HelloDB commented Jun 24, 2020

Thank you for your work. Can you provide an example of keyboard that can be used in BIOS environment

@fpistm
Copy link
Member Author

fpistm commented Jun 25, 2020

Thank you for your work. Can you provide an example of keyboard that can be used in BIOS environment

Hi and welcome.
There is already a HID Kbd example. Don't know if it can work in BIOS environment.

@HelloDB
Copy link

HelloDB commented Jun 26, 2020

Hi, I tested the keyboard in BIOS environment. It works well, but I can't find an example of AbsoluteMouse. I'm trying to modify the Mouse library

@fpistm
Copy link
Member Author

fpistm commented Jun 26, 2020

Fine.
For absolute mouse, I never tried.
I guess you will have to modify the library.

@fpistm
Copy link
Member Author

fpistm commented Jun 26, 2020

In fact it seems it will requires more dev as currently the mouse only send the relative move.
There is no get report. What is your goal? get the absolute position or send it ?

@HelloDB
Copy link

HelloDB commented Jun 26, 2020

I want to make a remote mouse, sending absolute coordinate data is easier to control it than using relative coordinate data

@HelloDB
Copy link

HelloDB commented Jun 26, 2020

In fact it seems it will requires more dev as currently the mouse only send the relative move.
There is no get report. What is your goal? get the absolute position or send it ?

I generate the mouse position in the webpage, send it to ESP32 through the server and then send it to STM32, and then STM32 controls the mouse movement of another computer

@HelloDB
Copy link

HelloDB commented Jun 26, 2020

I added moveTo(uint16_t x, uint16_t y, uint8_t wheel) and modified HID_MOUSE_ReportDesc HID_MOUSE_REPORT_DESC_SIZE and still cannot control the mouse

matthijskooijman added a commit to 3devo/Arduino_Core_STM32 that referenced this issue Sep 3, 2020
This adds support for the DFU runtime protocol, which allows resetting
into the bootloader using a DFU command. This allows e.g. dfu-util to
handle the complete firmware upload, including the needed reset.

This consists of a number of changes:
 - An extra interface is added to the USB configuration descriptor. This
   descriptor has two parts (interface descriptor and functional
   descriptor) which together indicate to a host that this device
   supports DFU.
 - Control packets to this new interface are detected by the CDC code an
   forwarded to a new USBD_DFU_Runtime_Control() function.
 - This new function handles the DFU GET_STATE, GET_STATUS and
   DFU_DETACH commands. The former are optional, but simple enough, the
   latter is mandatory and handles resetting into the bootloader.
 - The CDC device descriptor is changed to become a composite device
   (CDC and DFU). This allows operating systems (in particular Windows,
   Linux did not really need this) to identify two different subdevices,
   and install different drivers for each (on Windows, this is serusb
   for the CDC part and WinUSB/libusb for the DFU part). Without this,
   dfu-util on Windows could not access the DFU commands when the serial
   driver was loaded.

   Because the CDC functionality already exposes two interfaces (which
   together form a single serial port), an IAD (Interface Association
   Descriptor) is inserted before these interfaces to group them
   together in a single subdevice. No IAD is needed for the DFU
   interface, since it is just a single interface.

   To become a composite device, the device class must be changed from
   CDC to a composite device class. This was originally class 0/0/0, but
   together with the IAD, a new EF/2/1 deviceclass was also introduced,
   which is used now.

Note that this only adds descriptors and a command handler on the
default control endpoint, so no extra (scarce) endpoints are used by
this, just a bit of memory.

This commit is still a bit rough, because:
 - The DFU descriptors and code are now pulled in directly by the CDC
   code (and HID is not supported yet). Ideally, there should be some
   kind of pluggable USB library where different interfaces can be
   registered independent of each other (see also
   stm32duino#687).
 - The interface number is hardcoded in the DFU descriptor.
 - The reset to bootloader happens immediately, while it might be better
   to wait a short while to allow the current USB transaction to
   complete.
 - DFU support is unconditionally advertised, while not all boards might
   support DFU.
fpistm pushed a commit to fpistm/Arduino_Core_STM32 that referenced this issue Sep 17, 2020
This adds support for the DFU runtime protocol, which allows resetting
into the bootloader using a DFU command. This allows e.g. dfu-util to
handle the complete firmware upload, including the needed reset.

This consists of a number of changes:
 - An extra interface is added to the USB configuration descriptor. This
   descriptor has two parts (interface descriptor and functional
   descriptor) which together indicate to a host that this device
   supports DFU.
 - Control packets to this new interface are detected by the CDC code an
   forwarded to a new USBD_DFU_Runtime_Control() function.
 - This new function handles the DFU GET_STATE, GET_STATUS and
   DFU_DETACH commands. The former are optional, but simple enough, the
   latter is mandatory and handles resetting into the bootloader.
 - The CDC device descriptor is changed to become a composite device
   (CDC and DFU). This allows operating systems (in particular Windows,
   Linux did not really need this) to identify two different subdevices,
   and install different drivers for each (on Windows, this is serusb
   for the CDC part and WinUSB/libusb for the DFU part). Without this,
   dfu-util on Windows could not access the DFU commands when the serial
   driver was loaded.

   Because the CDC functionality already exposes two interfaces (which
   together form a single serial port), an IAD (Interface Association
   Descriptor) is inserted before these interfaces to group them
   together in a single subdevice. No IAD is needed for the DFU
   interface, since it is just a single interface.

   To become a composite device, the device class must be changed from
   CDC to a composite device class. This was originally class 0/0/0, but
   together with the IAD, a new EF/2/1 deviceclass was also introduced,
   which is used now.

Note that this only adds descriptors and a command handler on the
default control endpoint, so no extra (scarce) endpoints are used by
this, just a bit of memory.

This commit is still a bit rough, because:
 - The DFU descriptors and code are now pulled in directly by the CDC
   code (and HID is not supported yet). Ideally, there should be some
   kind of pluggable USB library where different interfaces can be
   registered independent of each other (see also
   stm32duino#687).
 - The interface number is hardcoded in the DFU descriptor.
 - The reset to bootloader happens immediately, while it might be better
   to wait a short while to allow the current USB transaction to
   complete.
 - DFU support is unconditionally advertised, while not all boards might
   support DFU.
fpistm pushed a commit to fpistm/Arduino_Core_STM32 that referenced this issue Sep 17, 2020
This adds support for the DFU runtime protocol, which allows resetting
into the bootloader using a DFU command. This allows e.g. dfu-util to
handle the complete firmware upload, including the needed reset.

This consists of a number of changes:
 - An extra interface is added to the USB configuration descriptor. This
   descriptor has two parts (interface descriptor and functional
   descriptor) which together indicate to a host that this device
   supports DFU.
 - Control packets to this new interface are detected by the CDC code an
   forwarded to a new USBD_DFU_Runtime_Control() function.
 - This new function handles the DFU GET_STATE, GET_STATUS and
   DFU_DETACH commands. The former are optional, but simple enough, the
   latter is mandatory and handles resetting into the bootloader.
 - The CDC device descriptor is changed to become a composite device
   (CDC and DFU). This allows operating systems (in particular Windows,
   Linux did not really need this) to identify two different subdevices,
   and install different drivers for each (on Windows, this is serusb
   for the CDC part and WinUSB/libusb for the DFU part). Without this,
   dfu-util on Windows could not access the DFU commands when the serial
   driver was loaded.

   Because the CDC functionality already exposes two interfaces (which
   together form a single serial port), an IAD (Interface Association
   Descriptor) is inserted before these interfaces to group them
   together in a single subdevice. No IAD is needed for the DFU
   interface, since it is just a single interface.

   To become a composite device, the device class must be changed from
   CDC to a composite device class. This was originally class 0/0/0, but
   together with the IAD, a new EF/2/1 deviceclass was also introduced,
   which is used now.

Note that this only adds descriptors and a command handler on the
default control endpoint, so no extra (scarce) endpoints are used by
this, just a bit of memory.

This commit is still a bit rough, because:
 - The DFU descriptors and code are now pulled in directly by the CDC
   code (and HID is not supported yet). Ideally, there should be some
   kind of pluggable USB library where different interfaces can be
   registered independent of each other (see also
   stm32duino#687).
 - The interface number is hardcoded in the DFU descriptor.
 - The reset to bootloader happens immediately, while it might be better
   to wait a short while to allow the current USB transaction to
   complete.
 - DFU support is unconditionally advertised, while not all boards might
   support DFU.
fpistm pushed a commit to fpistm/Arduino_Core_STM32 that referenced this issue Sep 17, 2020
This adds support for the DFU runtime protocol, which allows resetting
into the bootloader using a DFU command. This allows e.g. dfu-util to
handle the complete firmware upload, including the needed reset.

This consists of a number of changes:
 - An extra interface is added to the USB configuration descriptor. This
   descriptor has two parts (interface descriptor and functional
   descriptor) which together indicate to a host that this device
   supports DFU.
 - Control packets to this new interface are detected by the CDC code an
   forwarded to a new USBD_DFU_Runtime_Control() function.
 - This new function handles the DFU GET_STATE, GET_STATUS and
   DFU_DETACH commands. The former are optional, but simple enough, the
   latter is mandatory and handles resetting into the bootloader.
 - The CDC device descriptor is changed to become a composite device
   (CDC and DFU). This allows operating systems (in particular Windows,
   Linux did not really need this) to identify two different subdevices,
   and install different drivers for each (on Windows, this is serusb
   for the CDC part and WinUSB/libusb for the DFU part). Without this,
   dfu-util on Windows could not access the DFU commands when the serial
   driver was loaded.

   Because the CDC functionality already exposes two interfaces (which
   together form a single serial port), an IAD (Interface Association
   Descriptor) is inserted before these interfaces to group them
   together in a single subdevice. No IAD is needed for the DFU
   interface, since it is just a single interface.

   To become a composite device, the device class must be changed from
   CDC to a composite device class. This was originally class 0/0/0, but
   together with the IAD, a new EF/2/1 deviceclass was also introduced,
   which is used now.

Note that this only adds descriptors and a command handler on the
default control endpoint, so no extra (scarce) endpoints are used by
this, just a bit of memory.

This commit is still a bit rough, because:
 - The DFU descriptors and code are now pulled in directly by the CDC
   code (and HID is not supported yet). Ideally, there should be some
   kind of pluggable USB library where different interfaces can be
   registered independent of each other (see also
   stm32duino#687).
 - The interface number is hardcoded in the DFU descriptor.
 - The reset to bootloader happens immediately, while it might be better
   to wait a short while to allow the current USB transaction to
   complete.
 - DFU support is unconditionally advertised, while not all boards might
   support DFU.
fpistm pushed a commit to fpistm/Arduino_Core_STM32 that referenced this issue Sep 18, 2020
This adds support for the DFU runtime protocol, which allows resetting
into the bootloader using a DFU command. This allows e.g. dfu-util to
handle the complete firmware upload, including the needed reset.

This consists of a number of changes:
 - An extra interface is added to the USB configuration descriptor. This
   descriptor has two parts (interface descriptor and functional
   descriptor) which together indicate to a host that this device
   supports DFU.
 - Control packets to this new interface are detected by the CDC code an
   forwarded to a new USBD_DFU_Runtime_Control() function.
 - This new function handles the DFU GET_STATE, GET_STATUS and
   DFU_DETACH commands. The former are optional, but simple enough, the
   latter is mandatory and handles resetting into the bootloader.
 - The CDC device descriptor is changed to become a composite device
   (CDC and DFU). This allows operating systems (in particular Windows,
   Linux did not really need this) to identify two different subdevices,
   and install different drivers for each (on Windows, this is serusb
   for the CDC part and WinUSB/libusb for the DFU part). Without this,
   dfu-util on Windows could not access the DFU commands when the serial
   driver was loaded.

   Because the CDC functionality already exposes two interfaces (which
   together form a single serial port), an IAD (Interface Association
   Descriptor) is inserted before these interfaces to group them
   together in a single subdevice. No IAD is needed for the DFU
   interface, since it is just a single interface.

   To become a composite device, the device class must be changed from
   CDC to a composite device class. This was originally class 0/0/0, but
   together with the IAD, a new EF/2/1 deviceclass was also introduced,
   which is used now.

Note that this only adds descriptors and a command handler on the
default control endpoint, so no extra (scarce) endpoints are used by
this, just a bit of memory.

This commit is still a bit rough, because:
 - The DFU descriptors and code are now pulled in directly by the CDC
   code (and HID is not supported yet). Ideally, there should be some
   kind of pluggable USB library where different interfaces can be
   registered independent of each other (see also
   stm32duino#687).
 - The interface number is hardcoded in the DFU descriptor.
 - The reset to bootloader happens immediately, while it might be better
   to wait a short while to allow the current USB transaction to
   complete.
 - DFU support is unconditionally advertised, while not all boards might
   support DFU.
@HamidSaffari
Copy link

@rhapsodyv
Here is the USB Middleware library
and here is the USB API documents for ARM mbed OS which would be nice if we can port and use it inside Arduino core.

@rhapsodyv rhapsodyv mentioned this issue Oct 4, 2020
6 tasks
@rhapsodyv
Copy link

I just pushed a working version, #1196. Right now, it just expose the default USBH_MSC_ interface from STM32_USB_Host_Library.
There're some work to do, and it isn't a standard interface yet, but I think it's good for a first version. And it's working! I'm using it in Marlin.

I commented with a sample usage too.

@Hyratel
Copy link

Hyratel commented Nov 9, 2021

still no examples for Joystick via USB HID Middleware, and MHeironymous's Joystick library relies on HID.h (arduino core) -> PluggableUSB.h (arduino core) -> USBAPI.h (arduino core)

@shreeshan97
Copy link

Is USB MSC + CDC ready??
Any example available??

@Levi--G
Copy link

Levi--G commented Apr 26, 2022

@Hyratel I don't know if its still relevant to you but i just "completed" a basic library to add the traditional HID/PluggableUSB support. It is in nowhere ready for merging in the core, but if MHeironymous's joystick emulation is all you need you can use it right now. ;)

If anyone else comes across this and is knowledgeable in usb feel free to contact me to make the library more compatible. :)

@Hyratel
Copy link

Hyratel commented May 15, 2022

@Levi--G I'd definitely be interested in what you have thusfar and yes - MHJoy is about all I'm after for this. it's about the only thing blocking the 32F401 from being a viable competitor to the 32F103 or Pro Micro in the Simpit and Custom Joystick scene (MHJoy is kinda Hammery (very few iterative loops, everything is done in a very sequential way; it makes a good primer to HID descriptor construction) but also very understandable to an amateur like myself, it has a very clean structure)

@Levi--G
Copy link

Levi--G commented May 15, 2022

@Hyratel Well i noticed a while ago that my library actually works "by accident" if you just use the HID class it will work, but while working on receiving code i noticed i would have to redo a lot of code already in the framework... So now im running into the issue my library would need to replace framework files to work, which would either be manually or via some scripting in platformio, not compatible with arduino ide. So atm im still figuring things out :/
if you use platformio and only are interested in basic HID with SEND only and no USBSerial you can use my lib here: https://registry.platformio.org/libraries/levi--g/USBLibrarySTM32
But a proper redo with receiving and proper endpoint handling will take some time sadly :(

@Hyratel
Copy link

Hyratel commented May 15, 2022

@Levi--G I got it working on F401 with your LibHack, so it's rough-and-ready for that. I look forward to it being given bidirectional, but even this much is a watershed moment for the chip's usability

(this is long overdue, considering that the chip has been around for almost 10 years now)

@SunboX
Copy link

SunboX commented Sep 19, 2022

I'm looking for a USB MIDI Device or Host example for the F103C6 or F103C8. Is there already one available?

I've currently this one working (USB MIDI Device):
https://github.com/arpruss/USBComposite_stm32f1/blob/master/examples/midiout/midiout.ino

But it uses the Maple core and is incompatible with other libraries that are using the STM32Duino core.

Edit: Seems my question is related to #1533

@fpistm
Copy link
Member Author

fpistm commented Sep 19, 2022

Hi @SunboX,

unfortunately not.
IIRW, On the forum some ones talk about this but I guess there is no progress.

@Levi--G
Copy link

Levi--G commented Sep 19, 2022

@SunboX
Well... i wrote a library to support all the original arduino usb libraries (i linked it a bit up) but i did not test MIDI yet, and installation is kindof hard atm since there is a bug in platformio, ill see if i can get it working yet and maybe you can test it then? It might work or not, but might be worth trying?

@Levi--G
Copy link

Levi--G commented Sep 21, 2022

@SunboX Hi, sorry to ping you twice, but i just tested my library with the default arduino MIDIUSB and it works, I included a sample in the repository, it might not be ideal (especially with the extended installation procedure) but it might at least work with the new core :)

@fpistm
Copy link
Member Author

fpistm commented Sep 21, 2022

@SunboX Hi, sorry to ping you twice, but i just tested my library with the default arduino MIDIUSB and it works, I included a sample in the repository, it might not be ideal (especially with the extended installation procedure) but it might at least work with the new core :)

Nice @Levi--G
Thanks for sharing.

@sstaub
Copy link

sstaub commented Aug 13, 2023

Are there any news? I see there is no real progress since some years.

@Levi--G
Copy link

Levi--G commented Aug 15, 2023

Well I would be prepared to do the work to integrating my "library" as an alternative USB implementation to provide compatibility with the traditional arduino libraries and check at least a few boxes. But i need someone from the team (maybe @fpistm ?) to guide me towards how to implement it in a way where it would not interfere with the original implmentation. Like what boards need to be supported (i ran into issues with DMA on some boards), what defines to use, make sure it doesn't interfere with the other implementation and set up testing and documentation and such... Not to mention code review and writing style i didn't even check for. 😓

@fpistm
Copy link
Member Author

fpistm commented Aug 28, 2023

USB_CON is used to enabled USB.
So You can simply try to use new define and add menu option to the boards.txt

@Levi--G
Copy link

Levi--G commented Oct 13, 2023

Yea the problem is I tried some different devices like stm32F401 or stm32F411 but there it does not seem to work, I don't know what goes wrong. I tried debugging with bmp and capturing packets, but the communication does not seem to work. The setup goes correctly so the hid devices are made and registered fine, but after that none of the endpoints are transmitting data. I have seen these devices don't use DMA for their communication, maybe that is the difference, but I cannot seem to find the issue as the calls made are identical to the usbcomposite library. So I am stuck not knowing if it has any use if only one device is confirmed working and at least 2 are not...

@Hyratel
Copy link

Hyratel commented Oct 17, 2023

F401

I had good results using the Arduino IDE, not VSCode @Levi--G (do not like VScode for Assorted Personal Reasons). the only change I had to make was https://github.com/Levi--G/USBLibrarySTM32/issues/1

@fpistm fpistm mentioned this issue Dec 4, 2023
@fpistm fpistm added enhancement New feature or request and removed New feature labels Jul 16, 2024
@fpistm fpistm unpinned this issue Aug 22, 2024
@gigaj0ule
Copy link
Contributor

TinyUSB has STM32 implementations, and many devices implemented already like MIDI and RNDIS.

It’s actively maintained too — could this be a good way to upgrade the USB subsystem?

https://github.com/hathach/tinyusb

@fpistm
Copy link
Member Author

fpistm commented Sep 16, 2024

TinyUSB has STM32 implementations, and many devices implemented already like MIDI and RNDIS.

It’s actively maintained too — could this be a good way to upgrade the USB subsystem?

https://github.com/hathach/tinyusb

Yes it could. I know it and already follow it. Anyway, the main issue is the time. This is a community project and any contributions are welcome.
Since some times I've updated the core to solve some issue and now USB support is provided as a built-in library , it should ease the process to add new USB stack.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests