MCU as a HID Device

[D4no0]

Hello,
So I have a project in mind where I need to communicate via USB and the device connected should be a custom HID device.
I was thinking of using ESP32 as the main MCU, however since it doesn't have usb capabilities I will require a USB interface chip and I don't quite understand how they are classified.
I found some chips like FT260 but they are unnecessary expensive, since I know that HID is just a wrapper over USB and can be programmed.

I was wondering witch choice would be the best? Project doesn't have any special requirements such as real-time transmission.

[zzattack]

Any microcontroller that does USB should work. I personally like STM32F0/F4 with the USB stack from IntergatedCircuits.

[NorthGuy]

There are lots of cheap MCUs which can be made into a USB HID device and do not require a external crystal or oscillator, such as PIC16F1454.

[ledtester]

Low speed, non-compute intensive HID devices can be implemented by an ATtiny mcu...

https://codeandlife.com/2012/02/22/v-usb-with-attiny45-attiny85-without-a-crystal/

[rstofer]

Pick an MCU that supports USB
https://www.pjrc.com/teensy/teensyduino.html

This stuff is all worked out, there's no reason to reinvent anything.  Several years ago I used the original version of teensduino on some incantation of an AVR to connect lights, knobs and dials to Microsoft Flight Simulator.  It was trivial.

[Ian.M]

If you are using the ESP32 because you need its WiFi and/or Bluetooth capabilities, you may consider a slave PIC18LF14K50 + a 12MHz crystal.

Using the HID example code from the Microchip USB stack, running as a SPI slave off the ESP32 should be viable.  Start with the HID code, remove its current physical (or virtual) inputs and hack on it till you've got a working SPI slave replacing the inputs then add any HID output stuff you need.   Pad the SPI data transfer with zero bytes where necessary to give the PIC time to respond. 

Although it would be *NICE* to be able to use the cheaper PIC16F1454, without a crystal, using a PIC18 gets you two interrupt priorities so the SPI service routine can run at high priority and the USB SIE at low priority and your slave's main loop can idle through housekeeping tasks with no particular response time constraints.  If you use a PIC16F1xxx you only get a single interrupt priority level and as you need very well defined interrupt latency for a successful high speed SPI slave, that means you have to run the USB stack as a polled task, which can be a PITA if any of your main loop housekeeping takes approaching 1ms or longer.

OTOH as others have suggested, if you don't need the wireless comms features of an ESP32, you'd be better off choosing a MCU that has native hardware USB support.

[wraper]

Low speed, non-compute intensive HID devices can be implemented by an ATtiny mcu...

https://codeandlife.com/2012/02/22/v-usb-with-attiny45-attiny85-without-a-crystal/

Not worth it anymore. You can get MCUs with native USB interface for less. Especially when considering surrounding components required if you are not doing crystal-less (close to fail on AVR) hack job with zeners but do it properly with 3.3V LDO and crystal.

[PCB.Wiz]

I was thinking of using ESP32 as the main MCU, however since it doesn't have usb capabilities I will require a USB interface chip and I don't quite understand how they are classified.
I found some chips like FT260 but they are unnecessary expensive, since I know that HID is just a wrapper over USB and can be programmed.

There is also CP2110, which is a HID USB to UART solution, should talk well to the EDP32 ?

[Nominal Animal]

Teensies (using Teensyduino in the Arduino environment) has existing joystick, keyboard and mouse examples, and in particular supports USB HID + Serial combination; you need only a couple of dozen of lines of code to implement it in the Arduino environment.  With that, you can use the HID (max. 64 bytes every 1ms, i.e. max 64000 bytes/sec) for the ordinary communications, and the USB Serial for bulk data or configuration (full speed, i.e. 12 Mbit/s; around a million bytes per second in practice).  Teensies use their own uploader utility (included in Teensyduino), so you don't need any programmer for them, just the USB cable.  Many others have done this, and the environment explicitly supports it, so it is pretty easy to get what you need working the way you want.

