USB HID

Please do not post requests
User avatar
RogerClark
Posts: 6662
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: USB HID

Post by RogerClark » Sat May 20, 2017 2:12 am

I can try to merge the Master back into the AddMidiHID and see if the changes from the master are pulled in without an collisions.

Alternatively, as the AddMidiHID branch name confused a lot of people I could delete that branch and pull @libarra's master to a new USBMidiHID branch

petr
Posts: 32
Joined: Wed Jul 15, 2015 10:33 am

Re: USB HID

Post by petr » Sat May 20, 2017 8:10 am

The latter sounds like minimal work for both of you, which is good in times when everyone is busy working on many things.

libarra
Posts: 56
Joined: Tue Sep 15, 2015 2:51 pm

Re: USB HID

Post by libarra » Sat May 20, 2017 1:56 pm

RogerClark wrote:I can try to merge the Master back into the AddMidiHID and see if the changes from the master are pulled in without an collisions.

Alternatively, as the AddMidiHID branch name confused a lot of people I could delete that branch and pull @libarra's master to a new USBMidiHID branch
petr wrote:The latter sounds like minimal work for both of you, which is good in times when everyone is busy working on many things.
I agree

User avatar
RogerClark
Posts: 6662
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: USB HID

Post by RogerClark » Sat May 20, 2017 10:37 pm

Can you tell me a good name for this branch, as I know there was a lot if confusion about the name I gave to the old branch.

ag123
Posts: 708
Joined: Thu Jul 21, 2016 4:24 pm

Re: USB HID

Post by ag123 » Sat May 20, 2017 11:04 pm

i aren't really against having usb-hid as a composite device, just that i'm thinking this is much better done as a *library*, i.e. it should be a separate implementation and leaving the usb-serial in the core untouched. this is so that for the ordinary cases, it would simply be usb-serial, this minimize complications to the different use cases and platforms (windows, linux, mac etc).

some large usb device class implementations can really be called applications themselves amounting to being 'the sketch' itself implementing the usb-device class. e.g. usb mass storage literally requires implementing a scsi device over usb

