geekhack
geekhack Projects => Making Stuff Together! => Topic started by: chrisandreae on Tue, 04 December 2012, 06:11:27
-
The version of the firmware in this post has been superseded by a later version with Ergodox support added and a new GUI, described here (http://geekhack.org/index.php?topic=56923).
I've implemented a very full-featured open source microcontroller-based programmable USB keyboard firmware.
In its current incarnation, it provides a drop-in replacement for the main microcontroller of a Kinesis. I have schematics and software versions supporting the Kinesis Advantage, Professional, and the two-PCB version of the Model 110. It has been designed to be easy to customize to any keyboard with a known matrix layout.
The firmware provides the following features:
- Full key-rearrangement programmability, including support for a "keypad layer".
- Built in layout profiles to save/restore up to ten separate programmed keyboard layouts.
- Configuration and programming over USB with a GUI client.
- Enhanced macros that fully support modifier keys within macro sequences, and can be triggered by any combination of up to four keys.
- Built in mouse-keys in keypad layer.
- Built in virtual machine capable of running up to six concurrent programs written in a custom bytecode (compiler included)
- Multi-tone audio support using the internal buzzer, accessible from the VM
[attach=2]
The firmware is written to support both software USB with the V-USB library and hardware USB with LUFA. However, only the V-USB implementation has been recently tested, and the configuration over USB functionality is included only in the V-USB version.
My reference designs use an Atmel ATmega32 microprocessor. They're designed as mostly-single-sided PCBs for fairly easy home etching and assembly.
[attach=1][attach=3]
[attach=4][attach=5]
The firmware and schematics can be found on GitHub at https://github.com/chrisandreae/kinesis-firmware, under a GPL license.
(Moderators: please feel free to move this topic to the Making Stuff forum if it would be more appropriate there)
-
Okay, now, how much would it cost me to ship a Kinesis Advantage over to you for modification? :D (I don't know the first thing about soldering...)
-
Unfortunately it probably would be fairly expensive to ship back and forward to me - I live in New Zealand. Also I'm still etching and assembling the boards by hand, which is a fairly time consuming process, so I'm not in a position where I can produce large numbers of them for people. It'd probably be better to get in touch with someone local who could help guide you through the process, perhaps at a local makerspace?
-
Sound like a very complete solution. I am intrigued by your addition of an on chip virtual machine. What sort of programs do you envision this being used for? Based on the set of built-in functions in the system library, I could see it being used for multi-key mappings.
Thanks for sharing this, it must have been working on this for quite a while.
-
Mostly it was just for the fun of the exercise of writing a compiler and VM. So far, the only real program I've written is a joke to watch your keystrokes and play the Tetris theme tune if you happen to type "tetris".
But more realistically, I can imagine using it for gaming, to create macros with precise delays or conditions - perhaps to navigate a character in a pattern, or use a sequence of abilities, or maybe to create a rapid-fire key/mouse button like an old 'turbo' joystick. More generally, maybe for a key that performs one action on press and another on release? I'll look forward to seeing what other people make of the functionality. :)
-
Is there a function to add PS/2 support to Topre keyboards since Topre is to cheap to do it themselves?
-
Is there a function to add PS/2 support to Topre keyboards since Topre is to cheap to do it themselves?
Currently the controller only provides a USB keyboard. It would be certainly be possible to rewrite it for PS/2 communication, but it's not something I was planning.
-
Wow, great job! This looks like most full-fledged and multifunctional open source firmware I have ever seen before.
Macro and programmability via VM is just what I've wanted to add to my keyboard. I should look into your code of stack machine and learn how you realized these interesting features.
Thanks for publishing your great code!
-
I've been thinking more about Biternk's question: if I were to have a larger numbers of boards made and fully assembled, how many people would be interested in purchasing them as solder-free drop-in upgrades, and what would be a reasonable price to pay for such a thing? Additionally, are there any other keyboard models that people would particularly like supported?
-
Filco, QFR
-
how about something for the buckling spring fans?
i am not sure if you are familiar with IBM/Lexmark/Unicomp keyboards, but they have a distinctive sound and feel. but the buckling spring is just a transfer mechanism - the switch is actually a membrane in a model M. mkawa started a thread Project: SSK revival trying to build a 10keyless from new Unicomp parts.
like all membrane keyboards, the model M is 2kro. i made a suggestion to replace the bottom sheet of the membrane sandwich with very thin PCB and use a diode for each key. this will need a new controller of course. could i send you some drawings?
-
like all membrane keyboards, the model M is 2kro. i made a suggestion to replace the bottom sheet of the membrane sandwich with very thin PCB and use a diode for each key. this will need a new controller of course. could i send you some drawings?
Sure. If you're designing your own matrix, it should be very easy to take advantage of my controller. Send me a PM with details if you would like a hand adapting it.
-
(http://i.imgur.com/Mq6XN.jpg)
I'm wondering if you think your controller may be a suitable replacement for the one on this older WYSE terminal board I'm trying to get up and running. I tried working with Soarer's converter, but it seems the data line is dead or needs the original terminal to function properly, so I'm trying to figure out what the best thing to replace it with would be.
This thing is amazingly well built and it would be a shame to trash it or just use it for parts. :)
-
If you can access the keyboard matrix directly on the PCB, and are willing to spend some time with a multimeter to map it out, then the software should be pretty straightforward to adapt to the different matrix layout.
One factor that you might care about is that the Kinesis's matrix has built-in diodes, so I haven't bothered to include any software handling of masking/ghosting. If your keyboard doesn't include these then you'd need either add diodes, extend the firmware, or put up with masking/ghosting effects.
-
It is very straight forward to map a matrix layout using a Teensy++ (or something similar). Just hook it up to the matrix lines by the controller. Load a program that simply scans all pair of ports to see which are connected. Hit every key and have the controller print what it sees. You may need to go a little bit slow since the scanning is done really brute force. I had a picture from me doing it to a Filco, somewhere...
Edit: found it =)
(http://geekhack.org/index.php?action=dlattach;topic=34392.0;attach=2190;image)
-
The HumbleHacker (http://www.humblehacker.com/keyboard/) firmware has a mapping tool as part of it so you can be super lazy ;)
-
I've implemented a very full-featured open source microcontroller-based programmable USB keyboard firmware.
I request 2 new features:
1. PS/2 support. So I can program the keyboard with all my special settings via USB and press save. Then take keyboard to PS/2 computer and plug it in and it works. This is needed for a wide variety of reasons. For example all retrogamers can only use PS/2 keyboards on their computers, not USB. There are thousands of great old Amiga games from 1980s and 1990s freely downloadable on the net all fully compatible to PS/2 keyboards and mice. But trying to run USB keyboards and mice on an old 50Mhz computer ruins the game by bogging down the CPU. PS/2 FTW!
2. Independent Repeat Speed and Repeat Delay for every single key. Sometimes gamers need a certain key to start repeating instantly and rapidly every time they touch it. If gamers could tell their controller that the (for example) q key has a 0 repeat delay and high repeat speed, then pressing the q key down for 0.5 seconds would send many KEYDOWN KEYUP events to the computer. Awesome!
-
Sorry if my questions are noobish...its because they are.
1. Why are you inserting two boards and replacing the old usb-cable? I would have imagined one would suffice.
2. From the pictures it seems like you are just tapping into the pins of the old controller(marked 3-9-03 USB), is that correct?
3. If so, have you taken any steps to deactive the old controller?
Thanks
-
I request 2 new features:
1. PS/2 support. So I can program the keyboard with all my special settings via USB and press save. Then take keyboard to PS/2 computer and plug it in and it works. This is needed for a wide variety of reasons. For example all retrogamers can only use PS/2 keyboards on their computers, not USB. There are thousands of great old Amiga games from 1980s and 1990s freely downloadable on the net all fully compatible to PS/2 keyboards and mice. But trying to run USB keyboards and mice on an old 50Mhz computer ruins the game by bogging down the CPU. PS/2 FTW!
I see the value in that, but it's not something I'm particularly keen to work on myself. If someone were interested in forking to provide that functionality, it wouldn't be particularly difficult - the main work would be rewriting the key state management to work in terms of state change events rather than current state reports.
2. Independent Repeat Speed and Repeat Delay for every single key. Sometimes gamers need a certain key to start repeating instantly and rapidly every time they touch it. If gamers could tell their controller that the (for example) q key has a 0 repeat delay and high repeat speed, then pressing the q key down for 0.5 seconds would send many KEYDOWN KEYUP events to the computer. Awesome!
The firmware already supports this using the programming language feature. For example, you could write the program:
void main(){
while(checkPhysKey(0)){ // as long as the key that triggered the program is still pressed
pressKey(0x04); // press 'a'
releaseKey(0x04); // release 'a'
delay(50); // and wait 50 milliseconds
}
}
(Actually, this use-case reveals the need for a way to obtain the keycode associated with a currently pressed key from a program, which I'll try and get around to at some point. The library available to the programmed macros is pretty rudimentary at the moment, and deserves quite a bit more work.)
-
Sorry if my questions are noobish...its because they are.
1. Why are you inserting two boards and replacing the old usb-cable? I would have imagined one would suffice.
A couple of reasons. The largest reason for using two boards is physical space inside the keyboard: the cylindrical cut-out at the bottom of the keyboard (where the USB cable comes out) sits immediately above the microcontroller socket, and seriously constrains the possible size of any board that connects directly to that socket. In fact I have to slightly trim the internal plastic to even fit the small board pictured. (This issue could be fixed by designing a double-layer board with a smaller footprint) My first prototype was a single board like that, which required me to cut an unsightly hole in the bottom of the keyboard to fit it.
Other relevant information: the original microcontroller appear to actually be (mostly) a PS/2 keyboard: USB is provided by the PS/2-to-USB converter daughterboard (the part with the built-in USB hub). This is why I can't take advantage of the existing USB hub and the cable between that board and the mainboard: it simply doesn't provide USB.
2. From the pictures it seems like you are just tapping into the pins of the old controller(marked 3-9-03 USB), is that correct?
3. If so, have you taken any steps to deactive the old controller?
The old controller is removed from its DIP socket completely, and my board replaces it.
-
Thanks for your speedy answers.
Will probably take me a while to implement it.
Programmer by trade, but I know next to nothing about electronics...
-
Just saw this, nice! I wonder if this firmware works on the Ergodox keyboard (teensy 2.0) and how the two firmwares compare!
-
So after a month or so I'm finally back up to speed with my kinesis keyboard and my wrists feel so much better. Only problem is that my extensive keybinding changes to slickedit don't really translate so well to the kinsesis layout. I was hoping that any of you out there who also use a kinsesis wouldn't mind sharing any tips or keybindings that you find useful/comfortable.........
-
Based on two years of research the Kinesis contoured keyboard was designed not only to reduce the known risk factors associated with repetitive stress injuries but also to provide a more comfortable platform than other keyboards. Its unique contoured design reduces the force and stressful postures that contribute to discomfort and limit productivity. Since its introduction in 1992, the Kinesis keyboard has undergone extensive independent testing and has proven superior in both comfort and productivity against traditional and other alternative keyboards.
-
Yes, it's really good, but there's always room for improvement. In fact Kinesis themselves are soliciting input for their next generation contoured keyboard in this thread, under their own forum:
http://geekhack.org/index.php?topic=36195.0
-
Awesome work on this Chris
I have 2 Kinesis advantages so I hope to be able to get this firmware on at least one of them.
I also happen to live in New Zealand (Wellington) so I am wondering whether the board was self made of manufactured (apologies if this is explained elsewhere)
In case it it of interest my potential use case is that I have quite bad RSI/OOS in my wrists as well as rather lazy typing habits,
I hope to be able to modify the firmware in some way so that I can encourage better habits (or at least track my habits)
For example I commonly will do a combos that are quite uncomfortable:
windows-key (left thumb) and 1 (left ring finger)
shift (either left pink or thumb depending) and a 4 (left index)
I hope to alleviate this by not recognising problematic combos where the modifier and key are pressed with the same hand.
Thanks for the great work,
From a fellow Chris who also happens to live in New Zealand
-
Hi Chris, thanks for the interest! The boards were self-made, but I imagine that with a little time the Eagle files could be cleaned up to get the PCBs properly manufactured. Alternatively, it would be possible to jury rig a commercial board such as a Teensy to connect to the Advantage's microcontroller socket. (This would give the additional advantage of hardware-based USB, but would require bringing the somewhat neglected LUFA-based USB core in the firmware up to date (lufa/lufa_main.c)).
Modifying the firmware to perform extra actions on specific keyboard combinations would also be fairly easy. For a really quick hack, you could just toss handlers into handle_state_normal() in keyboard.c, otherwise you might want to look into using programmed-macros for the feature.
Unfortunately, I'm not in Wellington any more, otherwise I'd offer to help you build one. In the last couple of months I've moved to Tokyo for a new job, which has somewhat reduced my available time for hacking on the keyboard project.
-
Just saw this, nice! I wonder if this firmware works on the Ergodox keyboard (teensy 2.0) and how the two firmwares compare!
Should work with a bit of porting - would need to:
- Add a hardware mapping for the Ergodox' matrix layout
- Bring the LUFA based USB core up to date - I haven't used it since switching to software USB on cheap ATmega32s, so it'll need some changes.
- Either add some external eeprom storage for programs, or disable the uploadable program feature
- Add a buzzer, or disable the buzzer feature
-
I also happen to live in New Zealand (Wellington) ...
For example I commonly will do a combos that are quite uncomfortable:
windows-key (left thumb) and 1 (left ring finger)
shift (either left pink or thumb depending) and a 4 (left index)
I have the same problems as you with same-hand multikey combos. And I used to have a coder friend who lived in Wellington. Small world :)
-
Hi Chris!
I can see that your design involves a PCB plugged into Kinesis panel...
Would it be possible to replace just the firmware in the AT89S8253 chip?
They are both Atmel... am I missing anything?
Thanks!
-
I can see that your design involves a PCB plugged into Kinesis panel...
Would it be possible to replace just the firmware in the AT89S8253 chip?
They are both Atmel... am I missing anything?
Potentially, but it would require a rather different approach. First of all, the AT89S8253 is 8051 architecture rather than AVR, so significant porting would be required. Second, the Advantage seems to be internally implemented as a (mostly) PS/2 keyboard behind an internal USB-PS/2 adaptor on a daughterboard. So in order to make no hardware changes, you'd need to implement a PS/2 firmware plus any additional proprietary internal features required by the USB daughterboard (notice for example there's an extra connection labelled 'USB' between them, which presumably serves some purpose).
-
Potentially, but it would require a rather different approach. First of all, the AT89S8253 is 8051 architecture rather than AVR, so significant porting would be required. Second, the Advantage seems to be internally implemented as a (mostly) PS/2 keyboard behind an internal USB-PS/2 adaptor on a daughterboard. So in order to make no hardware changes, you'd need to implement a PS/2 firmware plus any additional proprietary internal features required by the USB daughterboard (notice for example there's an extra connection labelled 'USB' between them, which presumably serves some purpose).
Ah! Immediately after posting I realized that AT89S is not the same as ATMega, and now turns out these are different families altogether.
I totally missed the part about USB to PS/2 bridge.
Still, I am feeling adventurous enough to port your code to the native CPU, or at least some USB-enabled 8051. I am a decent C programmer, and even was, years ago, taught to code for Z80, but I have next to no experience with embedded systems. Would you be so kind to point me to some resource explaining the basic setup for programming a microcontroller? I imagine I would need a flash programmer, compiler tool chain, debugger, perhaps an emulator... what else?
Thanks!
-
Can this GUI and firmware be implemented and programmed on a Mac computer?
And yes, the Advantage is a PS/2 keyboard mainboard with a PS/2 to USB active converter provided by Pi Engineering. The next incarnation of the Kinesis is supposed to be USB native.
-
Still, I am feeling adventurous enough to port your code to the native CPU, or at least some USB-enabled 8051. I am a decent C programmer, and even was, years ago, taught to code for Z80, but I have next to no experience with embedded systems. Would you be so kind to point me to some resource explaining the basic setup for programming a microcontroller? I imagine I would need a flash programmer, compiler tool chain, debugger, perhaps an emulator... what else?
Pretty much as you described, except for the level of frustration potentially involved in getting your hands on them and their documentation. AVRs are well-beloved by the hobbyist community, so there's no end of resources available - guides, libraries, free compilers, large variety of cheap parts (flashers, debuggers, microcontrollers) available on eBay and so on. From a quick Google it looks like the support you want is there, but a little more awkward. Have a look into SDCC for a compiler toolchain. You could consider getting started with a development board kit like this one http://bit.ly/ZpzmU8.
-
Can this GUI and firmware be implemented and programmed on a Mac computer?
Yup, I work on a Mac most of the time. The current GUI requires Ruby and GTK from Homebrew, but there's a nicer QT GUI in the works that will build directly to a native Mac application.
-
Still, I am feeling adventurous enough to port your code to the native CPU, or at least some USB-enabled 8051.
Did you try to port it yet?
-
So in order to make no hardware changes, you'd need to implement a PS/2 firmware plus any additional proprietary internal features required by the USB daughterboard (notice for example there's an extra connection labelled 'USB' between them, which presumably serves some purpose).
If they use some proprietary extension of PS2 there there may be a problem. I believe the extra connection marked MPCUSB is just an access to Scroll Lock key when the main board is powered down. Just a speculation - looks like a way to wake up the main board when it is powered down and user presses Scroll Lock. On keyboards without the white relay MPCUSB is not even connected.
It would be interesting to test whether it would work when the main board is disconnected from the PS2-USB converter and we would connect some standard PS2 keyboard to the daughterboard converter.