USB devices are easy for users to install and set up (as long as everything is working correctly). Often, you just plug in a USB device and it works immediately. This is especially true for input devices, such as mice and keyboards.
Those devices conform to a specification layered on top of the USB protocol: Human Interface Device. Almost any possible type of input is defined; an entire “report descriptor” language is used to tell the computer how to process the input. This is not very simple to implement; dozens of specific requests must be handled properly. There are many steps between plugging in a USB device and being able to use it; these all take place in a few milliseconds and failure of any step means the device will not work.
What if you didn’t have to worry about any of that? What if you could use your favorite microcontroller, do “something” and the input appears on the computer in the correct format? You wouldn’t have to worry about complex USB code, HID specifications, or breaking your USB code when adding the other functions you need. You wouldn’t have to worry much about writing optimized code, or always getting in the way of USB interrupts.
That’s exactly what I decided to do. A couple of years ago, I developed a USB device and went through all the headaches of getting a USB HID up and running. Since I already had the hard work done, I decided to add a method of receiving data from another microcontroller and using that data as the input stream for the HID code. I wanted to use a Cubloc BASIC-programmable controller to process my input data and send it to the HID Portal. My test application would be an accelerometer-based HID joystick; simply plug the device into the computer and it will work.
It doesn’t have to be a joystick; it could be a keyboard, a mouse, or many other controls defined by the HID standard. It’s possible to add volume control buttons to a device…maybe have a circuit mute your computer when the phone rings? Turn any voltage input into a joystick axis, any switch into a button? Anything is possible!
Update:I decided to shrink the CUBLOC hardware down to a CB220, and fit everything into an airplane model. The model was chosen to match an airplane available in the Heroes of the Pacific game we used to test the joystick interface.
The HID Portal is based on an old project of mine, based on an MC68HC908JB8 microcontroller and programmed in assembly language. For certain reasons I can’t actually release the code right now, but there are plenty of other USB projects out there which could be adapted for this purpose. There’s an open-sourced soft USB implementation for the ATtiny microcontroller, for example.
My microcontroller doesn’t have built-in I2C or SPI, so I needed to implement one of my own. I also didn’t have interrupt pins available, meaning my solution needed to be based on polling. When all was said and done and optimized, I couldn’t detect edges faster than 16Khz. This is about ten times slower than the shift output available from the CUBLOC controller, so I couldn’t use that. I ended up writing my own shift-out routine in BASIC to get the data to the HID Portal. This could be avoided by using a microcontroller that has SPI or I2C built in already, but the JB8 is what I had on hand.
I use three signals to communicate with the CUBLOC controller. First, there is a CLK signal. The HID Portal detects a rising edge. At that point, it reads the value present on the DATA line. This is shifted into a register until a byte has been received, and the code moves to the next byte. The /RST line is a way to synchronize the start of each data packet in case there was any spurious input; when LOW it sets the packet and bit indexes to zero.
The HID Portal is currently programmed to act as a joystick with three axes and eight buttons. I’ve also tested it as a keyboard. In future development, I’d like to make the HID Portal more flexible; let the external controller select the device type and how many of each input are required. It would be the most flexible if it directly accepted HID report descriptors, but that opens up the possibility to make more mistakes and end up with a non-working device.
The accelerometer is a DE-ACCM3D from Dimension Engineering. The CUBLOC simply reads the voltage on its ADIN ports and converts to a value between -127 and 127.
Continued on Next Page