the library should be documented such that to use this library one should undef SERIAL_USB in platforms.txt, this is so that the alternate usb implementation from the library can be used.
(read roger's comment below, editing platforms.txt and undef SERIAL_USB may not be required, one concept is one could call usb.end() to end the current device, then pull D+ / D- low for 10ms (usb reset) so that the host would start re-enumerating usb devices, in the mean time we call a new usb.begin() implementation and start as a new usb device class. this concept is *very useful* as it means that you can have a *sketch* that runs with USB-Serial ask the user what usb device the user wants, then do a usb reset (D+/D- low 10ms) and warp into a new usb device class) :mrgreen:

this would be the preferred approach as for 'ordinary' cases, normally one would expect basically a serial interface there, and it isn't a surprise that Serial and SerialUSB is most commonly used for arduino - host interfacing, including simply printing and receiving commands / data as a user interface.

the trouble of course is that beyond USB-Serial, there can be usb hid, usb mass storage, usb cdc ethernet, usb audio and many other useful usb device classes. given the limited ram and possible complications and possible conflicts, and to simply use cases, it would be better if the usb device classes be abstracted as 'libraries' so that if one wants to use the different usb device class, one should first 'disable' usb-serial by editing platforms.txt


i'm actually quite keen to include ST's 'usb core middleware' (i'd think distributed within those ST'cube hal stuff) in which ST actually included some device classes implementations (notably cdc (e.g. usb-serial), usb mass storage, usb-hid, usb-audio) along with an extendible common 'usbcore'. i think this may be found in stm32generic as well as stm's core, just that i'm not too sure if the 'license terms' may have certain issues. the implications of including those st's codes some of them seem to have origin from keil is that it turns these stm32 devices into usb devices with a ready usb device class implementation for popular device classes e.g. usb mass storage, hid, cdc, audio, etc

the alternate is of course to implement it similar in spirit to this usb hid implementation, but as i'd prefer as 'libraries' so that it may be distributed as part of the 'core' set of libraries without possible complications

just 2 cents
Last edited by ag123 on Sun May 21, 2017 12:12 am, edited 4 times in total.

User avatar
RogerClark
Posts: 6662
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: USB HID

Post by RogerClark » Sat May 20, 2017 11:22 pm

Having the other USB types as a library seems a good idea if its technically possible.

I recall a USB mass storage demo sketch that I tried a long time ago, which kind-of worked.

From what I recall, I think the initialisation code calls Serial USB begin() so that users dont need to do it.

But we may be able to call Serial USB end() to kill it and then call USB HID begin to reset the USB bus and get HID instead of serial.


I think however that removing the Serial USB begin may not be a good idea as it may break loads of existing sketches

ag123
Posts: 708
Joined: Thu Jul 21, 2016 4:24 pm

Re: USB HID

Post by ag123 » Sat May 20, 2017 11:34 pm

i briefly dig my toes in it only to realise just how complex the usb protocol stack can be
http://www.stm32duino.com/viewtopic.php ... 367#p27723

e.g. to implement usb mass storage, one would need to basically program a scsi device and translate those scsi commands say and interfacing with the sd card, i think this is one of a popular scenario
the effort of which is no less than doing a full blown 'app / sketch', it could literally be 'the sketch' itself.

and my guess is implementing things like usb-cdc-ethernet (i.e. usb ethernet dongle) may be similarly complex
then there is a wish for a core 'common' usb core component which we could hook devices classes to this 'core' and letting this 'usb core' do some of the usb protocol work that's common.

this 'usb core' is actually found in st's cube mx usb protcol stack, st literally called this a 'usb middle-ware' or rather 'usb device library'
um1734 stm32 cube usb device library
http://www.st.com/resource/en/user_manu ... 108129.pdf

And st literally developed some of the device classs as well as described earlier. only thing of course is could we simply use those st's cube mx codes, which seemed pretty invloved (note some of them are *partial* implementations) in themselves?
Last edited by ag123 on Sun May 21, 2017 12:01 am, edited 1 time in total.

ag123
Posts: 708
Joined: Thu Jul 21, 2016 4:24 pm

Re: USB HID

Post by ag123 » Sat May 20, 2017 11:40 pm

back to this topic, i think the 'libraries' approach is pretty much the better approach for 'usb device classes' given the large number of different usb device classes / use cases
just that as usb enumeration etc would pretty much be *mutually exclusive* say vs UsbSerial

i.e. you can't enumerate as usb-serial and then separately as a composite device.
you would need to enumerate as a usb-composite (e.g. serial + hid) device and that being the case it would be necessary to undef SERIAL_USB in platforms.txt so that the 2 devices won't conflict with each other during enumeration
^^ actually i'm not to sure if this is indeed the case

hence, uses who wants to use specific new usb device classes would need to manually edit platforms txt themselves as it differs from the default usb-serial use case

----------
hi roger, i just read your comment about the usb.end(), i'd think that's one thing worth testing as we'd be able to avoid having to mess with platforms.txt and SERIAL_USB

i think you are likely correct about the usb.end(), as i'd imagine it would be possible to simply pull D+ and D- low for 10ms (usb reset) to get the host to start re-enumerating again. while we can write a different usb.begin() to start a different device class

User avatar
RogerClark
Posts: 6662
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: USB HID

Post by RogerClark » Sun May 21, 2017 12:29 am

I just checked and there is usb serial end

https://github.com/rogerclarkmelbourne/ ... pp#L88-L93

And yes.

I think if you call end and reset the USB bus, you should be able to get the board to enumerate as a different device

I'm just not sure how the host PC etc will handle getting a reset soon after its just started to setup for USB CDCACM

Though it should be easy to test.

Re: Mass storage.

There have been posts about this

http://www.stm32duino.com/viewtopic.php?t=315

The code is here

https://github.com/joeferner/maple-usbMassStorage

Though I don't know if it still works - however we have not changed the core of the USB significantly, so I suspect it could be made to work

ag123
Posts: 708
Joined: Thu Jul 21, 2016 4:24 pm

Re: USB HID

Post by ag123 » Sun May 21, 2017 12:40 am

thanks roger, i may 'mess with it' when i get some breather of time to 'play with it', additionally i like the idea of doing a usb reset and 'warping' into a different device, this could possibly make those stm32 boards with loads of flash work as a multi function usb device e.g. first run as a sketch then offer on usb-serial, select 1) mass storage, 2) hid, 3) audio etc, after the selection usb reset and warp :D

Post Reply

Who is online

Users browsing this forum: Bing [Bot] and 1 guest