Not at the moment. It'd be nice if there was a way though.

It seems a lot of devices now enumerate as several different USB devices. Ideally Espruino could enumerate as CDC (the existing COM port), an HID keyboard + mouse, and possibly mass storage for accessing the SD card.

A thread on this here: http://forum.espruino.com/conversations/127079

Current thought is to allow a custom device IDs to be described along with handlers for each endpoint - that'd allow for keyboard/mouse/trackpad/joystick/etc.

Ideally that would be part of a commit that simplified USB though - currently there are 3 different copies of basically the same code (for F1/3 and 4 parts).

I'm not really that clued up on USB, so it'd be great if someone else could work on this.

Needed as it was a Pico KickStarter stretch goal that got hit

Other things required as part of this:

• Swap to STM32Cube peripheral libs, merge the 2 separate USB stacks
• Working sleep for USB peripheral (this is killing Pico's power consumption in deep sleep atm)
• Fix 'wait for USB' issue: Pico always waits until USB connect before loading saved code #497
• 'Device flags' for fast boot: Add 'device flags' functions #482
• USB flow control: STM32F4DISCOVERY USB flow control #21

This is now added for the Pico as part of the NEW_USB Branch.

It's tantalisingly close for the Espruino Board too, but sadly not there yet - there seem to be some problems with how buffer sizes should be set for the USB hardware.

I'm about to get a Pico and just wanted to say thanks to all the contributors, especially to this issue. I wanted to make a password generator Yubikey-esque and the support for this is exactly what I needed. Thanks again!!!

Thanks! Just to add it's now all in the 1v80 release of the software, so I'm closing this.

It seems that Windows still has trouble picking Espruino Composite USB HID devices up, but they work great on Mac and Linux. Hopefully 1v81 will have the ability to disable the USB COM port and use only USB HID - which will make it work fine on Windows.

@gfwilliams I understand this is closed, but I'm just wondering if the Espruino Pico can be multiple HID devices at the same time, as in, a mouse and a keyboard?

As far as I know, it can't at the moment (although it might be possible for it to appear as one device that has a pointer and keys?). While you can specify a custom report descriptor, at the moment you can only send data to a single USB endpoint - and I think you may need 2 endpoints for 2 devices.

Maybe someone who is more clued up on USB would be able to help here?

It's a good point though. I've just filed an issue for adding 2 USB endpoints here: #562

Yeah after I had commented on here I tried using two descriptors in a single call to setUSBHid, it still detected one unfortuently, I researched a bit for Linux (because Windows has yet to work with the HID module) and found the usbhid kernel module had to be loaded in a certain way (a quirk option IIRC) but haven't got round to it due to me not having time.

I'll try and look into it soon!

Thanks! If you get it working, any info you have would be great.

It might be that the other descriptors just reference one report, like here.

Right now it'd need a recompile to change that, but it should be a lot easier when all the descriptors can be specified.

Ideally Espruino could enumerate as CDC (the existing COM port), an HID keyboard + mouse, and possibly mass storage for accessing the SD card.

Would be cool to be able to manipulate Storage module entries via USB Mass Storage.

I had been wondering about that kind of thing, but as I understand it Mass Storage exposes the underlying block device - so we'd have to move to a much bigger flash area and use FAT32 unless there's some crazy way we can fake a whole FAT32 filesystem.

The media transfer thing Android phones do when you plug them in might work though?

Well yes, it'd need to emulate some filesystem.

FAT16 perhaps?

But as you say, MTP could be the way to go. It's just that the USB Mass storage is easier from the user perspective.

The Teensy MTP responder implementation looks quite minimal.