Reverse engineer USB HID device: easy way to hack up USB hardware?

Question

Background:

I want to make a custom controller for an XBox. Either by butchering an existing controller, or making the hardware and firmware from scratch(ish). (Specifically, the goal is to make an arcade machine style driving simulator with steering wheel etc., directly mapped to buttons on a standard controller.)

I have an unbranded Xbox USB controller which seems to be compliant with USB standards, since connecting it to a PC and using USB packet sniffers confirmed that it's recognised as an HID device and the data coming from it seemed to be simple and made sense.

My question: What would be the most straight forward way of making the USB device from scratch(ish)?

I was going to butcher an existing controller: desolder any variable resistors and replace with my own, e.g. for the steering wheel - and the same for switches. Dead simple. But the problem is, among others, the latency of the controller seems to be pretty poor, and I was hoping to improve on it.

Are there any out-of-the-box solutions such as Raspberry Pi, Arduino or similar, which would, for making an HID device:

1. Have a library giving the simplest high level interface to the necessary USB protocols, with hello-world HID code samples.
2. Give me good latency (not hard, I'm sure, given it's a simple HID device)
3. Preferably via a high level programming language such as Java. (My C programming leaves a lot to be desired)
4. Not break the bank
5. Come out-of-the-box with 6+ ADC inputs (>100Hz sample rate, >10 bits) and some digital inputs

Ideas:

1. Raspberry Pi seems overkill
2. Arduinos' AFAIK have a reputation for being limited given their proprietary language/compiler.
3. I usually program 8-bit PIC microprocessors, but I've heard their USB stack is limited, hard to use and generally problematic. Also it would probably mean extra circuitry; or at least hassling with non-DIP packages, making PCBs or whatever else
4. Program an old Android smartphone to act as an HID device. I don't know which, if any OS versions would allow me to do this without writing or modifying a custom ROM. But the only way I can think of getting analog/digital inputs would be via a bluetooth module which would connect to the phone, no doubt giving terrible latency from end-to-end.

All advice welcome!!

Answer 1

Teensy is quite good at being USB HID: https://pjrc.com/teensy/usb_keyboard.html

But if you want to plug it into an xbox, the software side may be slightly more complicated; I don't think the xbox controllers are simple USB HID and I believe they have anti-cloning systems.

Answer 2

I'd suggest here the PIC32 series of microcontrollers, probably more specifically the PIC32MZ series of parts. In-built USB, lots of analog channels, up to 200MHz on parts so even a bit of data fiddling and play across a significant number of channels probably won't correspond to latency at the human level. It is also considered to be a microcontroller so you don't have some of the overhead of ARM cores when you approach that uC-SoC boundary.

Granted, they are typically available in SMT parts (I think the -MZ series only exists in SMT grades) and you'll likely need at least a small generic board to use it, but there are pre-made boards available, such as this. You mention the smaller PICs, so this might feature the same development environments, at the slack of being a completely different architecture. It's likely the USB stack offerings for this family of devices is improved over the 8-bit PICs due simply to the increased capability. There's even an open-source stack available here that supports HID, although it may require some jimmying to make work as it's fairly young.

Finally, a few tidbits and pointers - Arduino is open-source; so it's not proprietary per se; as pjc50 notes above people have managed to reconfigure small AVRs to act as a HID controller rather than the default device mode. Microchip's stacks are proprietary and thus you are reliant on them as the primary source of documentation.

Also, I would caution against being too dependent on higher-level languages for this sort of development. Over the years, there has certainly been a number of different projects intended to open uC development to HLLs such as Java or Python. These are certainly novel developments, but for applications such as real-time sampling or processing (such as your application), efficiency is critical and imparting VM/JIT/interpreting on these devices wastes such efficiency. In these embedded, microcontroller environments operating closer to low-level than high is often a cost of doing business (or, at least, doing it efficiently). As is often said, the tools used must fit the job.