I2C Keyboard/Mouse?
jazzed
Posts: 11,803
Has anyone tried to implement a Keyboard/Mouse interface via an I2C device? I'll try this soon using a small/cheap micro-controller as the I2C device interface (atTiny85).
Considering the built-in nature of I2C for Propeller such an interface seems natural. I'm thinking the Propeller object would poll the I2C device for keystrokes or mouse events using a COG and could also provide EEPROM device support. Any thoughts?
Considering the built-in nature of I2C for Propeller such an interface seems natural. I'm thinking the Propeller object would poll the I2C device for keystrokes or mouse events using a COG and could also provide EEPROM device support. Any thoughts?
Comments
I really like Peter J's idea (I think it was his) of Obex objects that include the attiny "firmware", so end users don't have to get involved in another programing environment to make it work. I'm not sure whether the i2c pins you have chosen are the same that normally program the attiny. I'm trying to do something vaguely similar with Cypress PSoC at the moment, and one of the reasons for selecting Cypress was programming (as well as runtime data) over the i2c interface.
Given that in this case the keyboard and mouse are fairly fundamental interfaces that people have come to expect to be there, as on demo boards etc, and the atTiny devices are so small perhaps it's better to have them permanently programmed rather than have dynamically loadable firmware.
Is it possible to program them via the I2C from the Prop with a Spin application run once when the board is constructed?
Dynamically loaded firmware might be interesting for other uses. But I'm starting to worry about Zog which now has binary blobs of firmware to load into Cogs, for FullDuplexSerial for example. Having to manage firmware for external devices as well is getting to much for me to think about.
I often thought about lumping an AVR onto the Prop as an A-D. Sounds a bit like a Cameleon (if I could spell it)
Dare I say it, like this ATmega328 from SparkFun with an Arduino boot loader pre loaded. http://www.sparkfun.com/commerce/product_info.php?products_id=9217
Which I start to think is not such a bad idea. It gets back use of a bunch of I/O lines that are used up in the Prop with the SDRAM interface that Jazzed wants to build. Provides A to D.
Also one could work this the other way round, use the AVR as the boot EEPROM for the Prop!
On the other hand it is quite likely that ZOG is going to sprout some Arduino compatible libraries and the same "sketch" style API. So why not have more of the same "out there"?
I'd love to see a really cheap I2C kb/mouse/etc controller!
I built the RamBlade with an option to use a PIC10F2xx 6pin SOT23. I was thinking to load a minimal prop boot code and possibly use it for a keyboard interface. I never did test any of it. I think there may not be enough Flash for the minimal prop boot code.
As for the keyboard, I would suggest that it may be better to just make a keyboard to serial (output pin only) chip. I guess it depends on whether you want to have other I2C chips on the bus.
However, wouldn't the easier way be to bight the bullet and use 2 props so that if/when we get the Prop 1.5 we can just use it instead??? Of course the second prop gives us access to the USB devices using the new non-compliant drivers .
What I would really like to find is a <$2 micro chip (including internal xtal) that can do USB OTG to replace the expensive FTDI chip. Those chips bug me the most about cost.
Why? Because it can share the eeprom I2C pins!!!
Re/USB
I've had PIC18F14K50 dev kits here for over a year, just no time to use them, intending to use it as an FTDI replacement. GG has a stick to do that now. The smaller memory version, the PIC18F13K50 is just under $2 in quantity! Note, this does not have USB OTG.
As far as a second prop goes - that would be a great solution, except for the price of Prop's. A lot of people simply do not understand the costs involved, and complain about pricing.
Bill: I'm inclined to a agree. A DIP 8 AVR on the I2C pins would be just fine.
Can we skip the PICs? I have an ulterior motive. Somewhere I have an AVR USB serial programmer built from just an ATMEGA8. It's about the first and last AVR project I got working before the Prop hit me. Never had any luck building a programmer for PICs. Also it's dead easy to code for AVR using GCC under Linux.
(I Think, ......... I'll just pop out and purchase a tin hat)
Re/ PIC's... sooner or later I may play with my PIC18F14K50's for USB->serial, but I have to finish all my new products first...
Btw - Happy Birthday!!!!
I agree about the painful pitch of the FTDI parts; but the price is awful too...
I see no reason to use the Arduino tool chain for what would be a simple I2C kb/mouse interface. Either AVR assembly, or GCC-AVR would be plenty, and besides - the Arduino Wiring extensions don't really suit writing such a driver.
twitch... twitch...
Actually, I love the idea of using some of the alternatives to do Propeller dirty work as in this case driving a keyboard/mouse. Am I going to have invest in some new programming tools to play?
OBC
Having an I2C keyboard/mouse device can serve the Propeller community well.
My primary motivations for choosing the AVR PDIP8 atTiny85 are:
1) To preserve the I2C bus for additional I2C devices.
2) AVR I2C device comm is faster than the Propeller equivalent.
3) I know AVR ASM ... I've never programmed a PIC.
4) PDIP8 atTiny85 are $1.82 each at mouser for 1 ($1.39 for 10).
5) Having exactly 6 IO's for the job seems to be a perfect fit.
6) If necessary, the code could be leveraged for bigger devices.
7) Could be a way to add other features simultaneously like ADCs.
I understand the desire to use a Propeller for this purpose and it is possible.
My first I2C keyboard/mouse design will be on a 32MB SDRAM GG board
that will allow a Propeller Computer using the GG PropellerPlatform SD.
Later I may offer a single board version with the same feature-set.
As you can see, there's no room for another Propeller on the 32MB SDRAM board.
@OBC, I could send you new chips
In the spirit of our community though, I think open source makes sense.
I would prefer a way to program a device in circuit from a Propeller.
Meanwhile, here's a programmer from SFE that uses an RS232 interface.
http://www.sparkfun.com/commerce/product_info.php?products_id=33
Unfortunately, a programmer cable is also needed for that.
The STK200 which I have is probably a better option because it comes with
everything you need to program just about any AVR and is listed at about $70.
http://www.kanda.com/products/kanda/STK200.html
Cheers.
--Steve
OBC, yep, using 32 bit COGs on things like keyboards/mice has always made me feel uneasy. Having a little DIP do that ans using a COG to drive it which can also be used to access EEPROM seems great.
I made an AVR programmer from an ATMEGA8, a USB socket, an XTAL and a bunch of resistors. From this design http://www.fischl.de/usbasp/ Which is in turn based on this USB stack for AVR http://www.obdev.at/products/vusb/index.html Which in turm means we can unload slow speed USB stuff to a dinky AVR as well
Anyway, What's wrong with the Wiring library? Whats 1/3 of a Gig beteen friends? (at least it is a mere fraction of the Xilinxs stuff !!!)
Wow that Dragon board looks great with full emulation and USB power
PonyProg looks interesting. How hard would it be to come up with a PropPlug compatible programmer schematic for atTiny85? I see there is a 4MHz crystal on the PonyProg schematic; is that necessary for programming? I'm a little concerned that the RST* function PB5 fuse has to be cleared to allow general purpose input ... if the fuse remains set can PB5 be used as an output? Wrong forum for such questions I guess
Thanks,
--Steve
If you are going to incorporate an AVR or something into your design, would it be possible to incorporate an IR or BlueTooth boot loader that programs the propeller as soon as it receives a prop image an a checksum. This could elinate the need for the ftdi chip and the eeprom, and allow us to program the propeller from our smart phones!
just throwing in my 10 bits
Doug
I built the combined Interface bit and the 8, 20, 28 and 2x 40 pin bit. The 4MHz xtal is there for when you are reprogramming chips that have the fuse bits set for external xtal. I have put an osc block on as well so that option is covered too.
People wish for fuse bits on the Prop, they are a right pain on the AVR. They are set when they are low, designed to confuse the stupid ......
http://www.circuitdb.com/circuits/id/216
Sure I've got a handful of "dead" AVRs that would be usable here if not for the fuse bits.
When I tried high voltage programming on a Prop ......
hinv: WOW - I never realised they were still using DIP chips in keyboards still. Well my latest keyboard (USB & works as PS2) is still oldish. It has a small single sided pcb and 8x18 input scans and 3 Leds. This is the best solution I have heard in a long time
BTW I could fit ~3 x RamBlades in there
Only problem is going to be each keyboard will have a different pcb and connection no doubt :mad:
A multi-propeller GadgetGangster module might be interesting to explore. A ring topology could be easily done by cross connecting serial links between boards to allow N connections. You could probably get 8 Propellers on a 2 sided GG module. That would allow Humanoido's tower to contain as many Propellers as his power supply could support before toppling over or dimming the lights.
Back to the prop in a keyboard -A single sided pcb with a DIP prop would work in the keyboard I opened. Wonder how many keyboards use a similar pcb?
What about the $2 bluetooth modules? Could use a network of props with bluetooth modules (one in the keyboard). Has anyone overcome the fixed address in those $2 bluetooth modules???