@parak/kps: You guys make it sound so hard. The Teensy library documentation[1] makes it sound easy. Which makes me feel naive, lol. What am I missing? The only problem (if it is one) that I can see is that this might only give us 6KRO without a lot of work.
( Some relevant stuff i found, just to put it here. Sorry if everyone already knows:
- NKRO is possible with USB, but not common: geekhack.org/showwiki.php?title=USB+versus+PS+2#Full+NKRO
- Phantom firmware. I thought it was NKRO, but the post says it's 6KRO, so I'd have to read/learn more to figure it out: geekhack.org/showwiki.php?title=Island:26742
)
[1] pjrc.com/teensy/td_keyboard.html (with something to handle I²C) in C, or pjrc.com/teensy/td_keyboard.html and pjrc.com/teensy/td_libs_Wire.html in what looks like C++
((sorry for the links, i can't post real ones yet))
EDIT:
Don't mean to clog the thread with dev stuff. Please let me know if there's another place I should put it.
I'd say that any development ideas you have are okay is this thread. I certainly find them more interesting than checked interest
So there already exists I2C for Teensy? I should have known. Looks like almost everything's been done on ATmega.
About #KRO: The Teensy supports NKRO logically, so it can recognize all the keystrokes, and keep them separate. As far as I know, the reason USB is usually 6KRO is due to bandwidth limitations, and it functioning on USB 1.1 for legacy (BIOS) purposes. There exists an implementation of NKRO over USB on the Teensy (see soarer), but I'm not 100% sure how it works out with the necessary bandwidth. My assumption has always been that it detects something from the computer and is only 6KRO (and slower) when it needs to be, then changes back to NKRO once it's into a full-OS, but I really have no idea.
See, I'm no EE, so I'm relatively new to this embedded system stuff. Also, I don't have a TEENSY, so I can't hardly breadboard an I2C solution.
---
Should I come up with a "roadmap" of stuff that needs to get done? I figure, if I do that, then people can tackle each bit, and we'd get more done faster. Like we could get the CAD files, and some people can talk to local machine shops. We can get someone working on implementing i2c as communication between the halves. We can get someone looking for solutions for the connector problem (either an easy cable for I2C or a larger one for passing the matrix) etc. Then we can have a list of design decisions to be made (fer example, number and placement of thumb keys, etc.)