Hey, this should also work on a CM Storm Quickfire Rapid (really fast, gogogo, super speed) model.
The mounting pins would need to be identical. And the matrix would need to be very close to identical for it to work at all. If that is not the case there is still the option to build a cruder version, using just a regular Teensy plus some multiplexing component to expand the number of IO lines. It will be more or less exactly the same thing.
You know, it's been so long since I had my Filco apart that I don't recall what it looks like... I'm ASSuming that the controller for a std. ANSI 104-key board is completely different and therefore I have no use for this controller?
No, the full size boards have another daughter board. It uses the same controller but is totally different. Actually harder to fit an ATmega onto I think. Unfortunate since I am a full size proponent myself..
I'm a little confused on how this works. How is the reprogramming done? [Yes, I've searched and haven't found much.] Is a firmware rebuild and reload required? I'm a software developer and don't mind tweaking and rebuilding firmware... just like to know what's involved before I commit.
Definitely interested in at least one unit if the programming/load process isn't too difficult.
You will need to have a hex-file, a compiled firmware, that is loaded to the chip through an interfacing software on your computer. With the Teensy this is done with their own TeensyLoader. With the stock Atmel or open source LUFA bootloader there are different programs. I've tried the Linux ones and got that working just fine. I still need to try on Windows, but that should be no problem either.
There are several other keyboard codes written for the Teensy controller. They should all be pretty easily adopted to run on this. The basic idea of a keyboard firmware is:
- Read all keys
- Decide if anything changed, not only chattering (debouncing)
- Decide what keyboard presses to send to the computer.
To do step one the controller needs to know which pins are connected to what in the keyboard matrix, a grid of keys and diodes. All Cherry switch matrices are basically the same. So the big difference between different keyboards is just defining which pins to send probing signals on, and which to scan to read pressed keys. This should be quite straight forward to change since it should be a separate section of the code in a good software design. This should also only need to be done once for each firmware code.
Step three really is where the magic of using a programmable controller comes in. "Ah, so Scroll Lock is pressed. Then I will send these other key presses as numpad keys instead of their usual identities.", or in whatever way you can think of (down to what is possible to do purely programming wise, and that is a lot).
I will load some basic firmware onto the controller before shipping. Probably just something that mimics the original controller.
you think you can get it down to 20$ stuffed/unit?
I want to get one or two. Is $20 including components or just the PCB?
This is nothing like ordering a mega large keyboard PCB. It is ~ 2.2" x 1.3", they are super cheap =D I still sort of haven't factored in shipping from China, but with these amounts that should divide down to manageable amounts. The ATmega is the only expensive component at ~$6