If you want to spin your own board, I can recommend ATmega32u4 for USB HID (and/or USB Serial) use.  You can check out the SparkFun Pro Micro board for suggestions; it is OSHW (CC SA 4.0 for the hardware, MIT for code), and the Eagle files are at SparkFun GitHub: you'll only need some resistors, capacitors, and a crystal to get it working at USB 5V.  ATmega32u4 is widely used USB HID (especially custom keyboard projects), and you only need open source tools (avr-gcc, avr-libc, and an uploader utility depending on which bootloader you use), or Arduino; there are lots of examples to adapt to your own code.

Some USB 3 ports have had some issues with USB 1.x and 2.x devices; probably because of driver inanities or poor hardware implementations.  In all cases I've heard (all laptops, IIRC), either the port was physically broken, or using an USB 2 hub in between solves the issue.  I use a cable hub (with USB micro and mini connectors) to connect to my prototypes, for that reason, and to reduce the stress on the small USB connectors on the microcontrollers: I attach/detach the hub from the computer, not the microcontroller from the hub.  I also have some ADuM3160/4160-based USB isolators, which work for up to 12 Mbit/s, for the cases when I connect the project to more than one computer or other powered device; even the cheap $8 USD Chinese clones off fleabay work fine.  They're all straightforward implementations of the datasheet anyway, and really only vary in which isolated DC-DC converter they use.

[NiHaoMike]

I suggest STM32 if 3.3V logic is OK, since it's actually cheaper than the Arduino Pro Micros nowadays and way more powerful.

[Nominal Animal]

NiHaoMike, have you actually used STM32 for an USB HID project?

I'm asking, because I have not, and a quick DuckDuckGo search shows rather convoluted steps to get it working.  (I am not being skeptical, just inquisitive curious/interested! Me fail English often.)

[legacy]

I had a few problems with Tensee v1 and v2 and my old laptop IBM T23 (PentiumIII), whose built-in USB controller is neither OHCI nor EHCI but rather a weird UHCI chip. All boards with Intel PCI chipsets like intel 430TX, 440FX, 440LX, 440BX, i810, i820 and all VIA PCI chipsets like VIA VP2, VP3, MVP3, Apollo Pro, Apollo Pro II or Apollo Pro 133 and LEON/GRLIB SoCs with the GRUSBHC controller, they all conform to this UHCI standard, and they all failed the same way with my Tensee v1 and v2.

Dunno why, but I tried several Linux kernel from 2.6.23 to 2.6.39, and I was so frustrated to see random errors and disconnections from the Tensee that I added a PCMCIA-USB EHCI card in a free slot of my old laptop and it sorted it out. My conclusion is that probably the problem was hardware, or firmware on the Tensee side.

My current laboratory laptop is an IBM/Lenovo X61S (intel core duo dual), the USB controller is EHCI, and the Tensee v1 and v2 have never had a single problem with it!

[legacy]

Some USB 3 ports have had some issues with USB 1.x and 2.x devices; probably because of driver inanities or poor hardware implementations.  In all cases I've heard (all laptops, IIRC), either the port was physically broken, or using an USB 2 hub in between solves the issue.

These issues are also present on MIPS routers like the old 703 where the USB controller is built-in the SoC and it's somehow bugged by some USB  device that needs to talk "high speed" rather than "full speed". It's not clear to me why? what? etc, but I know that even cheap USB PCI cards made with crappy VIA chip seem to have the bug, and there is no definitive solution, just the "workaround" of putting a USB2 hub between.

[ogden]

NiHaoMike, have you actually used STM32 for an USB HID project?

You can do it yourself, fast. Install STM32Cube, configure clocks and pins, compile example HID keyboard or mouse project and you are done. Cube may not be the best way of building polished products, but it is very good tool for throwing snippets together to get first prototype running fast.

Any microcontroller that does USB should work. I personally like STM32F0/F4 with the USB stack from IntergatedCircuits.

I am looking for small footprint CDC stack. This could be the one? How it compares to USB stack from ST?

[NiHaoMike]

NiHaoMike, have you actually used STM32 for an USB HID project?

Yes, just use PlatformIO as an alternative to Arduino.

[thinkfat]

STM32F042, USB without crystal. You can get it in TSSOP package, if QFN or QFP scares you.

Gesendet von meinem Nokia 6.1 mit Tapatalk

