Using an alternate interface for HID ? #260
Comments
|
The HS USB core has more endpoints, but that's not connected to the USB connector, so is no use for us. Please, issue a pull request for your MSC/HID, that would be awesome! |
|
yes, the HS needs an external phy, I guess they ran out of space :) anyway, I will send a pull request tomorrow... |
|
You can use the HS core in FS mode without any external circutry. In fact, you could wire up HS and normal core together (ie the DM DP pins together) and use whichever you wanted. HS core in FS mode gives you more endpoints and FIFO buffer space. |
|
cool, I didn't know that... so this is what I have so far, it kinda works, but there's one problem though, I can't re-attach the kernel module after switching the alt setting because it defaults to alt setting 0..my own project doesn't have this problem because the alt setting doesn't need a kernel driver so I don't re-attach it... any ideas ? |
|
okay, so this should work after switching the alt setting: But it doesn't ._. for some reason I get: Does the two alt settings have to have the same EP types/numbers ? |
|
Hmm, I don't really know how to fix this. It's nice to be able to switch the USB device from one setting to another using "alternate configs", but maybe that's too complicated. I was instead thinking to have an option in boot.py which makes the pyboard look either like MSC+VCP, or HID(+MCS/VCP). It would do this simply by sending different USB configuration data. |
|
I'm not sure how it's done in commercial products, but I've had some time to think about this, here's one possible and not very complex solution, when the set interface request is received we switch the MSC alternate interface value (in the config descriptor) to 1 (by writing to its offset something like Alternatively, we could read the value from boot.py and then do the same trick based on that, this will allow it to use the same cfg descriptor instead of allocating two of them. |
|
This would require putting the USB descriptor information in RAM (or at least the part that needs to be modified). Or, when sending the descriptor, you could intercept the ROM memory location that needs to be changed and instead send the corrected value. |
|
it's already in RAM not flash, right ? |
|
Yes you are correct, it's in RAM. |
|
okay, but now if we do a soft reset the config desc be reloaded from flash ? :D I think USB core has a softreset I will try that and get back to you |
|
so it turns out there's a softdisconnect feature which makes the OTG disconnect internal USB pull-up, and the device disconnects and re-enumerates, before using that I switch the altsettings like mentioned before, now this is the kernel log when it's first connected: and when doing And again doing |
|
Well, at least you can get back safely to VCP+MSC. There must be something wrong with the descriptor for HID. Have you tried the HID device without this alternate function switching? Have you tried just HID (no VCP composite device)? |
|
Yes, this softdisconnect trick will be very useful even if you decide to use two separate config descriptors, it's documented in the datasheet search for About the HID error, I always had this one with VCP/HID, even before I try the altsetting thing, it could be something with the HID descriptor, or maybe because I haven't updated my fork for a while ? |
|
Okay, so I checked out a fresh micropython, changed just one line: compile, flash and: |
|
oh and I moved the usb altsetting code to a new branch, til we decide what to do with it: |
|
it works with a single interface: |
|
Ok, you got me! Nobody and no messages in the forum :-) Where is everyone C. Towne Springer On Wed, Feb 12, 2014 at 8:00 PM, Ibrahim Abd Elkader <
|
|
Mostly through issues, but also on this google group: |
|
Can anyone test the HID and confirm that it's enumerated correctly ? or not ? |
|
It works only with a single interface (ie HID only). VCP+MSC works, but not VCP+HID... I played around with the descriptors a bit but couldn't get both interfaces working. See eg http://www.microchip.com/forums/m189607.aspx for some ideas on fixing this. |
|
I'm not sure why, but if you move the HID interface descriptor before the CDC (make it the first interface) it works and CDC doesn't ! |
|
It's strange. It could be a linux USB driver issue, not enumerating composite devices correctly. Each device on its own has the correct descriptor, but putting them together, linux seems to get confused for HID and CDC. |
|
It could be or it could be an issue with the USB stack, descriptor or anything else, so what if we use the softdisconnect as mentioned, but instead we switch descriptors ? MSC/HID or MSC/CDC ? as simple as that |
|
The latest version in stmhal/ now has support for CDC+MSC or CDC+HID. I managed to somehow get the composite CDC+HID working with the new Cube HAL driver. |
|
what about switching between CDC/MSC and CDC/HID ? I can try the softdisconnect in stmhal if you want ? |
|
I am using Windows 7. When trying http://micropython.org/doc/tut-mouse and putting pyb.usb_mode('CDC+HID') into boot.py, the board does not enumerate correctly anymore. The CDC part still works, but HID is not working, and the Windows device manager shows a problem with a mass storage device (German: "Massenspeichergerät"): Has anyone the HID demo working on Windows? |
|
@markusgritsch I can confirm that HID + CDC is not working under Windows. I had tested it on Linux and Mac, but it seems that Windows was not tested for this feature. Windows handles composite USB devices differently to Linux and Mac, and fixing it for Windows I think then breaks it for Linux and Mac. The solution is to provide either a pure HID configuration (ie no CDC), and/or a HID+MSC configuration, and/or a different version of HID+CDC. I'll see what I can do. |
|
Has been found some solution in windows 7: you can use HID interface, but you have to change driver manualy. |
|
@inaugurator which version of the firmware did you use? The very latest version of master has a fix for this: it changes the PID of the USB device when it is in CDC+HID mode so that Windows uses a different configuration, and hence a different driver. It uses PID 0x9800 in CDC+MSC mode, and PID 0x9801 in CDC+HID mode. |
|
Great! With firmware pybv10-network-2014-10-29-v1.3.5.dfu it works fine for me. |
|
Could you, please, share a project CDC+HID mode? |
@bowman85 please see the official tutorial: http://docs.micropython.org/en/latest/pyboard/pyboard/tutorial/usb_mouse.html |
|
This can be closed: stmhal supports dynamic selection (in boot.py) of VCP+MSC, VCP+HID or VCP only. |
This is the first automatic update that has caused a few deletions where code was previously copied instead of moved. This is a prerequisite for micropython#260.
* atmel-samd: Support patching after updating ASF4. This makes it possible to automatically fix newer code. * atmel-samd: Update ASF4 to include flash APIs for SAMD51. This is the first automatic update that has caused a few deletions where code was previously copied instead of moved. This is a prerequisite for micropython#260.
This allows us to re-enable `os`. `random` is also enabled because it solely depends on `os`. Fixes micropython#266. Its also a pre-requisite for micropython#260.
* atmel-samd: Add support for internal filesystems. This allows us to re-enable `os`. `random` is also enabled because it solely depends on `os`. Fixes micropython#266. Its also a pre-requisite for micropython#260. * atmel-samd: Update SAMD51 linker script comments and MICROPY_MAX_STACK_USAGE enabling.
I needed a third (4th?) interface for my project, but there not enough endpoints for that, so I used an alternate vendor-specific interface with MSC, just got this working, and I thought we could use the same technique for MSC/HID ? this way you won't need to recompile to switch HID... I can send a patch if you like..
The text was updated successfully, but these errors were encountered: