USB HID Support on Pico!

Yep, confirmed that something going wrong with uploading/saving code to Espruino on my Win 8.1/Chrome 44. Working fine on OSX + Chrome 43.

But the repeated character bug is fixed. Thanks!

Yes, I think there may be some problem when repeatedly writing USB HID code to Espruino (it doesn't happen when I upload normal bits of JS, but recently I've had similar problems when trying to update USB HID code).

Ah good to know.

I've removed the ST drivers and rebooted the Win 8.1 PC but still no joy. Device Manager refreshes when I plug/unplug the Pico but no new entries appear in either the HID or Keyboard sections. I think the refresh is just the COM port appearing/disappearing.

Ok, thanks - I just had a try and noticed this too.

Has anyone actually had any luck with Windows at any point, for Mouse or Keyboard?

I wonder if it's to do with the descriptor not being right, or is just because the ST com port drivers are somehow 'grabbing' the whole device. I guess there must be some kind of debug info available in windows.

Sigh. This is why I hate doing anything remotely platform specific - not that HID actually should be!

I've managed to make some progress on Windows. I had to uninstall/delete the ST Driver from inside Device Manager. Once I did that and unplugged/plugged the Pico, a USB HID device appeared and installed. However it does not work (This device cannot start. (Code 10) {Operation Failed} The requested operation was unsuccessful.)

These are the logs from Windows:

Driver Service Added (usbser)
Driver Management has concluded the process to add Service usbser for Device Instance ID USB\VID_0483&PID_5740\00000000001A with the following status: 0.

Device installed (stmcdc.inf)
Driver Management concluded the process to install driver stmcdc.inf_amd64_9422b577b75e16b8\stmcdc.inf for Device Instance ID USB\VID_0483&PID_5740\00000000001A with the following status: 0x0.

Device deleted
Device USB\VID_0483&PID_5740\00000000001A was deleted.
Class Guid: {4D36E978-E325-11CE-BFC1-08002BE10318}

Device Configured (input.inf)
Device USB\VID_0483&PID_5740\00000000001A was configured.

Driver Name: input.inf
Class Guid: {745A17A0-74D3-11D0-B6FE-00A0C90F57DA}
Driver Date: 06/21/2006
Driver Version: 6.3.9600.17041
Driver Provider: Microsoft
Driver Section: HID_Inst.NT
Driver Rank: 0xFF3101
Matching Device Id: USB\Class_03&SubClass_01
Outranked Drivers: input.inf:USB\Class_03:00FF3202
Device Updated: false

Device not started (Hid Usb)
Device USB\VID_0483&PID_5740\00000000001A had a problem starting.

Driver Name: input.inf
Class Guid: {745A17A0-74D3-11D0-B6FE-00A0C90F57DA}
Service: HidUsb
Lower Filters: 
Upper Filters: 
Problem: 0xA
Status: 0x0

Hmm. That log isn't hugely helpful - I wonder what the problem starting actually was, as it doesn't seem to say much more than had a problem starting.?

What happens if you now use one of the older builds (that had the device subclass set as a mouse) with the example code for the mouse? Does it work any better?

I'll try that in a bit. Any specific build?

I had to re-install the ST VCP driver to get the COM port back, and immediately lost the HID device from Device Manager so I strongly suspect something bad with their driver.

Yeah, maybe not bad with their driver, but it probably claims the whole device. I'll have to look into doing a custom inf file like MicroPython does.

This build would probably work ok - it's the one just before I changed the HID details.

I tried to get the Pico HID work with Windows (7) , same behaviour, the HID class does not enumerate as well. I wonder if the Device Descriptor field "bDeviceClass" should be set to 0x00 (line 62 of usbd_cdc_hid.c). I read in a (great) document from Cypress those few lines:

"bDeviceClass, bDeviceSubClass, and bDeviceProtocol
are used by the operating system to identify a driver for a
USB device during the enumeration process. Filling in this
field in the device descriptor prevents different interfaces
from functioning independently, such as a composite
device. Most USB devices define their class(es) in the
interface descriptor, and leave these fields as 00h."

The document can be found here: http://www.cypress.com/file/134171/download

No joy with older build and mouse code. No HID device appears. Works ok on OSX.

A full drive uninstall/delete gives the same HID error as the keyboard code.

Shows "STM32 Virtual COM Port" in the installation step when plugging in again but you don't actually get a COM port, you have to reinstall the driver fully to get that.

@Jean-Philippe_Rey Thanks, that's a good point - and there's also usb_desc.c:129 (not sure why those details are specified twice?). I wonder if setting it to 0 would affect enumeration when it was just a CDC device.

I'm actually having troubles with the build at the moment (sometimes it works, sometimes the build doesn't enumerate at all when using HID) so it's proving hard to test.

Hmm, no luck I'm afraid.

