geekhack
geekhack Projects => Making Stuff Together! => Topic started by: chrisandreae on Wed, 09 April 2014, 01:43:15
-
I've extended my previously announced (https://geekhack.org/index.php?topic=37991.0) USB keyboard firmware to support both Ergodox and Kinesis.
Hardware currently supported:
- Kinesis Contoured (Advantage, Professional, Model 110) with drop-in microcontroller replacement (see schematic/ directory)
- Ergodox (with native Teensy - no hardware change required)
Can support most ATMega series AVR microcontrollers, using LUFA if native USB is available and VUSB otherwise. Using the macro and program-interpreter features requires an external AT24C164 or compatible I2C EEPROM. (This EEPROM is already built in to Kinesis Advantage/Professional hardware.)
Features
- On-the-fly reprogrammable keyboard layout, including 'keypad layer' support (two independent key layouts toggled by a 'keypad' key).
- Onboard layout profiles to save/restore up to ten separate programmed keyboard layouts.
- Enhanced text macros that fully support modifier keys and can be triggered by any combination of up to four keys. (requires external EEPROM on Ergodox)
- Virtual machine interpreter that allows complex interpreted macros to be written in a simple programming language. (requires external EEPROM on Ergodox)
- Programming, macro recording and layout save/load can be performed entirely on-keyboard with no additional software.
- USB API for configuring, remapping and uploading programs to the keyboard. (C++ GUI client and Ruby library included.)
- Also appears as USB mouse, mouse functions can be be bound to keys.
- Multi-tone buzzer audio support (included in Kinesis hardware)
Pictures
GUI client
[attach=1][attach=2]
Optional external EEPROM on Ergodox
An EEPROM can easily be attached to the I2C bus in the spare space on the non-Teensy side of the keyboard:
[attach=3][attach=4]
Kinesis Hardware
The Kinesis board uses the easy-to-find Atmel ATMega32 microprocessor. There are two revisions of the hardware: the first is a mostly single-sided PCB which can be easily etched at home, the second (v2.5) is a double-sided PCB suitable for professional manufacture. If you want to order boards easily, I've uploaded them to the DirtyPCBs store here (http://dirtypcbs.com/view.php?share=3735&accesskey=8e7001099151c3af43b29427c8f369a0). (Full disclosure: I get a $1 credit each time the board is ordered using this link.)
[attach=5][attach=6]
The firmware and schematics can be found on GitHub under a GPL licence:
https://github.com/chrisandreae/keyboard-firmware (https://github.com/chrisandreae/keyboard-firmware). Binaries ready to flash and go are found here (https://github.com/chrisandreae/keyboard-firmware/releases/tag/1.1.1).
-
Sounds great!
Do you have any plans to extend it to Maltron?
-
Do you have any plans to extend it to Maltron?
I don't have a Maltron to play with, so I can't do it myself, but the firmware's easily extensible to other keyboard hardware if you know the matrix layout (pretty easy to work out) and don't mind designing a custom circuit board.
-
Ooh, on-the-fly programming...
Can hardly wait to check it out on my Ergodox.
-
so what is the advantage of the external EEPROM on the Ergodox if all those features can exist without it? am i an idiot who missed something.
-
The advantages are:
- Enhanced text macros that fully support modifier keys and can be triggered by any combination of up to four keys. (requires external EEPROM on Ergodox)
- Virtual machine interpreter that allows complex interpreted macros to be written in a simple programming language. (requires external EEPROM on Ergodox)
I think they must just not fit in the onboard Teensy memory...
-
what i really want is media key support for windows via the massdrop configurator. can we get support for that with this new firmware?
-
what i really want is media key support for windows via the massdrop configurator. can we get support for that with this new firmware?
As the firmware isn't based on the ergodox firmware, it's not necessary to reflash the keyboard to change the layout. You can remap keys on the keyboard itself (see docs here (https://github.com/chrisandreae/keyboard-firmware#enterexit-layout-programming)) or using the GUI config program.
Unfortunately though, the "consumer control device" HID media keys aren't yet supported. It's on the todo list, though.
-
On the release page, there is this comment:
Caveat for Windows: To use the GUI client on Windows, you must first install a generic USB driver to allow libusb to access the device. An easy tool for doing this is zadig.exe. This will however prevent Windows from using the usb interface with that driver as HID input (that is to say, either typing (Interface 0) or mouse movement (Interface 1) will be lost).
What does this mean? Does this mean I would need to uninstall the generic USB driver before I could use the ErgoDox or my trackball?
-
On the release page, there is this comment:
Caveat for Windows: To use the GUI client on Windows, you must first install a generic USB driver to allow libusb to access the device. An easy tool for doing this is zadig.exe. This will however prevent Windows from using the usb interface with that driver as HID input (that is to say, either typing (Interface 0) or mouse movement (Interface 1) will be lost).
What does this mean? Does this mean I would need to uninstall the generic USB driver before I could use the ErgoDox or my trackball?
No, it would affect only the keyboard itself. Here's the issue: Windows has a limitation that you can't send USB vendor commands (what the firmware uses for configuration) to a standard HID device like a keyboard or mouse. So to use the configuration software on Windows, you have to replace the standard HID driver with a generic driver allowing vendor commands. The problem with doing this though is that suddenly you can no longer use the device that you reinstalled the driver of for its standard purpose (i.e typing or mouse movement). Fortunately, the keyboard firmware presents a composite device with two interfaces - a keyboard and a mouse (for mousekey support). Replacing the driver on the mouse interface loses mouse key support, but overall that's not a very big loss.
There's a way to fix the issue: if I change the firmware to use HID feature reports for its configuration interface instead of vendor commands, it'll work without any special driver on Windows. This is definitely on my todo list, but I haven't gotten around to it yet - I use a Mac, so it doesn't personally affect me. If I get a few Windows users asking for the feature, I'll try and get around to it soon :)
(There's a second, much hackier way to fix the issue: make the keyboard report a third completely fake interface, and just install the generic driver on that. I've pushed a completely untested branch with this to github here (https://github.com/chrisandreae/keyboard-firmware/tree/windows-hack))
tl;dr: replace the driver for interface 1 of the keyboard using zadig.exe (http://zadig.akeo.ie/) - you'll lose mousekey support, but gain the use of the config tool.
-
Wow, amazing stuff!
-
Any chance of a linux client? I would love to use this with my Doxen.
-
Any chance of a linux client? I would love to use this with my Doxen.
The client builds and runs fine in Linux, basic instructions are here (https://github.com/chrisandreae/keyboard-firmware/blob/public/README.md#gui-client). You need to have libusb-dev and qt4-dev to build.
-
Does this allow N-Key rollover?
-
Does this allow N-Key rollover?
Currently it sends standard boot protocol reports with 6-key rollover. Adding a few more to this is very easy though:
- Increase the descriptor's report count here (https://github.com/chrisandreae/keyboard-firmware/blob/public/Descriptors.h#L83)
- Increase KEYSTATE_COUNT here (https://github.com/chrisandreae/keyboard-firmware/blob/public/keystate.h#L68) by the same amount
Increasing KEYSTATE_COUNT will affect the scan speed though, so best not to add too many this way.
(To be fully boot-protocol compliant, you should also really cut the report size back to 6 when the host has selected boot protocol with HID_SET_PROTOCOL. Shouldn't actually be a problem in practice, as a boot protocol BIOS host should just ignore any extensions to the report.)
To do complete n-key support properly it'd be a bit more work, it would require:
- Move to tracking the state and debounce of all physical keys rather than a KEYSTATE_COUNT subset (may need to disable a VM or two to free up enough RAM for this)
- Switch to using a bitset (LogicalMinimum=0x0, LogicalMaximum=0x1, ReportCount 0x65, ReportSize 0x1, Input (Variable, Absolute)) in the report descriptor instead of an array, and add a new keystate_Fill_KeyboardReport (https://github.com/chrisandreae/keyboard-firmware/blob/public/keystate.c#L232) to construct that.
- Add code to check whether the host has requested us to use report or boot protocol, and actually send the two different report types based on that.
This does slightly break the HID spec, which states in Appendix C (Keyboard Implementation) that "Non-modifier keys must be reported in Input (Array, Absolute) items", but it seems to be the better supported way out there to get NKRO. Myself though, I'd rather have a more compatible keyboard than the ability to press more keys than I have fingers.
-
Does this allow N-Key rollover?
Currently it sends standard boot protocol reports with 6-key rollover. Adding a few more to this is very easy though:
- Increase the descriptor's report count here (https://github.com/chrisandreae/keyboard-firmware/blob/public/Descriptors.h#L83)
- Increase KEYSTATE_COUNT here (https://github.com/chrisandreae/keyboard-firmware/blob/public/keystate.h#L68) by the same amount
Increasing KEYSTATE_COUNT will affect the scan speed though, so best not to add too many this way.
(To be fully boot-protocol compliant, you should also really cut the report size back to 6 when the host has selected boot protocol with HID_SET_PROTOCOL. Shouldn't actually be a problem in practice, as a boot protocol BIOS host should just ignore any extensions to the report.)
To do complete n-key support properly it'd be a bit more work, it would require:
- Move to tracking the state and debounce of all physical keys rather than a KEYSTATE_COUNT subset (may need to disable a VM or two to free up enough RAM for this)
- Switch to using a bitset (LogicalMinimum=0x0, LogicalMaximum=0x1, ReportCount 0x65, ReportSize 0x1, Input (Variable, Absolute)) in the report descriptor instead of an array, and add a new keystate_Fill_KeyboardReport (https://github.com/chrisandreae/keyboard-firmware/blob/public/keystate.c#L232) to construct that.
- Add code to check whether the host has requested us to use report or boot protocol, and actually send the two different report types based on that.
This does slightly break the HID spec, which states in Appendix C (Keyboard Implementation) that "Non-modifier keys must be reported in Input (Array, Absolute) items", but it seems to be the better supported way out there to get NKRO. Myself though, I'd rather have a more compatible keyboard than the ability to press more keys than I have fingers.
This is very interesting. Thanks for all your hard work on this project!
-
please please let us know when this supports HID Media Keys in windows. thanks!
-
Expecting my Ergo kit from MassDrop to show up in a month or so. Could you supply a part number for the EEPROM so I can have that available too?
-
wow, excellent! I may use this as my "go-to" ergodox firmware for testing.
-
Expecting my Ergo kit from MassDrop to show up in a month or so. Could you supply a part number for the EEPROM so I can have that available too?
Sure. What I used (because I had it lying around) was an AT24C16AN (http://www.atmel.com/Images/doc0180.pdf). You can pick them up extremely cheaply on eBay (http://www.ebay.com/sch/i.html?_nkw=at24c16). Any compatible 2kbyte I2C serial EEPROM should be fine though.
-
This looks really well done!
I'm curious, what is the approximate scan rate with the default rollover config?
I know there were some issues early on with the TMK firmware with this.
-
Any chance of a linux client? I would love to use this with my Doxen.
The client builds and runs fine in Linux, basic instructions are here (https://github.com/chrisandreae/keyboard-firmware/blob/public/README.md#gui-client). You need to have libusb-dev and qt4-dev to build.
I got an error during make.
g++ -c -pipe -g -Wall -W -D_REENTRANT -fPIE -DQT_XML_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I/usr/lib/qt/mkspecs/linux-g++ -I. -I/usr/include/libusb-1.0 -I/usr/include/qt -I/usr/include/qt/QtXml -I/usr/include/qt/QtGui -I/usr/include/qt/QtCore -I. -o keyboardcomm.o keyboardcomm.cc
In file included from keyboardcomm.cc:11:0:
keyboardcomm.h: In member function ‘virtual const char* InsufficentStorageException::what() const’:
keyboardcomm.h:53:6: error: ‘class QString’ has no member named ‘toAscii’
.toAscii();
^
Makefile:1470: recipe for target 'keyboardcomm.o' failed
make: *** [keyboardcomm.o] Error 1
Any ideas?
-
This?
http://www.qtcentre.org/threads/53783-toAscii()-in-Qt5
-
This?
http://www.qtcentre.org/threads/53783-toAscii()-in-Qt5
I got past that error by using qtchooser with Qt4, but now on the make command I get the following error:
g++ -c -pipe -g -Wall -W -D_REENTRANT -DQT_XML_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtXml -I/usr/include/qt4 -I/$
Makefile:550: recipe for target 'hexdump.o' failed
Any ideas?
-
Did anybody convert Kinesis Advantage schematic to KiCad? If yes, can you post it?
-
This?
http://www.qtcentre.org/threads/53783-toAscii()-in-Qt5
I got past that error by using qtchooser with Qt4, but now on the make command I get the following error:
g++ -c -pipe -g -Wall -W -D_REENTRANT -DQT_XML_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtXml -I/usr/include/qt4 -I/$
Makefile:550: recipe for target 'hexdump.o' failed
Any ideas?
Alright, I got it to build and run and build properly now, by running qmake-qt4 now instead, but now I get an error when I click download default settings.
Error downloading settings: LIBUSB_ERROR_TIMEOUT
Segmentation fault (core dumped)
Any ideas?
-
Okay, when I don't run ./KeyboardClient as root, I get
LIBUSBError when enumerating: LIBUSB_ERROR_ACCESS
which makes me think that libusb is giving me trouble, somehow..
-
Any ideas?
I just tried building it in an Ubuntu VM and had no issues. Library versions libqtcore4 4:4.8.1-0ubuntu4.6 and libusb-1.0-0 2:1.0.9~rc3-2ubuntu1. In case you happen to be using Ubuntu, I've made (attached) a quick and dirty Ubuntu package which you could try.
-
Did anybody convert Kinesis Advantage schematic to KiCad? If yes, can you post it?
I haven't, but it'd be pretty cool if someone did! Another really useful project would be to redesign it as a two-layer board suitable for professional manufacture rather than home etching. It should be possible to lay it out entirely within the DIP40 socket footprint and remove the need for the separate daughterboard.
-
Any ideas?
I just tried building it in an Ubuntu VM and had no issues. Library versions libqtcore4 4:4.8.1-0ubuntu4.6 and libusb-1.0-0 2:1.0.9~rc3-2ubuntu1. In case you happen to be using Ubuntu, I've made (attached) a quick and dirty Ubuntu package which you could try.
I am actually using Arch, and I am pretty new to it still, so I am very likely doing something wrong, but I can pry still look at the package you built as a reference. I will take a look when I get back home.
Just to give you more info on the problem that I was having, the program runs, but it doesn't specify what kind of keyboard is plugged in, and when I click load default, it crashes. It also refuses to reconnect to the keyboard until I re-flash the firmware, which I thought was bizarre.
-
I am actually using Arch, and I am pretty new to it still, so I am very likely doing something wrong, but I can pry still look at the package you built as a reference. I will take a look when I get back home.
I cobbled together an Arch VM and it worked fine there too. Not sure what's breaking for you, but I'll send you the binary that worked for me in a PM.
-
This looks really well done!
I'm curious, what is the approximate scan rate with the default rollover config?
I know there were some issues early on with the TMK firmware with this.
• With the LUFA core on an Ergodox, about 180Hz. This is constrained by the I2C I/O expander. It's measured with the default 100kHz I2C frequency (https://github.com/chrisandreae/keyboard-firmware/blob/public/twi.h#L53): if your hardware copes with it, you could do a lot better by bumping it up to 400kHz. I think this is what was done to improve the TMK firmware's performance. Next time I get my hands on an Ergodox I'll do a bit of testing.
• With the VUSB core on my Kinesis, about 420Hz. This is constrained mostly by the software USB implementation.
-
Okay, when I don't run ./KeyboardClient as root, I get
LIBUSBError when enumerating: LIBUSB_ERROR_ACCESS
which makes me think that libusb is giving me trouble, somehow..
Same Problem here at Kubuntu 14.04
-
Did anybody convert Kinesis Advantage schematic to KiCad? If yes, can you post it?
I haven't, but it'd be pretty cool if someone did!
Can you post pictures (or pdf file) of the schematic?
-
Okay, when I don't run ./KeyboardClient as root, I get
LIBUSBError when enumerating: LIBUSB_ERROR_ACCESS
which makes me think that libusb is giving me trouble, somehow..
Same Problem here at Kubuntu 14.04
If you're not running as root, you need to make sure that your user account has permissions to access the USB device. This typically involves creating a udev rule. See here (http://www.libusb.org/wiki/FAQ#CanIrunLinuxlibusbapplicationswithoutrootrootprivilege) and here (http://stackoverflow.com/questions/13419691/accessing-a-usb-device-with-libusb-1-0-as-a-non-root-user) for more details.
-
Did anybody convert Kinesis Advantage schematic to KiCad? If yes, can you post it?
I haven't, but it'd be pretty cool if someone did!
Can you post pictures (or pdf file) of the schematic?
Sure - attached.
-
For the ErgoDox, is it possible to install the EEPROM on the right hand side?
-
For the ErgoDox, is it possible to install the EEPROM on the right hand side?
Sure, it needs to be attached to the I2C bus (i.e. the cable going between the two halves), so you could install it anywhere you find room for it on either side, or even in-line with the cable in order to avoid modifying the keyboard itself.
-
For the ErgoDox, is it possible to install the EEPROM on the right hand side?
Sure, it needs to be attached to the I2C bus (i.e. the cable going between the two halves), so you could install it anywhere you find room for it on either side, or even in-line with the cable in order to avoid modifying the keyboard itself.
I'll preface this with "I'm not an electrical engineer," so this is all very foreign to me.
Would this chip work? http://www.digikey.com/product-detail/en/AT24C16C-XHM-B/AT24C16C-XHM-B-ND/3046491
On a side note, would you happen to know if those 2.2k resistors are needed if no left-hand keyboard is being used? If that's the case then it appears as though, I may be able to connect it to the same contacts as in the picture of the left side.
The I2C doesn't appear to be labeled on the right hand PCB so I'm just not sure. Would you be able to point out the contacts that the chip should be connected to? Given that there are resistors soldered at the points where the chip is connected on the right hand side I'm not sure if that's the proper place.
-
Would this chip work? http://www.digikey.com/product-detail/en/AT24C16C-XHM-B/AT24C16C-XHM-B-ND/3046491
Probably yes. If you already have them just try it.
On a side note, would you happen to know if those 2.2k resistors are needed if no left-hand keyboard is being used? If that's the case then it appears as though, I may be able to connect it to the same contacts as in the picture of the left side.
Those resistors are pull-ups for I2C bus. You need them if you use any I2C device (e.g. the EEPROM). Even if you would not use any I2C device the firmware would probably halt if you would try to initialize the bus. So you can get rid of them only if you do not use any I2C device and make sure the firmware will not try to initialize the bus (which probably requires software change).
The I2C doesn't appear to be labeled on the right hand PCB so I'm just not sure. Would you be able to point out the contacts that the chip should be connected to? Given that there are resistors soldered at the points where the chip is connected on the right hand side I'm not sure if that's the proper place.
You can attach it to the resistors on the right end side, their bottom (non-vcc) side.
-
Hello there!
First time here :) I am currently looking for help to map correctly my brand new Ergodox.
I am french and I use an alternate kexboard layout known as Bépo. Unfontunately, because of the accents and different layers, the Massdrop Configurator isn’t much of a help to me. I think your app is a wonderful solution.
So far I am stuck at this damn USB driver issue. I downloaded you win client, and teh Zadig app.
Whin you say…
replace the driver for interface 1 of the keyboard using zadig.exe (http://zadig.akeo.ie/) - you'll lose mousekey support, but gain the use of the config tool.
I am puzzled. With what should I replace the Interface 1 ? I also see the Ergodox in the list of UBS devices, do I have to do something with it?
I am sorry to ask such noobs questions, but I am totally lost…
Thanks in advance to whoever will answer me :)
See you soon!
-
I am puzzled. With what should I replace the Interface 1 ? I also see the Ergodox in the list of UBS devices, do I have to do something with it?
I am sorry to ask such noobs questions, but I am totally lost…
Open Zadig, and choose 'List all devices' from the options menu
[attach=1]
Choose the target USB device to replace, for you it would probably be "Ergodox (Interface 1)"
[attach=2]
Ensure "WinUSB" is selected, and hit "Replace driver"
[attach=4]
Allow installation
[attach=3]
Should now work!
[attach=5]
Also for better international support, you probably will want to install the latest firmware release (https://github.com/chrisandreae/keyboard-firmware/releases/tag/1.1.1) - before this, the keyboard didn't report that it could provide the full range of keycode HID usages, which would have prevented several international extended keys (and other useful keys such as volume up/down) from working.
-
Thanks a lot, chrisandreae!
I’ll try that ASAP :)
.v
-
Thanks everyone for your replies. I have the firmware installed and it's working great!
My desired configuration is somewhat unique, so I'll be posting pictures in a little while with what I did different.
-
I just started using this too and I am enjoying it.
Is it possible to move the keypad button?
-
I just started using this too and I am enjoying it.
Is it possible to move the keypad button?
The keypad and program keys currently can't be soft-remapped due to their special functions, however if you don't mind editing the source and recompiling, you can change their positions in the MATRIX_TO_LOGICAL_MAP in hardware/ergodox.c (https://github.com/chrisandreae/keyboard-firmware/blob/public/hardware/ergodox.c#L51). Just pick another LOGICAL_KEY_ to swap with, and exchange their positions.
-
Since my need was for only one side of the ErgoDox, I ended up placing the EEPROM in a different location.
I used some spare USB cable to connect the EEPROM. I had enough and it's colored so I could tell the difference between leads easily.
I used the datasheet from Amtel to identify which leads were which on my package of the chip.
Identifying which contacts for the power was fairly easy since they're labeled on the board (on the other side).
[attach=1]
The SCL, and SDA were a little more difficult, but is simply a mirror of the example picture in the first post.
[attach=2]
The package of the chip that I got was not ideal. I'm not sure which would be the best, but this one is designed for surface mount and the leads are incredibly small and was a huge pain to solder the wires in place.
The chip lives on the front of the board near the controller in an available space. Luckily there was a hole in the board already through which I could route the wires.
The finished product:
[attach=3]
Thanks again to everyone that helped. The firmware has been working quite well.
-
Does the eeprom have to be 2kbyte? Or can it be larger? It's hard to find the one you mentioned here. Would something like http://ww1.microchip.com/downloads/en/DeviceDoc/20001203U.pdf (http://ww1.microchip.com/downloads/en/DeviceDoc/20001203U.pdf) also work?
-
Does the eeprom have to be 2kbyte? Or can it be larger? It's hard to find the one you mentioned here. Would something like http://ww1.microchip.com/downloads/en/DeviceDoc/20001203U.pdf (http://ww1.microchip.com/downloads/en/DeviceDoc/20001203U.pdf) also work?
There's no reason it needs to be constrained to 2 kbyte, but the protocol for talking to the larger eeproms is slightly different (two byte addresses), so if you wanted to use one you'd have to change serial_eeprom.c (https://github.com/chrisandreae/keyboard-firmware/blob/public/serial_eeprom.c#L72) to match. If you don't want to do that, other compatible 2 kbyte serial eeproms aren't that hard to find: for example 10x AT24C16 for $4 or so on eBay here (http://www.ebay.com/itm/10PCS-IC-AT24C16-AT24C16AN-PU-2-7-EEPROM-DIP8-NEW-GOOD-QUALTIY-DTE-CODE-12-/300771487534?pt=LH_DefaultDomain_0&hash=item460760af2e). It's not necessary to specifically use the (obsolete) AT24C164: that's just what happens to be already present in the Kinesis.
-
I've designed a new double-sided PCB for the Kinesis, suitable for professional manufacture, which should reduce the effort required to get your hands on one. Schematics and Gerber files can be found here (https://github.com/chrisandreae/keyboard-firmware/tree/public/schematic/KinesisAdvantage%20v2.5), or they can be ordered from the DirtyPCBs store here (http://dirtypcbs.com/view.php?share=3735&accesskey=8e7001099151c3af43b29427c8f369a0)
[attachimg=1]
[attachimg=2]
-
Nice. I'm planning to do something like this too. Though I would like to put there ATxmega128A4U. Do you happen to know whether the address decoders and the EEPROMs on the original PCB would work with Vcc of 3.3V ?
I'm not sure whether I'll need to replace also the original PCB.
Thanks for the nice firmware.
-
Nice. I'm planning to do something like this too. Though I would like to put there ATxmega128A4U. Do you happen to know whether the address decoders and the EEPROMs on the original PCB would work with Vcc of 3.3V ?
I'm not sure whether I'll need to replace also the original PCB.
Thanks for the nice firmware.
Looking at datasheets (http://ecee.colorado.edu/~mcclurel/sn74ls138rev5.pdf, http://www.atmel.com/Images/doc0105.pdf), the EEPROM should be just fine. The decoders, maybe: they require a 5V Vcc, but will register input HIGH at 2.0V, and their output HIGH is typically 3.5v. The ATxmega128A4U datasheet states that the absolute maximum pin voltage is Vcc+0.5v. So you'd probably get away with it just fine, particularly with series resistors to limit the current.
Edit: you could always switch out the 74LS138 for 74HC138, a more modern CMOS variant which will handle 3.3v just fine.
However, one thing that you may have trouble with is the buzzer: my Kinesis features an Intervox BRT1209PF-06 (datasheet (http://ex-en.alliedelec.com/images/products/datasheets/bm/ICC/70115802.pdf)) whose operating voltage is 4-8V.
-
I can switch the buzzer. I will need to hack the PCB a bit anyway since I would like to add also 2 more buttons to each thumb cluster so that it has Maltron like thumb clusters. This is still far future since I want to finish v0.7 of Katy (https://geekhack.org/index.php?topic=61323.0) first.
I'm not decided whether I hack the original PCB or just replace it and also add an LCD support with the new PCB.
The rubber keys do not have diodes. That means the address decoders must be somehow able to handle a short between their outputs since when e.g. both F6 and F8 are pressed at the same time then U4-Y0 and U4-Y1 are shorted. Or is the resistance of the rubber keys high enough that it is not really a short? The original kinesis firmware will detect only one of the simultaneously pressed rubber keys in one column.
It looks safer to rather use something which allows to set output to high impedance for the rubber key matrix rows. E.g. the micro-controller pins directly. Only 3 more pins needed for that.
-
The rubber keys do not have diodes. That means the address decoders must be somehow able to handle a short between their outputs since when e.g. both F6 and F8 are pressed at the same time then U4-Y0 and U4-Y1 are shorted. Or is the resistance of the rubber keys high enough that it is not really a short? The original kinesis firmware will detect only one of the simultaneously pressed rubber keys in one column.
It looks safer to rather use something which allows to set output to high impedance for the rubber key matrix rows. E.g. the micro-controller pins directly. Only 3 more pins needed for that.
I see the issue that you're pointing out, but since it's part of the original design of the Kinesis, I'm reasonably prepared to assume it's not going to become any (more of) a problem in a derived design. I've certainly never burned out a Kinesis by chording the function keys.
Looking at the datasheet for the demultiplexer, there's:
IOS | Short Circuit Current (Note 1) | –20 (min) | –100 (max) | mA
Note 1: Not more than one output should be shorted at a time, nor for more than 1 second.
Perhaps this combined with the high scan rate is why it doesn't seem to be an issue in practice.
By the way, is your modified source with support for the ATxmega online anywhere?
-
Right. I would not be afraid to use the original address decoder since it works ok. But the possible shorts should be considered if I would need to replace it.
The port to ATxmega128a4u is not published yet. I'll let you know when it is out. The port handles only Katy's controller since I do not have any ATxmega controller for Erogodox or Kinesis upgrade. Also Ergodox/Kinesis are probably broken because of the other changes added for Katy (like e.g. the layer shift keys).
Otherwise the port for ATxmega was easy. It is more or less only the LUFA upgrade to the latest version and then it just works. It is also not tested well yet since I do not have a case finished for Katy v0.7 (which is the first one using ATxmega).
-
I've designed a new double-sided PCB for the Kinesis, suitable for professional manufacture, which should reduce the effort required to get your hands on one. Schematics and Gerber files can be found here (https://github.com/chrisandreae/keyboard-firmware/tree/public/schematic/KinesisAdvantage%20v2.5), or they can be ordered from the DirtyPCBs store here (http://dirtypcbs.com/view.php?share=3735&accesskey=8e7001099151c3af43b29427c8f369a0)
(Attachment Link)
(Attachment Link)
Hi Chris,
What else would I need to order so I can use the boards from Dirty PCB? Looking through your github project, it's not clear what else is needed, like the ribbon cable in your photos.
Thanks.
-
What else would I need to order so I can use the boards from Dirty PCB? Looking through your github project, it's not clear what else is needed, like the ribbon cable in your photos.
I didn't make an exact BOM, but here are the things I bought specifically that might not be obvious from the schematic:
Ribbon cable (http://www.ebay.com/itm/5pcs-150mm-Length-24Pins-0-5mm-Pitch-FFC-FPC-Ribbon-Flat-Cable-Forward-Direction-/200829810197?pt=LH_DefaultDomain_0&hash=item2ec263b615)
Ribbon cable connectors (http://www.ebay.com/itm/10-pcs-FFC-FPC-24-pin-0-5mm-Pitch-Ribbon-Flat-Connector-Socket-Top-contact-/231575316632?pt=LH_DefaultDomain_0&hash=item35eaf6e898)
Zener diodes for USB data lines (http://www.ebay.com/itm/100pcs-3-6V-0-5W-ZMM-1206-SMD-Zener-Diode-/171054799790?pt=LH_DefaultDomain_0&hash=item27d3a91bae)
2mm pin header to connect to existing Kinesis USB cable (http://www.ebay.com/itm/10pcs-1-X-40pin-2mm-breakaway-Male-header-for-Arduino-Prototype-Shield-DIY-/251074830562?pt=LH_DefaultDomain_0&hash=item3a7539e0e2)
Other than that it's just an ATMega32A microcontroller, some 0603 resistors and capacitors in various values, a 16mhz crystal, a small electrolytic capacitor, and a 2.54mm pin header.
-
do you mind expanding on the reasons for the ribbon cable and secondary board? why didn't you just add the microcontroller, 7pin, jumpers, and diode right to the board that plugs into the kinesis socket?
-
Out of curiosity, and forgive me if this is should be obvious, but would this firmware work around the USB 3.0 issue with the Kinesis Advantage and Windows 7?
-
do you mind expanding on the reasons for the ribbon cable and secondary board? why didn't you just add the microcontroller, 7pin, jumpers, and diode right to the board that plugs into the kinesis socket?
Space, unfortunately. The Kinesis' microcontroller socket sits right underneath the cylindrical cutout in the case where the cable comes in, so there's very little room to be any larger than the 40-pin DIP footprint of the original chip. My initial design was all-in-one, and required me to cut out a bit of plastic for the case to shut.
I've actually considered porting to a physically smaller microcontroller, just so I can fit everything in between the pins in the DIP socket. I may get around to it some day.
-
Out of curiosity, and forgive me if this is should be obvious, but would this firmware work around the USB 3.0 issue with the Kinesis Advantage and Windows 7?
Yep, works fine on USB 3.0 in Windows 7.
-
By the way, is your modified source with support for the ATxmega online anywhere?
It is out now: https://github.com/hercek/keyboard-firmware/commits/katy
Your latest branch containing the layer shift and Program/KeyPad key remap support is not merged yet.
There is my own layer shift version there. Other notable things: ATXmega support, newer LUFA version, lower EEPROM requirements and support for macro storage in internal eeprom (i.e. Ergodoxes without external EEPROM can have some macro functionality too).
Your Ergodox and Kinesis support is bitroted. And I cannot fix it by myself since I do not have Ergodox nor Kinesis with your controller. At most, I can make sure they compile. You need to decide whether you would want to merge anything to your branch. If so, I can merge your new branch and make Ergodox and Kinesis options to compile. It will not be soon since I'll need to understand your commits in the layer shift branch first.
-
Does anyone know specifically which components are needed to build the Kinesis Advantage 2.5 replacement firmware? Is there a BOM available, the information in this thread seems a bit scattered and I need to be sure I order the correct components.
I'd love to have someone build one for me, as I don't have the skills nor the equipment to solder surface mount components.
Aside from that, is there anyone interested in actually soldering one of these for me? I'd be willing to pay for the job of course.
Alternatively are there perhaps other ATmega breakout boards that have the correct amount of pins and pin spacing that could be used to skip the PCB manufacturing process all together? I know @vvp has a fork with support for other ATmega chips. Curious what people's thoughts are on this.
-
Carefull, my branch is for ATXmega and not for ATmega. ATXmega is a bit more powerfull and much less used than ATmega. Although the instruction set is almost the same, the input/output system is significantly different.
I have a plan to make my own ATXmega controller board for my old kinesis but there is no timeframe and it is possible I will not ever do it.
My port is for ATXmega128A4U (which has 34 GPIO pins) and it is specifically for my Katy keyboard (http://deskthority.net/workshop-f7/katy-keyboard-or-k80cs-key80-contoured-split-t8524.html#p247068). It is not usable with chrisandreae's kinesis replacement controler.
Chrisandreae uses ATmega32 chip in his kinesis replacement controller which has 32 GPIO pins.
Ergodox uses ATmega32u4 which has 26 GPIO pins.
If you want to completely avoid SMD soldering than you might be able to use Teensy 2.0 or ArduinoMicro boards. From the schematic it looks like you may be able to fit in 26 pins if you ignore some or all footswitch pins. All 26 pins can be pulled out from Teensy/ArduinoMicro but some of them (e.g. HWB) need to be pulled from inside smd components. It is not a big deal but harder compared to normal pins. You would need to modify the firmware too, i.e. some programming skills are needed.
-
Carefull, my branch is for ATXmega and not for ATmega. ATXmega is a bit more powerfull and much less used than ATmega. Although the instruction set is almost the same, the input/output system is significantly different.
I have a plan to make my own ATXmega controller board for my old kinesis but there is no timeframe and it is possible I will not ever do it.
My port is for ATXmega128A4U (which has 34 GPIO pins) and it is specifically for my Katy keyboard (http://deskthority.net/workshop-f7/katy-keyboard-or-k80cs-key80-contoured-split-t8524.html#p247068). It is not usable with chrisandreae's kinesis replacement controler.
Chrisandreae uses ATmega32 chip in his kinesis replacement controller which has 32 GPIO pins.
Ergodox uses ATmega32u4 which has 26 GPIO pins.
If you want to completely avoid SMD soldering than you might be able to use Teensy 2.0 or ArduinoMicro boards. From the schematic it looks like you may be able to fit in 26 pins if you ignore some or all footswitch pins. All 26 pins can be pulled out from Teensy/ArduinoMicro but some of them (e.g. HWB) need to be pulled from inside smd components. It is not a big deal but harder compared to normal pins. You would need to modify the firmware too, i.e. some programming skills are needed.
Thanks for the heads up, my mistake, I didn't notice it was for a different series.
I've thought abuot going down the Teensy2 route with the (ATmega32u4). I wouldn't need the footswitch capabilities, as the only reason I'd use them today would be extend the current firmware's macro capabilities. However, could I instead get a hold of a 32pin ATmega32 with a 32 pin IO configuration? If so I could do the same as Chrisandreae, just with a breakout board and a much less elegant solution.
-
The closest to a BOM that I put together was this post:
I didn't make an exact BOM, but here are the things I bought specifically that might not be obvious from the schematic:
Ribbon cable (http://www.ebay.com/itm/5pcs-150mm-Length-24Pins-0-5mm-Pitch-FFC-FPC-Ribbon-Flat-Cable-Forward-Direction-/200829810197?pt=LH_DefaultDomain_0&hash=item2ec263b615)
Ribbon cable connectors (http://www.ebay.com/itm/10-pcs-FFC-FPC-24-pin-0-5mm-Pitch-Ribbon-Flat-Connector-Socket-Top-contact-/231575316632?pt=LH_DefaultDomain_0&hash=item35eaf6e898)
Zener diodes for USB data lines (http://www.ebay.com/itm/100pcs-3-6V-0-5W-ZMM-1206-SMD-Zener-Diode-/171054799790?pt=LH_DefaultDomain_0&hash=item27d3a91bae)
2mm pin header to connect to existing Kinesis USB cable (http://www.ebay.com/itm/10pcs-1-X-40pin-2mm-breakaway-Male-header-for-Arduino-Prototype-Shield-DIY-/251074830562?pt=LH_DefaultDomain_0&hash=item3a7539e0e2)
Other than that it's just an ATMega32A microcontroller, some 0603 resistors and capacitors in various values, a 16mhz crystal, a small electrolytic capacitor, and a 2.54mm pin header.
If you want to use a Teensy to avoid the surface mount soldering, someone else has designed a pinout here (https://hackaday.io/project/4320-kinesis-advantage-tmk-hack) and there's a pull request to my firmware to support it here (https://github.com/chrisandreae/keyboard-firmware/pull/7/files) that I haven't yet gotten around to merging (sorry!).
I'm also currently working on an ARM port, but progress on it stalled a lot when I broke my wrist a couple of months back.
-
However, could I instead get a hold of a 32pin ATmega32 with a 32 pin IO configuration? If so I could do the same as Chrisandreae, just with a breakout board and a much less elegant solution.
I'm not aware of a breakout board with ATmega32. You can try to google :)
But really. If you can solder through hole parts then you can solder also SMD with only a very little training (like few hours). And then you learn that soldering SMD is even quicker than through-hole and will start to prefer SMD parts :)
-
The closest to a BOM that I put together was this post:
I didn't make an exact BOM, but here are the things I bought specifically that might not be obvious from the schematic:
Ribbon cable (http://www.ebay.com/itm/5pcs-150mm-Length-24Pins-0-5mm-Pitch-FFC-FPC-Ribbon-Flat-Cable-Forward-Direction-/200829810197?pt=LH_DefaultDomain_0&hash=item2ec263b615)
Ribbon cable connectors (http://www.ebay.com/itm/10-pcs-FFC-FPC-24-pin-0-5mm-Pitch-Ribbon-Flat-Connector-Socket-Top-contact-/231575316632?pt=LH_DefaultDomain_0&hash=item35eaf6e898)
Zener diodes for USB data lines (http://www.ebay.com/itm/100pcs-3-6V-0-5W-ZMM-1206-SMD-Zener-Diode-/171054799790?pt=LH_DefaultDomain_0&hash=item27d3a91bae)
2mm pin header to connect to existing Kinesis USB cable (http://www.ebay.com/itm/10pcs-1-X-40pin-2mm-breakaway-Male-header-for-Arduino-Prototype-Shield-DIY-/251074830562?pt=LH_DefaultDomain_0&hash=item3a7539e0e2)
Other than that it's just an ATMega32A microcontroller, some 0603 resistors and capacitors in various values, a 16mhz crystal, a small electrolytic capacitor, and a 2.54mm pin header.
If you want to use a Teensy to avoid the surface mount soldering, someone else has designed a pinout here (https://hackaday.io/project/4320-kinesis-advantage-tmk-hack) and there's a pull request to my firmware to support it here (https://github.com/chrisandreae/keyboard-firmware/pull/7/files) that I haven't yet gotten around to merging (sorry!).
I'm also currently working on an ARM port, but progress on it stalled a lot when I broke my wrist a couple of months back.
I've looked at that hackaday project, but the schematic refers to a different Atmel chip, the AT90S58515-P, rather than the onboard AT89S8253.. The schematic refers to pins that doesn't even exist.
How do I use this to use the Teensy? I've literally got everything a lot of it wired up already.
-
How do I use this to use the Teensy? I've literally got everything a lot of it wired up already.
I'm afraid there is no simple answer to this. If somebody did not design the schematic to connect teensy to kinesis advantage then you need to design it yourself. Based on the schematics it should be doable (without handling some foot switch pins). It is a considerable work but it always like that when you choose a non-published not-yet-developed option.
-
I just want to update this and let everyone know that the TMK schematic seen on the hackaday site works. I'm thinking about creating a new schematic that's more detailed and references the correct chip.
Sad thing is, the Teensy I bought from PJRC doesn't support LUFA, so can't get the 'programmable on the fly' firmware running just yet.
-
How could it not support LUFA?
PJRC Teensy is interesting only because of its proprietary 512 B bootloader. The application should not depend on bootloader.
And even if you would want a different bootloader, you still can replace it with an ISP programmer. And if it is just for a bootloader, then you can use something home made like these:
https://www.arduino.cc/en/Hacking/ParallelProgrammer
http://nahians-avr.webs.com/serialportprogrammer.htm
At least the first one works also with avrdude.
-
How could it not support LUFA?
PJRC Teensy is interesting only because of its proprietary 512 B bootloader. The application should not depend on bootloader.
And even if you would want a different bootloader, you still can replace it with an ISP programmer. And if it is just for a bootloader, then you can use something home made like these:
https://www.arduino.cc/en/Hacking/ParallelProgrammer
http://nahians-avr.webs.com/serialportprogrammer.htm
At least the first one works also with avrdude.
I'm not entirely sure, but I couldn't find much information on it. It's probably possible to flash the AVR itself through serial if the bit is set etc, but I don't want to brick my device either.
I wasn't able to flash the hex, and from what I read the Teensy 2.0 comes with the Halfkey bootloader.
-
Does the firmware for the Kinesis Advantage support the foot pedals? I don't have those, but I have used the internal connections for them to wire up a couple of palm arcade buttons à la Sordna's post: https://geekhack.org/index.php?topic=26579.0 (https://geekhack.org/index.php?topic=26579.0). I love them, and as much as I want to use this controller replacement, I really want to keep my palm buttons working (I have the left one mapped to left Shift and the right one shifts to the Keypad Layer).
-
Does the firmware for the Kinesis Advantage support the foot pedals? I don't have those, but I have used the internal connections for them to wire up a couple of palm arcade buttons à la Sordna's post: https://geekhack.org/index.php?topic=26579.0 (https://geekhack.org/index.php?topic=26579.0). I love them, and as much as I want to use this controller replacement, I really want to keep my palm buttons working (I have the left one mapped to left Shift and the right one shifts to the Keypad Layer).
Yes, -ish. I've routed the connections for them on the PCB, but never actually gotten around to adding them to the matrix scanning in the firmware. It wouldn't be much work at all to do so, I'd just need to dig my foot pedal out to check that I'd done it right.
-
How could it not support LUFA?
PJRC Teensy is interesting only because of its proprietary 512 B bootloader. The application should not depend on bootloader.
And even if you would want a different bootloader, you still can replace it with an ISP programmer. And if it is just for a bootloader, then you can use something home made like these:
https://www.arduino.cc/en/Hacking/ParallelProgrammer
http://nahians-avr.webs.com/serialportprogrammer.htm
At least the first one works also with avrdude.
I'm not entirely sure, but I couldn't find much information on it. It's probably possible to flash the AVR itself through serial if the bit is set etc, but I don't want to brick my device either.
I wasn't able to flash the hex, and from what I read the Teensy 2.0 comes with the Halfkey bootloader.
Update: I've been able to flash the Teensy 2.0 with the compiled hex but it doesn't want to work nicely. I ordered a Atmega32u4 breakout board and flashed that, works great with this firmware, really appreciate the help with this!
I do have a few questions though. Is it possible to add multiple layers to the GUI config tool? I use colemak and would like to use that natively but also have alt-gr modifiers comparative to the US International layout. I understand I can rewrite the layout under hardware/kinesis.c but I was hoping for an easier solution.
Lastly, it should be possible to remap and create new layers directly with the keyboard, how do I for example reprogram layer 3 to be colemak instead of qwerty? Does anyone have any experience with this? I honestly have some trouble understanding the documentation, beyond that of the capabilities of the Kinesis EEPROM remapping features.
-
The firmware supports 10 "configurations" by default. These are actually 10 save spots where you can save your currently used keypad/normal layer. You can load a configuration using Prg-<LoadCfgKey>-<NumberKey> key combination. You can save the current configuration using Prg-<SaveCfgKey>-<NumberKey>.
One configuration is actually contains a remap definition for your normal + keypad layer.
Probably (for Katy it is different so I'm not sure I have this right for non-Katy keyboards):
LoadCfgKey = L
SaveCfbKey = S
I.e. What is named "configuration" in this firmware is actually named "layer" in other firmwares. While "layer" in this firmware means either normal or keypad layer.
KeyboardClient (qtclient) allows you to modify the current configuration. So e.g. if you want Qwerty and Colemak then
define your querty layout in qtclient and save the configuration under number 1. Then define colemak layout in qtclient and save it under nubmer 2. Then you can quickly load the configuration 1 or 2 with Prg-<LoadCfgKey>-(1|2).
-
The firmware supports 10 "configurations" by default. These are actually 10 save spots where you can save your currently used keypad/normal layer. You can load a configuration using Prg-<LoadCfgKey>-<NumberKey> key combination. You can save the current configuration using Prg-<SaveCfgKey>-<NumberKey>.
One configuration is actually contains a remap definition for your normal + keypad layer.
Probably (for Katy it is different so I'm not sure I have this right for non-Katy keyboards):
LoadCfgKey = L
SaveCfbKey = S
I.e. What is named "configuration" in this firmware is actually named "layer" in other firmwares. While "layer" in this firmware means either normal or keypad layer.
KeyboardClient (qtclient) allows you to modify the current configuration. So e.g. if you want Qwerty and Colemak then
define your querty layout in qtclient and save the configuration under number 1. Then define colemak layout in qtclient and save it under nubmer 2. Then you can quickly load the configuration 1 or 2 with Prg-<LoadCfgKey>-(1|2).
From what I can see there's no way to select which layer to save and load from in the GUI, correct? As for doing it through the keyboard I've tried to make a modification to the default layer and then save that to say layer 1, but it spits out "No Layer" on all of the layers I try to save to.. Am I doing something wrong? Or perhaps my GUI client is too old?
-
Not sure what gui client you have. But first naming:
One configuration contains two layers: normal and keypad. You can use KeypadShift/KeypadToggle to switch between them. (I.e. a configuration is actually the remap definition (what USB HID code each key press should emit).
The keyboard has one active (current) configuration and 0-9 inactive configurations.
Active configuration is the one which is used when you type normal text, use numerical keypad (in keypad layer) etc.
Inactive configurations are actually an 10 item array. Each array item is the space where you can store copy of your active configuration (Prg-<SaveCfgKey>-<NumberKey>). And it is also the space from which you can copy the configuration to the active configuration (Prg-<LoadCfgKey>-<NumberKey>).
GUI Client always works only with the active/current configuration only. GUI does not know that the keyboard has also configurations 0-9. GUI knows normal layer and keypad layer, but does not know configurations.
So lets say you have defined two configurations 1 and 2. The current configuration is the copy of 1. You want to modify configuration 2. You can do it like this:- Prg-<LoadCfgKey>-2 (copy configuration 2 to the active configuration)
- modify it with GUI client
- now the current configuration is different from both configuration 1 and 2
- Prg-<SaveCfgKey>-2 (actualize configuration 2 so that it is not lost if you load some configuration)
It should work. Some configuration must be saved to e.g. slot 2 before you can load the (previously saved) configuration from the slot 2. If no configuration was saved to it then it prints "No Layer". Some keys must be remapped from default before you can save the active configuration to some slot. Otherwise it prints "No Change".
If you want to use GUI client on windows then the keyboard firmware and the GUI client must be compiled from "windows hack" branch and WinUSB driver must be installed. GUI client and keyboard firmware can be used directly on linux (no need for "windows hack" branch or special drivers).
-
Is there anyway to get one of these kinises conversion boards prebuilt?
-
Not sure what gui client you have. But first naming:
One configuration contains two layers: normal and keypad. You can use KeypadShift/KeypadToggle to switch between them. (I.e. a configuration is actually the remap definition (what USB HID code each key press should emit).
The keyboard has one active (current) configuration and 0-9 inactive configurations.
Active configuration is the one which is used when you type normal text, use numerical keypad (in keypad layer) etc.
Inactive configurations are actually an 10 item array. Each array item is the space where you can store copy of your active configuration (Prg-<SaveCfgKey>-<NumberKey>). And it is also the space from which you can copy the configuration to the active configuration (Prg-<LoadCfgKey>-<NumberKey>).
GUI Client always works only with the active/current configuration only. GUI does not know that the keyboard has also configurations 0-9. GUI knows normal layer and keypad layer, but does not know configurations.
So lets say you have defined two configurations 1 and 2. The current configuration is the copy of 1. You want to modify configuration 2. You can do it like this:- Prg-<LoadCfgKey>-2 (copy configuration 2 to the active configuration)
- modify it with GUI client
- now the current configuration is different from both configuration 1 and 2
- Prg-<SaveCfgKey>-2 (actualize configuration 2 so that it is not lost if you load some configuration)
It should work. Some configuration must be saved to e.g. slot 2 before you can load the (previously saved) configuration from the slot 2. If no configuration was saved to it then it prints "No Layer". Some keys must be remapped from default before you can save the active configuration to some slot. Otherwise it prints "No Change".
If you want to use GUI client on windows then the keyboard firmware and the GUI client must be compiled from "windows hack" branch and WinUSB driver must be installed. GUI client and keyboard firmware can be used directly on linux (no need for "windows hack" branch or special drivers).
Hey, thanks for the detailed information. I've actually found the problem, it never was the GUI client. My problem is either with the firmware build, or how I've connected the breakout board.
For example, the GUI client throws an exception when I try to upload an empty macro (I'm unable to actually use macros, even outside of the GUI client).
E.g: terminate called after throwing an instance of 'InsufficentStorageException' what(): Cannot store 4 bytes to macro storage: only 0 available.
I followed instructions for the TMK firmware, therefor it's likely I'm missing something that allows me to utilize the onboard eeprom? I'm not sure what that could be though.
-
Hey, thanks for the detailed information. I've actually found the problem, it never was the GUI client. My problem is either with the firmware build, or how I've connected the breakout board.
For example, the GUI client throws an exception when I try to upload an empty macro (I'm unable to actually use macros, even outside of the GUI client).
E.g: terminate called after throwing an instance of 'InsufficentStorageException' what(): Cannot store 4 bytes to macro storage: only 0 available.
I followed instructions for the TMK firmware, therefor it's likely I'm missing something that allows me to utilize the onboard eeprom? I'm not sure what that could be though.
The current release of the firmware uses the external 2kbyte I2C EEPROM included on the Kinesis' PCB to store the macro contents. On the Kinesis' 40 pin socket, SCL is pin 7 and SDA is pin 8. Those needs to be wired up to your microcontroller (preferably to the hardware I2C SCL/SDA pins, but you can use any I/O pins at a performance penalty if you #define BITBANG_TWI), the selected pins mapped in hardware/kinesis.h, and the firmware compiled with HAS_EXTERNAL_STORAGE=1.
-
Much appreciated Chris! I might just have compiled the firmware without external storage support.. I'll look into it and hopefully get it working. Would be great to use keypad_shift to access the keypad layer instead of reaching up to the keypad button to activate a second layer.
-
I've now checked both the pinout and can confirm both pin 7 & 8 go to SCL and SDA on my breakout board. I even recompiled and reflashed the firmware with external eeprom enabled. Still it reports macro storage size to 0. I must be doing something wrong..
-
Macros storage size is defined by symbol MACROS_SIZE. Or may be MACRO_SIZE in older sources?
Check what is that symbol defined like in your sources.
The relevant code reporting this to KeyboardClient is in
lufa/lufa_main.c:207
case READ_MACRO_STORAGE_SIZE:
Endpoint_Write_16_LE(MACROS_SIZE);
-
Macros storage size is defined by symbol MACROS_SIZE. Or may be MACRO_SIZE in older sources?
Check what is that symbol defined like in your sources.
The relevant code reporting this to KeyboardClient is in
lufa/lufa_main.c:207
case READ_MACRO_STORAGE_SIZE:
Endpoint_Write_16_LE(MACROS_SIZE);
It reads exactly as you mention it. I'm using a fork of this project with added support for the atmega32u4, could that be the reason this isn't working?
-
Ok, search all your sources for string MACROS_SIZE.
It will be defined somewhere to 0. Probably in some *.h file or a makefile. Change the definition to e.g. 1024.
If your fork redefined the symbol than it is one of the reasons why macros do not work for you. Maybe it is the only reason.
-
Ok, search all your sources for string MACROS_SIZE.
It will be defined somewhere to 0. Probably in some *.h file or a makefile. Change the definition to e.g. 1024.
If your fork redefined the symbol than it is one of the reasons why macros do not work for you. Maybe it is the only reason.
Hi, I looked through the source and couldn't find any mistakes in the macro size definition. Could it be wrong wiring on my end that's causing it?
-
If your KeyboardClient still reports macro storage size as 0 and your MACROS_SIZE is bigger than 0, then I do not know what else can be wrong. Well, it can be a lot of things (my next guess would be somewhere in qtclient code) but they do not seem probable to me. I doubt this can be caused by wiring.
Sorry, I'm out of ideas.
-
I didn't make an exact BOM, but here are the things I bought specifically that might not be obvious from the schematic:
Ribbon cable (http://www.ebay.com/itm/5pcs-150mm-Length-24Pins-0-5mm-Pitch-FFC-FPC-Ribbon-Flat-Cable-Forward-Direction-/200829810197?pt=LH_DefaultDomain_0&hash=item2ec263b615)
Ribbon cable connectors (http://www.ebay.com/itm/10-pcs-FFC-FPC-24-pin-0-5mm-Pitch-Ribbon-Flat-Connector-Socket-Top-contact-/231575316632?pt=LH_DefaultDomain_0&hash=item35eaf6e898)
Zener diodes for USB data lines (http://www.ebay.com/itm/100pcs-3-6V-0-5W-ZMM-1206-SMD-Zener-Diode-/171054799790?pt=LH_DefaultDomain_0&hash=item27d3a91bae)
2mm pin header to connect to existing Kinesis USB cable (http://www.ebay.com/itm/10pcs-1-X-40pin-2mm-breakaway-Male-header-for-Arduino-Prototype-Shield-DIY-/251074830562?pt=LH_DefaultDomain_0&hash=item3a7539e0e2)
Other than that it's just an ATMega32A microcontroller, some 0603 resistors and capacitors in various values, a 16mhz crystal, a small electrolytic capacitor, and a 2.54mm pin header.
I'm scoping out the components to try this on my Kinesis Advantage. What values do you recommend for the resistors and capacitors?
-
I didn't make an exact BOM, but here are the things I bought specifically that might not be obvious from the schematic:
Ribbon cable (http://www.ebay.com/itm/5pcs-150mm-Length-24Pins-0-5mm-Pitch-FFC-FPC-Ribbon-Flat-Cable-Forward-Direction-/200829810197?pt=LH_DefaultDomain_0&hash=item2ec263b615)
Ribbon cable connectors (http://www.ebay.com/itm/10-pcs-FFC-FPC-24-pin-0-5mm-Pitch-Ribbon-Flat-Connector-Socket-Top-contact-/231575316632?pt=LH_DefaultDomain_0&hash=item35eaf6e898)
Zener diodes for USB data lines (http://www.ebay.com/itm/100pcs-3-6V-0-5W-ZMM-1206-SMD-Zener-Diode-/171054799790?pt=LH_DefaultDomain_0&hash=item27d3a91bae)
2mm pin header to connect to existing Kinesis USB cable (http://www.ebay.com/itm/10pcs-1-X-40pin-2mm-breakaway-Male-header-for-Arduino-Prototype-Shield-DIY-/251074830562?pt=LH_DefaultDomain_0&hash=item3a7539e0e2)
Other than that it's just an ATMega32A microcontroller, some 0603 resistors and capacitors in various values, a 16mhz crystal, a small electrolytic capacitor, and a 2.54mm pin header.
I'm scoping out the components to try this on my Kinesis Advantage. What values do you recommend for the resistors and capacitors?
mystdrkn, did you ever proceed?
Has anyone else other than chrisandreae actually pulled this off?
I think I can probably figure out what all needs to be done from this thread, but I fear I'm not good enough with a soldering iron to do the assembly myself.
-
Chris' firmware is used by other people. No idea how many (if any) use his hardware though. I guess most use Ergodox hardware with the firmware. I use a completely different hardware.