[SiliconWizard]

A small MCU will definitely be both cheaper and more flexible than fixed-solution HID interface ICs.

In one project I have used the Teensy line. Lots of existing code, gets you there in a short time. If you favor low power draw though, I would go for an STM32 instead.

[PCB.Wiz]

A small MCU will definitely be both cheaper and more flexible than fixed-solution HID interface ICs.

That's true for reasonable volumes, but for low volumes of UART bridge use, the fixed solutions save a lot of development & deployment time, and time is money.
Someone could start using CP2110, and then on the same PCB, move to a SiLabs USB MCU, which have HIDtoUART examples included.

[NorthGuy]

That's true for reasonable volumes, but for low volumes of UART bridge use, the fixed solutions save a lot of development & deployment time, and time is money.

If you can do the processing directly on the MCU, you not only eliminate the bridge entirely, your development time may actually get shorter.

Even if you use MCU as a bridge to your main MCU, you still can do some of the processing on the bridge MCU, so your main MCU sends/receives only the data it needs and in the most convenient format.

[nigelwright7557]

I found a good website for getting started in PC to PIC USB.
www.waitingforfriday.com
He gives a circuit for PIC18F4550, PC software and PIC software to toggle an LED.
I have used it for the basis of numerous PIC USB projects and it works a treat.

[Ian.M]

Unfortunately the https://www.waitingforfriday.com/?p=415#Reference_Firmware for USB HID uses the Microchip C18 compiler which is long obsolete and can no longer be licenced.   Ideally one would start with newer code that can be built with the current XC8 compiler.

[SiliconWizard]

That's true for reasonable volumes, but for low volumes of UART bridge use, the fixed solutions save a lot of development & deployment time, and time is money.

If you can do the processing directly on the MCU, you not only eliminate the bridge entirely, your development time may actually get shorter.

Even if you use MCU as a bridge to your main MCU, you still can do some of the processing on the bridge MCU, so your main MCU sends/receives only the data it needs and in the most convenient format.

Absolutely.

Besides, there was a point completely missing here. If all that's required is a "UART to USB" bridge of some kind, then OK. Then again, there are myriads of solutions, you don't necessarily need an HID device either. Sure it saves having to install a specific driver, but most UART to USB solutions on the market have perfectly working drivers on most platforms, are often cheaper, and many even have drivers that are already included in most OSs, so the point may be valid in some specific cases, but you don't necessarily need to bother.

Now if you want to develop any kind of HID device outside of this particular case, the ready-made solutions listed won't work, they are just not configurable enough for that. That would include keyboards, mice, any kind of joystick, the list goes on...

[nigelwright7557]

Unfortunately the https://www.waitingforfriday.com/?p=415#Reference_Firmware for USB HID uses the Microchip C18 compiler which is long obsolete and can no longer be licenced.   Ideally one would start with newer code that can be built with the current XC8 compiler.

I took his project as a starting point and made a 460K sampling oscilloscope using PIC18F4550.
I then converted it using Microchip Harmony to use the PIC32MX and XC32.
I took his PIC app.c  and replaced the harmony app.c and it worked a treat.

[JVR]

There are lots of cheap MCUs which can be made into a USB HID device and do not require a external crystal or oscillator, such as PIC16F1454.

Seconded. They are dirt cheap, and set up real quick. Also available in really tiny packages.

[Ian.M]

Unfortunately the https://www.waitingforfriday.com/?p=415#Reference_Firmware for USB HID uses the Microchip C18 compiler which is long obsolete and can no longer be licenced.   Ideally one would start with newer code that can be built with the current XC8 compiler.

I took his project as a starting point and made a 460K sampling oscilloscope using PIC18F4550.
I then converted it using Microchip Harmony to use the PIC32MX and XC32.
I took his PIC app.c  and replaced the harmony app.c and it worked a treat.

Good to know, as a few years back, I also found the waitingforfriday code interesting and helpful.  Would you be able to post the complete PIC32MX MPLAB project you converted somewhere (+ enough of a schematic or pin connection list to make sense of the code)?

I still have concerns about a C18 =>XC8 port.  Hopefully its got easier since I last had that chore.