In usbd_cdc_hid.c it turns out the 2 you see if actually the USB version number. I just added comments to it:

/* USB Standard Device Descriptor */
__ALIGN_BEGIN static const uint8_t USBD_CDC_HID_DeviceQualifierDesc[USB_LEN_DEV_QUALIFIER_DESC] __ALIGN_END =
{
  USB_LEN_DEV_QUALIFIER_DESC,    // bLength
  USB_DESC_TYPE_DEVICE_QUALIFIER,// bDescriptorType
  0x00,  // bcdUSB lo
  0x02,  // bcdUSB hi
  0x00,  // bDeviceClass
  0x00,  // bDeviceSubClass
  0x00,  // bDeviceProtocol
  0x40,  // bMaxPacketSize0
  0x01,  // bNumConfigurations
  0x00,  // bReserved
};

But usb_desc.c did have the problem. Sadly that didn't help matters though :(

Same here when working with the linked firmware. I had the com port disappearing several times after a save() and only a firmware re-flash would bring the Pico back. (which is the only thing I came up with, at least)

Don't know if this is only for dual saves (one for the basic HID code, on after actually setting up app data on the device).

Creates a bit of dev cycle overhead thru firmware flashing ... :)

Hm, missed a whole page of discussion before posting... Sorry.

Tried again with a single save() after pushing the code via the IDE (instead of another/second save()), which seems to work.

So the multiple HID config might be the culprit, as you suggested.

Today I managed to kill the com port with a single save(), so...
I flashed the older firmware again and don't use the pico on a mac for the time being.

Yeah, I'll try and fix that problem today hopefully. My guess is it's to do with the changes to RAM size rather than anything specifically to do with USB HID.

Hi,

Does anyone managed to get the VCP+HID class enumeration on Windows?
I came accross a document that explains how to enumerate a composite device.
Is anyone working on this those days?

When HID is enabled, it is a composite device already... The issue seems to be that Windows still seems to require an 'inf' file for it (much like it does for normal VCP devices). All other OSes (Mac, Linux, Android) seem happy with it as-is. Usually that inf file is in the ST driver pack that you have to install before you start using Espruino - but it only mentions VCP - not the HID stuff at all.

The only solution I'd found to get it working driverless on Windows appeared to be for me to add the option to disable the virtual COM port and have just the HID device - but that means trying to develop HID stuff on Windows would be a nightmare, so it wasn't desperately high priority.

But if you can figure out some way of tweaking the descriptor such that it does actually work then I'd be very happy to include it :)

I guess if you found a VCP+HID composite device that does work without drivers then we could compare the descriptors and see what was different?

OK I had a look at the different descriptors (Device desc, Config desc, Interface desc, Endpoint desc, ...) as well as the stmcdc.INF, and it appears that I am completely lost. I can't figure out if 2 configuration descriptors are used (one for each interface) or if only one configuration descriptor is used, thus enclosing both interfaces. I am not familiar enough with that USB stuff to pretend I will find a solution, but I read this (old) post where they managed to enumerate a VCP/HID device with an STM32.

I will continue to try to understand all that stuff anyway.

You could compare with what's here: https://github.com/espruino/Espruino/blob/master/targetlibs/stm32usb/usbd_cdc_hid.c#L181

But it seems like there might be some USB debug tools for Windows, and those might be the best place to start? They might give some clue as to what Windows thinks is wrong.

The only solution I'd found to get it working driverless on Windows appeared to be for me to add the option to disable the virtual COM port and have just the HID device - but that means trying to develop HID stuff on Windows would be a nightmare

Do we have a way to get a telnet terminal on a wifi connected Espruino yet? That's a solution (for certain values of solution). Or setConsole and a TTL serial adapter...

Yes, a USB-TTL adaptor would work fine - it defaults to B6/B7 when USB isn't connected anyway, no there's not even a need for setConsole.

You can implement telnet over WiFi with a few lines of JS, it's just not built-in yet (as the existing WiFi driver uses a JS library, so would have problems if you wanted to totally reset Espruino).

It seems that on Windows, if there is more than one interface descriptor within a configuration descriptor, the latter should include a IAD (Interface Association Descriptor).

[Device Descriptor]
[ConfigDescriptor]
[Interface Association Descriptor]
[Interface Descriptor] (1)
[EndPoints Descriptors and so on..]
[Interface Descriptor] (2) 
[EndPoints Descriptors and so on..]   

I don't see any IAD in usbd_cdc_hid.c. Maybe this could do the trick in order to allow windows to enumerate this CDC-HID config.

That said, I don't know if IAD are recognized in Linux and macOS

I am exploring USB enumeration with STM32F4DISCO. I will give feedback here in case of positive results.

I just found a working example of dual CDC (2 COM ports) on a stm32F103 HERE. This example may help.