Main > Main Forum
Control to interpret speed as axis/button? (pedal to play!)
Derrick Renaud:
Hmm...
Playing Lunar Lander on a bike that you have to pedal faster for more thrust.
Interesting.
D.
vputz:
--- Quote ---Playing Lunar Lander on a bike that you have to pedal faster for more thrust.
--- End quote ---
Hmm--I guess maybe there are some arcade games that this could work for.
At any rate, I may have a partial answer along the lines of MonMotha's suggestion; a fellow has already done the bulk of the "use an AVR as a USB HID device" work (http://www.mindaugas.com/projects/MJoy/), so using that software as a starting point it should be possible to add in some code which treats the encoder as a speed input (or at least calculates speed to use as an input) and do the other logic. I've written him to see if that sounds reasonable. Of course, there's still the "learning how to program the AVR chips" problem, but now that I know what's possible, I really must learn; it sounds fun and can't be any worse than writing my "SpaceOrb HID device driver" experiment (lol).
Hmm. I'm very intrigued now.
MonMotha:
I'm curious why they used an ATMega8. Atmel sells devices designed specifically for USB (the cool thing is that you can program them over USB, too). I'm guessing those parts weren't out when that design was done. I'd be interested to see how they're doing the USB on there...people don't usually bit-bang USB (it's electrically difficult to do other things as well). His FAQ addresses this somewhat, but I know digi-key carries many of the USB Atmel chips (as well as the Cypress ones). If you only want one, you'll get hit with a $5 handling fee, but that isn't too bad. Seeing as how I know of no places near me that sell anything that new anyway, I'd be stuck mail ordering things no matter what. If you're really nice, you can usually get Atmel to give you freebies.
You should be able to add thresholds for the analog inputs fairly easily. Just make the USB enumerate with a 2nd function of a keyboard (if it isn't already) and simulate keypresses. Rotary/Optical encoders are pretty easy to deal with: they just output two waves in quadrature that lets you tell which direction it's being rotated. You can then use a timer (ATMega has tons) to determine how fast the pulses are flying by and calibrate that to speed (basically, just count the pulses between timer events and divide by the time elapsed, then apply a linear calibration curve). You could then map that either to an axis or again do thresholds and keypresses.
AVR is a pretty easy arch to work with. The instruction set is pretty nice, and C compilers are readily available (gcc targets it, for pete's sake). If you have a flash based device, you could set it up so you wouldn't even need special drivers other than for programming thresholds or recalibrating speeds (like if you changed wheel diameter or gearing ratios).
vputz:
Probably right as to why the AtMega8 (he has a board which uses the AtMega16, though). Problem is, I'm way way at sea with this so hesitant about jumping to a new part without guidance. Maybe the folks at avrfreaks.net would be able to help... not sure there.
The problem with USB devices "programmable over USB" is that then I would think you'd have the "is it a programmable chip, or is it a hid input device?" problem, ie if it's acting like a HID device, wouldn't you then be unable to program it?
Any pointers on the Atmel USB parts, even which ones you mean? I'm probably going to have to go through Digikey myself (not positive, but it's very likely), so the mail-order aspect doesn't bother me (I'd probably buy at least two for when I fry the first one trying to make a programmer circuit).
But yes, that's the idea--a flash-based beastie. If I could, I'd like to enable it to recieve HID packets from the computer side and use that to change thresholds/speeds (I arranged my SpaceOrb driver to do that--a user-space program would forward a HID packet of some sort, can't remember the name, to the device, which would then alter its messages in response--for calibration and the like).
Grr... software guy. I fear circuits. This'll be a fun learning experience, though.
MonMotha:
Atmel has a wide selection of USB enabled microcontrollers, both AVR and 8051 based. The AVR devices, while probably easier to program, are only available in "really tiny" packages (like QFN or TQFP). The 8051 devices are available in PLCC or, probably even easier to work with, SOIC.
These can all take a command over the USB control endpoint to accept a new firmware download, and of course software on the device could accept commands to program new thresholds and such. I know the 8051 devices can reprogram their own flash via internal firmware, and I'm guessing the AVR devices are similar. Unfortunately, most of my experience is on 8051, not AVR (though I'm looking at doing a new product using the AVR series - the instruction set is nicer and performance is higher, not to mention they have some REALLY TINY devices).
The ATMega with bit-banged USB should be able to be programmed in a similar manner. My only issue is handling the electrical characteristics of USB correctly. That's not easy to do with general purpose I/O pins (though it is quite possible) - I'm surprised they didn't use a device like the Fairchild USB USB1T11A to handle that for them.
If you want to really homebrew a solution, there are also USB chips from Cypress and Microchip. Cypress is on my baddie list due to EOLing a product with no warning, and I've hear that Microchip's USB enabled PICs are buggy, but YMMV. I've used the older Cypress devices extensively, and they do work well. I'm currently looking at the Atmel AT89C5131A-L and AT90USB646 (there's a version with 128k flash, as well) for a new product since Cypress pulled a no-no. The former is an 8051, while the latter is an AVR. The AVR version also has 8 channel 10-bit A/D, but is only available in small packages :(