geekhack
geekhack Community => Keyboards => Topic started by: cub-uanic on Wed, 04 September 2013, 18:46:30
-
Greetings,
It gives me great pleasure to announce my fork of TMK keyboard, adopted to ErgoDox. It's released on GitHub here: https://github.com/cub-uanic/tmk_keyboard/tree/cub_layout
There's not everything is finished yet - no layouts for Dvorak, Colemak and Workman, and TODO file is not empty yet - but it's usable and it have all TMK features.
There is no analog of TEENSY_DRIVE_ROWS and TEENSY_DRIVE_COLUMNS from Ben's firmware (see https://github.com/benblazak/ergodox-firmware), because I have one Ergodox, and I can't test both variants. Currently only "cathode of the diode (denoted with a line) connects to the square pad" is supported, so if you'll do everything as stated on Massdrop site - it will work. In case you'll soldered diodes differently - please adopt code yourself. Or if you want me to do this - then don't hesitate to send me one more Ergodox, and I'll assemble it with "diodes in opposite direction" and then will adjust sources and will make sure that everything works fine :)
But it have support for LeftLed :)
(see http://geekhack.org/index.php?topic=22780.msg873819#msg873819 for more details)
I'm trying to keep master branch to be clean, and experimenting with layout for myself in separate branch: https://github.com/cub-uanic/tmk_keyboard/tree/cub_layout - here you can find example howto use ACTION_* macros, for example how to use same key as Enter (on tap) or Control (when it's hold and other key pressed), how to configure your own keys (like TEENSY key on Ben's firmware) and so on.
Feel free to fork and improve, and send patches and pull requests.
-
so....... media keys... yes no maybe?
-
so....... media keys... yes no maybe?
This
-
so....... media keys... yes no maybe?
Media is fully supported by TMK so yes.
-
I posted this at massdrop, but every time I load up TMK firmware, my ergodox becomes very slow to respond/type, to the point that hitting the button on the teensy takes it 15 seconds to respond and show up in the teensy loader.
Can anyone else report if they've had this problem? I'm rocking ben's firmware without issue, but the promise of media key support (and other features) is just so tantalizing.
Edit: 15 SECONDS, not minutes. 15 minutes would be horrible!
Also for reference, here's what cub-uanic had my try last at massdrop, neither of which made a difference:
Please try to build from cub_layout branch, using "cd keyboard/ergodox && make -f Makefile.pjrc cub". Do you experience same problems?
As last resort, here is binary that I use: https://github.com/cub-uanic/tmk_keyboard/releases/download/e6ad104/ergodox_pjrc.hex
-
Media keys and dual role modifiers would be so awesome; anyone have success with this? I removed all of the build options in the makefile.pjrc, which reduces the firmware size significantly, but has not improved the performance for me. :/
-
... to the point that hitting the button on the teensy takes it 15 seconds to respond and show up in the teensy loader.
This just can't be, because Teensy's button and it's handling is implemented at hardware level, and currently uploaded firmware (either my port of TMK or Ben's firmware) can't affect this in any way.
-
Media keys and dual role modifiers would be so awesome; anyone have success with this?
I can confirm that dual-role keys works as expected, and I use them as for usual modifiers, like Shift/Ctrl/Alt/Win, as well for layer switching.
Also, I can confirm that mouse-related things (movement, wheel scroll, buttons) works as well.
I don't tried to use media keys though, and don't see why they shouldn't work.
-
... to the point that hitting the button on the teensy takes it 15 seconds to respond and show up in the teensy loader.
This just can't be, because Teensy's button and it's handling is implemented at hardware level, and currently uploaded firmware (either my port of TMK or Ben's firmware) can't affect this in any way.
I did some testing, and with the build options all turned off, the teensy button brings a system response within 3 to 5 seconds. With all of the build options on (except PS2, the default config you have posted), hitting the teensy button does not bring a response from the teensy loader until about 15 seconds have passed. In both cases, keys are delayed from showing up on screen while I type.
I agree about the hardware level; I'm thinking this is either an issue of my system trying to keep up with the information coming to it from the board, or the teensy is processing so much that it can't keep up, or maybe it's running at a slower speed than it should?
I'm running Win7 x64; what are you running?
PS: I haven't tested the media keys/dual role modifiers yet. I'm sure they work, but the slow responsiveness has been my main focus. I meant to ask has anyone gotten the firmware to work without slowness, not those features specifically.
-
cub-uanic, Great work!
I think diversity or another option will be welcomed, even though ErgoDox has already well documented and cleanly coded Ben's firmware. :D
fisofo,
I confirmed your problem, it took 20 sec on my Windows 7 64bit with full build options. This can be super annoying if you are developing or testing your firmware and program it 100 times a day. In this case you still can use other OS, at least Linux(Ubuntu) can recognizes it immediately in a few seconds even with full build options.
I think this problem doesn't prevent you from using it as a normal keyboard. Your problem appears only after pushing the reset button on Teensy for windows to recognize Teensy bootloader, right?
If so this will not be placed on the top of my TODO list, though I want to improve my code when the cause of the problem become appeared to me.
I removed all of the build options in the makefile.pjrc, which reduces the firmware size significantly, but has not improved the performance for me. :/
Opossitely my Windows recognized it immediately(in 3-5sec) with no build options firmware. And the more options the firmware has, the longer it takes to recognize. To have many build options means many endpoints. This may be a clue to solving.
In fact I tested with my own designed controller, which has same ATMega32U4 as Teensy but with Atmel bootloader instead of Teensy halfKay bootlader. Though, I don't think this is big difference for the problem.
-
One question that will decide if I switch (I can make my own colemak layout easy enough so that's no prob): does the teensy led work as a layer indicator?
-
CommunistWitchDr,
No. tmk doesn't support that feature.
-
hasu,
Thanks for stopping by! Yeah, the long teensy button time is annoying, but not really that big of a deal. The bigger issue I was having was the very slow typing speed I was experiencing with the TMK firmware. We've been running some tests and discussing over at the massdrop ergodox discussion (moving it here would probably be better), and cub-uanic just posted this most recent finding:
I just did some measurements, and here is results:
- TMK with I2C ~ 93.5 matrix scans per second
- TMK without I2C ~ 1714.5 !!!
- Ben's firmware ~ 200
What about to Ben's fw - I didn't measure this time, I just remember he said this somewhere - Ben, please correct me if I'm wrong.
So, what I can say:
1. currently, with my port of TMK you can't type faster than 90 chars per second
2. I2C slowing everything down 18 times! - definitely, something should be optimized :)
So yeah, we're trying to track that down. If you have any ideas, I'm sure we'd appreciate it :)
@cub-uanic: I haven't tested the builds you just posted, but I'll do so in a few hours:
I created two branches for you:
https://github.com/cub-uanic/tmk_keyboard/tree/no_i2c
https://github.com/cub-uanic/tmk_keyboard/tree/disable_all
Please try them both and let me know the difference between each of them and Ben's FW.
-
@cub-uanic: Per hasu's note, I'll stop posting my results of how long the teensy button takes to respond. The typing response times on both of the builds you just posted is very fast and in line with Ben's firmware; looks like you already knew that from your most recent post about I2C speed reduction though.
So yeah, I guess something needs to be optimized better there. I wish I knew this language better so I could be more helpful to you!
-
One question that will decide if I switch (I can make my own colemak layout easy enough so that's no prob): does the teensy led work as a layer indicator?
With my additions, TMK for Ergodox have support for all led's:
- three on right
- three on left (see http://geekhack.org/index.php?topic=22780.msg873819#msg873819 for more details)
- and Teensy's led as well
See cub_layout branch for details: https://github.com/cub-uanic/tmk_keyboard/blob/cub_layout/keyboard/ergodox/ergodox.h#L62-76
-
One question that will decide if I switch (I can make my own colemak layout easy enough so that's no prob): does the teensy led work as a layer indicator?
With my additions, TMK for Ergodox have support for all led's:
- three on right
- three on left (see http://geekhack.org/index.php?topic=22780.msg873819#msg873819 for more details)
- and Teensy's led as well
See cub_layout branch for details: https://github.com/cub-uanic/tmk_keyboard/blob/cub_layout/keyboard/ergodox/ergodox.h#L62-76
Nice, nice. But does it support turning on the teensy led when on a layer other than 0 by default?
-
One question that will decide if I switch (I can make my own colemak layout easy enough so that's no prob): does the teensy led work as a layer indicator?
With my additions, TMK for Ergodox have support for all led's:
- three on right
- three on left (see http://geekhack.org/index.php?topic=22780.msg873819#msg873819 for more details)
- and Teensy's led as well
See cub_layout branch for details: https://github.com/cub-uanic/tmk_keyboard/blob/cub_layout/keyboard/ergodox/ergodox.h#L62-76
Nice, nice. But does it support turning on the teensy led when on a layer other than 0 by default?
Yes, but not out of the box - you need to tweak sources a bit and then build it.
See here: https://github.com/cub-uanic/tmk_keyboard/blob/cub_layout/keyboard/ergodox/matrix.c#L108-L140
-
So yeah, we're trying to track that down. If you have any ideas, I'm sure we'd appreciate it :)
From looking at the code it seems like the i2c polling would be the first thing I would suspect. Perhaps moving to an ISR-based implementation is in order. I'd hack that in myself but I don't have my Ergodox yet. I have no experience with how that IO expander works so maybe it's not appropriate.
-
I just did some measurements, and here is results:
- TMK with I2C ~ 93.5 matrix scans per second
- TMK without I2C ~ 1714.5 !!!
- Ben's firmware ~ 200
What about to Ben's fw - I didn't measure this time, I just remember he said this somewhere - Ben, please correct me if I'm wrong.
So, what I can say:
1. currently, with my port of TMK you can't type faster than 90 chars per second
2. I2C slowing everything down 18 times! - definitely, something should be optimized :)
Glad to let you know that I found root of evil :)
TWI library that I used (written by Peter Fleury <pfleury@gmx.ch> http://jump.to/fleury) by default use olny 100kHz speed on I2C bus, while Teensy can operate on up to 400 kHz. This library doesn't have possibility to change I2C bus speed via #define or parameter in Makefile, so I had to hack it.
After change I2C bus speed to 400 kHz I got scan rate 298 scans/second!
And after additional optimization (excluding redundant calls to I2C) I got final 317 scans/second!
Of course it's far away from I2C-less variant (1714.5) - but this is 3.4 times faster than it was :)
@fisofo: please try my latest updates on cub_layout branch: https://github.com/cub-uanic/tmk_keyboard/tree/cub_layout
UPDATE:
According to ATmega16/32 secification, it can operate on up to 400 kHz speed on I2C.
But it's possible to get 444 kHz (this is highest value), and seems it works well.
Update is just pushed to my branch, and with it scan rate is 341 scans/second :thumb:
-
I just did some measurements, and here is results:
- TMK with I2C ~ 93.5 matrix scans per second
- TMK without I2C ~ 1714.5 !!!
- Ben's firmware ~ 200
What about to Ben's fw - I didn't measure this time, I just remember he said this somewhere - Ben, please correct me if I'm wrong.
So, what I can say:
1. currently, with my port of TMK you can't type faster than 90 chars per second
2. I2C slowing everything down 18 times! - definitely, something should be optimized :)
Glad to let you know that I found root of evil :)
TWI library that I used (written by Peter Fleury <pfleury@gmx.ch> http://jump.to/fleury) by default use olny 100kHz speed on I2C bus, while Teensy can operate on up to 400 kHz. This library doesn't have possibility to change I2C bus speed via #define or parameter in Makefile, so I had to hack it.
After change I2C bus speed to 400 kHz I got scan rate 298 scans/second!
And after additional optimization (excluding redundant calls to I2C) I got final 317 scans/second!
Of course it's far away from I2C-less variant (1714.5) - but this is 3.4 times faster than it was :)
@fisofo: please try my latest updates on cub_layout branch: https://github.com/cub-uanic/tmk_keyboard/tree/cub_layout
UPDATE:
According to ATmega16/32 secification, it can operate on up to 400 kHz speed on I2C.
But it's possible to get 444 kHz (this is highest value), and seems it works well.
Update is just pushed to my branch, and with it scan rate is 341 scans/second :thumb:
Awesome! I just tested it and it's smooth as butter; nice work! Can't wait to use it to build a new layout, thanks for tracking that down!
-
One question that will decide if I switch (I can make my own colemak layout easy enough so that's no prob): does the teensy led work as a layer indicator?
With my additions, TMK for Ergodox have support for all led's:
- three on right
- three on left (see http://geekhack.org/index.php?topic=22780.msg873819#msg873819 for more details)
- and Teensy's led as well
See cub_layout branch for details: https://github.com/cub-uanic/tmk_keyboard/blob/cub_layout/keyboard/ergodox/ergodox.h#L62-76
Nice, nice. But does it support turning on the teensy led when on a layer other than 0 by default?
Yes, but not out of the box - you need to tweak sources a bit and then build it.
See here: https://github.com/cub-uanic/tmk_keyboard/blob/cub_layout/keyboard/ergodox/matrix.c#L108-L140
Shame. I set up a colemak layout and quite like it, especially the mouse keys. I just can't get used to not having that light and know absolutely 0 c.
-
Media is fully supported by TMK so yes.
Clarification: media key support on Windows?
-
Media is fully supported by TMK so yes.
Clarification: media key support on Windows?
Short: yes
Long: Read: https://github.com/tmk/tmk_keyboard
-
So how would I adapt my layout generated from MassDrop to this firmware?
-
So how would I adapt my layout generated from MassDrop to this firmware?
You can edit the layout file (keymap.c) pretty easy, if you open the file it's self explanatory from there.
-
So how would I adapt my layout generated from MassDrop to this firmware?
You can edit the layout file (keymap.c) pretty easy, if you open the file it's self explanatory from there.
And read the link that I posted before. Hasu has very good instructions for building the firmware and modifying the keymap. The docs have everything you need to customize the firmware.
-
So a question: After switching to a layer in TMK, it seems I cannot then switch to ANOTHER layer. I first have to reset back to layer 0, and then switch to the other one. I gotta think I'm doing something wrong, but thus far I haven't figured it out; ideas?
Using the default cub layout as an example: I switch to layer 2, and then attempt a momentary switch to layer 1, but it doesn't go through. Thoughts?
-
Hmmm....
As you can see from sources, key to activate layer 5 is present only on layer 4 - and I can confirm that it works and layer 5 is accessible.
I just tried all layer switching keys - and seems only this one (activate L1 when current is L2) is not working.
I can't explain why.
May be Hasu can tell you, or someone from community?
Update: seems I found the problem.
It's not possible to get momentary switch to lower layer.
For example, when I'm hold FN6 or tap FN2, and layer 2 is active, then tap on FN1 does nothing, but FN3 and FN4 does momentary layer switch as expected.
Or other example: when I hold FN3 and layer 3 is active, then FN6 and FN1 does not work, but FN4 does momentary layer switch as expected and FN6 does layer switch as well.
So, I think this is bug in TMK itself, somewhere around momentary switching, and it's triggered only when layer number used in ACTION_LAYER_MOMENTARY macro is less than currently active layer.
I just filed bug on GitHub: https://github.com/tmk/tmk_keyboard/issues/59 - you can use it to track progress of changes.
-
After some thinking, seems this is not really bug - this is just result of how layers work.
Read doc/keymap.md file more carefully, especially "0. Keymap and layers" and "0.2 Layer Precedence and Transparency".
To achieve what you want (telepathy mode on :) ), you need not only momentary activate needed layer, but before you have to DE-activate current layer. Or even better, you should ACTION_LAYER_SET(0) and only then issue ACTION_LAYER_MOMENTARY to needed layer. So, you have to send two actions, at least. In theory, you can do this using ACTION_MACRO (or one of it's variants). But on practice, before you'll reset current layer to 0 you have to remember it, and on key release you have to restore it. So this should be user-defined function, like I did for TEENSY_KEY. Implementing this seems over-complicated as for me.
To be honest, I didn't even think about this "problem" just because I never hit it.
I'm pretty sure that Hasu will close my bug report as "won't fix" or "not a bug" and I will agree with him.
Try to re-think and reorganize your layers.
Try to avoid workflow like "layer 0 -> layer N -> layer M -> layer 0", and try to use simple "layer 0 -> layer N -> layer 0".
There is so many keys and so many ACTION* macros that I'm pretty sure that it's possible to avoid your problem.
-
That sort of makes sense, although I'd prefer it to not care about the layer #; seems silly that it can't go down a layer.
I do have one more situation that doesn't make sense to me: If I set the layer to 2, and then I set the layer to 5 (I just modified layer 2 slightly to have FN5 on it), I would expect transparent keys on 5 to reflect the keys from layer 2, but instead, the transparent keys reflect layer 0.
I can work around these oddities as you mentioned, I'm just trying to make sense of it. It's different than how Ben's firmware works, and between you and me, I like the logic his uses for layers more than TMK thus far ;)
-
That sort of makes sense, although I'd prefer it to not care about the layer #; seems silly that it can't go down a layer.
Sources are open and you more than welcome to make them better and clever :)
I do have one more situation that doesn't make sense to me: If I set the layer to 2, and then I set the layer to 5 (I just modified layer 2 slightly to have FN5 on it), I would expect transparent keys on 5 to reflect the keys from layer 2, but instead, the transparent keys reflect layer 0.
This is because you use ACTION_LAYER_SET.
Try to use ACTION_LAYER_ON/ACTION_LAYER_OFF instead.
I can work around these oddities as you mentioned, I'm just trying to make sense of it. It's different than how Ben's firmware works, and between you and me, I like the logic his uses for layers more than TMK thus far ;)
The difference is simple.
Ben's fw use real stack structure under the hood, while TMK use bit vector of active layers.
So, when you activate layers 2, 1, 3 (in that order), then Ben's fw will look at layer 3, then (if TRNS) 1, then 2, then 0.
In same situation TMK will just mark layers 0, 1, 2 and 3 as active, and as stated in doc/keymap.md - "***higher layer has higher priority on stack of layers***".
In your example (L2 then L5): Ben's fw will have [L0, L2, L5] in stack, and TMK will have only L0 and L5 bits set. This is so because L0 is always active, and ACTION_LAYER_SET will clear all other layer bits before set what you asked. If you'll use ACTION_LAYER_ON instead, you'll get L0, L2 and L5 bits set, because ACTION_LAYER_ON will NOT clear bits for all other layers. But then don't forget to put ACTION_LAYER_OFF somewhere :)
Once more again - please, read doc/keymap.md carefully, in will answer to (almost) all your questions.
And once more again - try to simplify your layers, this will solve (almost) all your problems.
And after all, simpler layers are simpler to learn/remember and use.
-
Thanks for the explanation cub! I do need to go read that document more closely, I skimmed it because I thought I already knew it, lol :))
Yeah, my layers will be pretty simple really, I was just trying to wrap my head around this before I got too far into designing it.
Anywho, thanks again!
-
@fisofo
We got excellent answer on GitHub, please read it carefully.
-
Yeah, that's a great explanation, thanks for the heads up!
-
For anyone interested, here is my layout, which I now have working to how Ben's works, with proper layer priorities: https://github.com/fisofo/tmk_keyboard/blob/cub_layout/keyboard/ergodox/keymap_fisofo.h (https://github.com/fisofo/tmk_keyboard/blob/cub_layout/keyboard/ergodox/keymap_fisofo.h)
And here's an SVG diagram to more easily see what is happening: https://github.com/fisofo/tmk_keyboard/blob/cub_layout/doc/keymap_fisofo.svg (https://github.com/fisofo/tmk_keyboard/blob/cub_layout/doc/keymap_fisofo.svg)
@CommunistWitchDr: I modified matrix.c in my branch to have the teensy light turn on when I am not on layer 0.
@daerid: Media keys work great! Did you get it figured out? The ErgoDox has been my first foray into building and pushing firmware to a device like this, so I'd be willing to post the steps I took for how to do it on Windows if you'd like (as in, what software to install, commands to run, etc...)
@Cub: Ben has a really handy function in his where capslock is turned on/off by holding both shift keys (See the "2_keys_capslock" and "shR2kcap" in here:https://github.com/benblazak/ergodox-firmware/blob/partial-rewrite/firmware/keyboard/ergodox/layout/common/keys.c.h (https://github.com/benblazak/ergodox-firmware/blob/partial-rewrite/firmware/keyboard/ergodox/layout/common/keys.c.h)). Any idea how to do that in TMK? I monkeyed around a bit, but couldn't nail it down.
-
@Cub: Also, the teensy key on the keyboard does not work for me at this point; does it work for you? On mine, the computer sees the keyboard disappear, but the teensy loader never detects it. I have to then unplug and plug it back in, and use the hardware button instead.
-
@Cub: Ben has a really handy function in his where capslock is turned on/off by holding both shift keys (See the "2_keys_capslock" and "shR2kcap" in here:https://github.com/benblazak/ergodox-firmware/blob/partial-rewrite/firmware/keyboard/ergodox/layout/common/keys.c.h (https://github.com/benblazak/ergodox-firmware/blob/partial-rewrite/firmware/keyboard/ergodox/layout/common/keys.c.h)). Any idea how to do that in TMK? I monkeyed around a bit, but couldn't nail it down.
Sorry but no.
I think you should ask Hasu about this (probably by opening new bug on GitHub), because this feature is not specific to Ergodox.
Also, keep in mind that "two Shifts" is already used as COMMAND key, but this is easy to change.
@Cub: Also, the teensy key on the keyboard does not work for me at this point; does it work for you? On mine, the computer sees the keyboard disappear, but the teensy loader never detects it. I have to then unplug and plug it back in, and use the hardware button instead.
Sometimes I have same problem, but is really very rare.
In most cases - about 99% - it works fine.
Maybe Hasu can help here too? :)
// I'm on Debian Linux, if this is important
-
@Cub: Ben has a really handy function in his where capslock is turned on/off by holding both shift keys (See the "2_keys_capslock" and "shR2kcap" in here:https://github.com/benblazak/ergodox-firmware/blob/partial-rewrite/firmware/keyboard/ergodox/layout/common/keys.c.h (https://github.com/benblazak/ergodox-firmware/blob/partial-rewrite/firmware/keyboard/ergodox/layout/common/keys.c.h)). Any idea how to do that in TMK? I monkeyed around a bit, but couldn't nail it down.
Sorry but no.
I think you should ask Hasu about this (probably by opening new bug on GitHub), because this feature is not specific to Ergodox.
Also, keep in mind that "two Shifts" is already used as COMMAND key, but this is easy to change.
As cub-uanic said, LShift+RShift is used for command in tmk by default.
At first you need to change IS_COMMAND in config.h. Then you can write code for "two shift" in ACTION_FUNCTION or ACTION_MACRO, I think. But these actions are not settled API and not enough documented yet, they may have unseen bugs.
Still you have source at least :) Feel free to fork and tweak it for your need!
@Cub: Also, the teensy key on the keyboard does not work for me at this point; does it work for you? On mine, the computer sees the keyboard disappear, but the teensy loader never detects it. I have to then unplug and plug it back in, and use the hardware button instead.
Sometimes I have same problem, but is really very rare.
In most cases - about 99% - it works fine.
Maybe Hasu can help here too? :)
// I'm on Debian Linux, if this is important
Yeah, I've also found this problem but no idea to solve it at this time :( If firmware size get to larger like 22-3KB the problem tends to appear with high probability. Maybe I should read datasheet elaborately again and get deep understanding of AVR acrchitecture.
So its workaround is to keep firmware small, if you don't need NKRO, Mousekey, BootMagic or other functions you can comment out those build options in Makefile. Try this.
-
Is there any way to force your function to be placed at a lower address in PROGMEM, regardless of the total firmware size?
-
Is there any way to force your function to be placed at a lower address in PROGMEM, regardless of the total firmware size?
I can't answer, I don't know :(
I know C and C++ to some degree, but I'm too far from AVR-specific things, like PROGMEM.
(btw, where I can read about this?...)
Hasu, any thoughts?...
-
The avr-libc documentation (http://www.nongnu.org/avr-libc/user-manual/index.html) is pretty good (especially see the user manual reference sections), as is the ATMega32U4 datasheet (http://www.pjrc.com/teensy/atmega32u4.pdf). Dean Camera's written some nice tutorials (http://www.fourwalledcubicle.com/AVRArticles.php) that I've found useful from time to time. And if you're ever board, my references page (https://github.com/benblazak/ergodox-firmware/blob/partial-rewrite/doc/references.md) lists almost every useful link I've looked at during this project, lol.
Specifically, to learn about PROGMEM, I'd start with this (http://www.nongnu.org/avr-libc/user-manual/pgmspace.html) (from the avr-libc docs). The quick version is that AVRs are Harvard architecture machines, and so have separate address spaces for different kinds of memory (as opposed to Von-Neuman architecture machines, like Intel chips, which have one address space for everything). PROGMEM is the flash area where program data is stored, SRAM is the normal (volatile) RAM (which is the address space things operate on by default in AVR C), and EEPROM is slow and nonvolatile but can be written to byte by byte (as opposed to the PROGMEM which can only be written to in pages).
-
Hmm... So after a quick search, I don't see any option to that effect. Perhaps it would help to make sure the file containing the bootloader function is early in the list of files passed when linking? lol. Looking at my firmware.map and the order in which *.o files were listed when building my firmware.elf seems to suggest that GCC places functions in the order it finds them, looking through the *.o files in the order they are passed.
-
Hi ic07,
Is there any way to force your function to be placed at a lower address in PROGMEM, regardless of the total firmware size?
Hmm... So after a quick search, I don't see any option to that effect. Perhaps it would help to make sure the file containing the bootloader function is early in the list of files passed when linking? lol. Looking at my firmware.map and the order in which *.o files were listed when building my firmware.elf seems to suggest that GCC places functions in the order it finds them, looking through the *.o files in the order they are passed.
To implement keymap editor I just have researched how to place object in fixed address for last a few week. I need the address of keymap array to edit/replace its data in hex file format.
http://geekhack.org/index.php?topic=12047.msg1035113#msg1035113
Yeah, I also didn't find no easy way to place object where you want, such like any gcc extensions or command line options weren't so useful. After all I needed to write own ld script to achive the purpose.
This is my modified version of ld script for fixed address keymap based on avr-gcc's original script. I added 'keymap' section at 0x68000 of ATMega32U4 with the script, the bottom of flash but just before bootloader section(Factory default 32U4 has 4KB region for this while Teensy has just 512B).
https://github.com/tmk/tmk_keyboard/blob/master/ldscript_keymap_avr5.x
And added 'section' attribution to the keymap array,
https://github.com/tmk/tmk_keyboard/blob/master/keyboard/hhkb/keymap.c#L52
const uint8_t keymaps[][MATRIX_ROWS][MATRIX_COLS] __attribute__ ((section (".keymap.keymaps"))) = {
then lastly gave this option to gcc(ld).
-Wl,-L$(TOP_DIR),-Tldscript_keymap_avr5.x
With this method I'll be able to put bootloader jump function anywhere. Do you think the placement of the function is a cause of the problem?
-
Wow, that looks like a lot of work! There were a few people considering writing a keymap editor for my rev-1 for a while, before Massdrop wrote their generator - but instead of putting the matrix in a known position, I wrote a script to extract the location and length of the matrix from the .map file, and put it into a JSON file. Your way is probably much less fragile though :)
I really don't have much understanding of what might cause a delay in the execution of the bootloader function... It just seems to me that if it's more likely to happen when the firmware is large, placement might be something to check...
-
Thank you, ic07.
Fxied the bootloader jump bug finally. I used byte address where it should be word address :o
https://github.com/tmk/tmk_keyboard/commit/0ca415004a453b2a841880d3a66492c664505737
I didn't found it until read asembly listing and AVR intstruction set document eraborately this time. Until this fix it should jump to non-existent flash address, I don't know why did it work. :)
-
what's the difference between using the pjrc and lufa makefiles? Is there an advantage to lufa? And if so, why doesn't it support nkro?
-
PJRC stack is no longer used by me and won't be tested and maintained actively from now on. NKRO is supported by LUFA too now.
See this issue and comments on github.
https://github.com/tmk/tmk_keyboard/issues/58#issuecomment-24491886
-
Good to know, thanks hasu!
-
So I tried merging hasu's changes into my own before I went on vacation, but didn't have time to test. I came back, merged a few more changes from the master branch, then tested, but the keyboard does not get recognized by windows.
I merged cub's changes back over mine, and for some reason I still can't get lufa to work, but at least pjrc is working for now. I haven't committed my build to git yet since it's currently broken.
What is the recommended way to get changes from the master branch without messing up the code that makes the ergodox work? And also, is lufa currently broken for ergodox? Thanks!
-
So I tried merging hasu's changes into my own before I went on vacation, but didn't have time to test. I came back, merged a few more changes from the master branch, then tested, but the keyboard does not get recognized by windows.
I merged cub's changes back over mine, and for some reason I still can't get lufa to work, but at least pjrc is working for now. I haven't committed my build to git yet since it's currently broken.
What is the recommended way to get changes from the master branch without messing up the code that makes the ergodox work? And also, is lufa currently broken for ergodox? Thanks!
I did a simple pull from tmk/master into a branch based on the latest revision in the cub_layout branch and it Just Worked™ when building with Makefile.lufa.
-
I've been playing around with this firmware over the weekend and almost have it working the way I want it to, although setting up a symbol layer with lots of shifted keys was a bit of a pain and left me almost out of available FN keys.
There's one bug that keeps me from using it though. The aforementioned symbol layer is reached by a key bound to ACTION_LAYER_MOMENTARY in fn_actions, and then I have for example ACTION_MODS_KEY(MOD_LSFT, KC_4) on my left index finger, really nice when coding perl! When I press these keys nice and slow all is well, but if I press them relatively fast the shift key seems to get stuck.
I've turned on DEBUG_ACTION and this is the log from that: http://pastebin.com/hHQwR2nG
Seems like it might be related to tapping, even though that action should as far as I know not really involve any tapping.
Has anybody else hit this bug?
-
bobkare,
I didn't confirm this bug myself yet, but I can come up with the clue.
I guess this bug appears when you release the LAYER_MOMEMTARY key before releasing the 'LShift+4' key.
I filed this bug on github issue tracker and will fix it later.
https://github.com/tmk/tmk_keyboard/issues/62
Thanks.
-
bobkare,
I didn't confirm this bug myself yet, but I can come up with the clue.
I guess this bug appears when you release the LAYER_MOMEMTARY key before releasing the 'LShift+4' key.
I filed this bug on github issue tracker and will fix it later.
https://github.com/tmk/tmk_keyboard/issues/62
Ah, yes, testing some more and paying more attention to the release order I think you're right.
Thanks!
-
bobkare, do you mind linking to your fork? I'd like to compare to see what I'm doing wrong. I did the pull request, but building using the lufa file is still not working. pjrc still works fine: https://github.com/fisofo/tmk_keyboard
-
fisofo,
I think this will fixed your problem on LUFA.
https://github.com/tmk/tmk_keyboard/commit/d267ee2adabdae333d77d4434ba8256c2270bc19
Or use INTERRUPT_CONTROL_ENDPOINT option of Makefile.
-
Hi guys,
I just tried to use LUFA again, after merging latest updates from Hasu, and it works fine.
But not without surprises.
First, and main: GUI version of Teensy loader won't update firmware, if keyboard is already on firmware with LUFA stack. If you reboot kbd - using KC_TEENSY or h/w button - only "Reboot" button is active on GUI, and "Program" button is grayed.
In other words, if now kbd is on PJRC, and you want to program it with LUFA using GUI Teensy loader - you can do this only once.
This is very frustrating, because if something is wrong with your new fw - you'r in ass :(
With PJRC you can select previous fw image by mouse, press h/w button on Teensy - and all will be fine.
With LUFA you can't.
Hopefully, it worked fine from first try, and so I was able to search and build teensy_loader_cli: http://www.pjrc.com/teensy/loader_cli.html
Using it, I was able to flash it again: make -f Makefile.pjrc teensy
Hasu, is this known problem?
How this can be solved?
And second, not so important: with LUFA stack kbd is bit slower (365 scans on lufa against 368 on pjrc), and bit more interesting - handling of KC_TEENSY is muuuuuuch slower (about 3 seconds on lufa against ~0.5 on pjrc). Is this can be solved?...
fisofo & bobkare - could you please try my latest update and share your experience?
-
First, and main: GUI version of Teensy loader won't update firmware, if keyboard is already on firmware with LUFA stack. If you reboot kbd - using KC_TEENSY or h/w button - only "Reboot" button is active on GUI, and "Program" button is grayed.
In other words, if now kbd is on PJRC, and you want to program it with LUFA using GUI Teensy loader - you can do this only once.
I'm not completely sure about the problem, you mean bootloader_jump() fails if you build with LUFA stack?
But I believe that reset(h/w) button on Teensy should always work even when you have rotten firmware.
Teensy uses PJRC original halfkay bootloader whose size is different from Atmel stock bootloader. As its name suggests size of halfKay is 512bytes while Atmel 4096. You should teach firmware which bootloader you are using with BOOTLOADER_SIZE option. Wrong size could result in wrong destination of bootloader_jump and going mad.
You must use 512 instead of 4096 on the option. and I don't think FLASH_SIZE_BYTES is needed. Strangely you have 512 correctly in Makefile.pjrc :)
https://github.com/cub-uanic/tmk_keyboard/blob/cub_layout/keyboard/ergodox/Makefile.lufa#L96-100
# Boot Section Size in *bytes*
# Teensy halfKay 512
# Atmel DFU loader 4096
# LUFA bootloader 4096
OPT_DEFS += -DBOOTLOADER_SIZE=4096 -DFLASH_SIZE_BYTES=0x8000
And second, not so important: with LUFA stack kbd is bit slower (365 scans on lufa against 368 on pjrc), and bit more interesting - handling of KC_TEENSY is muuuuuuch slower (about 3 seconds on lufa against ~0.5 on pjrc). Is this can be solved?...
Difference of scan rate looks natural to me, they are diffrent implementation. Slow startup will also be fixed with correct bootloader size, I think.
-
Thanks, with your proposed modifications all works like charm! :)
// incorrect values is result of previous experiments
-
fisofo & bobkare - could you please try my latest update and share your experience?
Latest version works for me too.
bobkare, do you mind linking to your fork? I'd like to compare to see what I'm doing wrong. I did the pull request, but building using the lufa file is still not working. pjrc still works fine: https://github.com/fisofo/tmk_keyboard
It's not public (yet), it wouldn't be very interesting anyway since I have been lazy and have nothing actually committed yet. My version was really as simple as clone from cub_uanic/cub_layout then pull from tmk/master with a few local changes mainly to the keymap.
-
Thanks guys, those latest changes resolved the issues I was having and now it builds with the lufa version just fine. Sweet!
-
Thanks for the port cub-uanic and hasu, works like a charm using the LUFA stack!
-
Hi guys,
Glad to let you know that I merged latest fixes from Hasu, and now firmware works just excellent!
Especially, tapping features now very smooth and really comfortable.
It seems even solved (or made it much less frequent) my problem with tapping:
https://github.com/tmk/tmk_keyboard/issues/59#issuecomment-24471266
Also, new layout is introduced, inspired by MicroDox:
- http://geekhack.org/index.php?topic=42231.msg1062851#msg1062851
- https://www.massdrop.com/ext/ergodox/?referer=CTL63V&hash=9ff8ddbb75e03e517aaa39acabc81669
Will be glad to get your feedback!
-
I've messed up remapping my ergodox - I was trying to remap it to dvorak. Used the supplied dvorak-kinesis-mod file.
Managed to run make in the parent folder and then stupidly loaded that onto the teensy. Worked out (in other words 'read') what I was doing wrong and then ran make in the src folder. Reloaded the firmware.eep and then firmware.hex onto the teensy.
I get three leds all nicely lit up, but nought else.
Could anyone please help? I'm not familiar with this stuff I'm afraid.
-
I get three leds all nicely lit up, but nought else.
Could anyone please help? I'm not familiar with this stuff I'm afraid.
First of all, please try to install some of my releases: https://github.com/cub-uanic/tmk_keyboard/releases
Does it work well for you? It have QWERTY and Workman, and don't have Dvorak yet - but it 100% works correctly, and so if something not work with it, then fix your keyboard first.
After that, when you will be sure that kbd works correctly - consider take some existing layout from my repository and tweak it so suit your needs. Do not take dvorak-kinesis-mod file supplied by Ben's firmware. TMK and Ben's firmwares are different and use different layout definitions, they completely incompatible.
-
Got it working again - thanks!
I think I got your mod confused with Ben's - sorry.
I'll start on a dvorak layout soon.
-
Hello, firstly thx for the work done here it's amazing i never knew i would be able to do so much with this keyboard.
But there is one thing that i wanted to do because i'm french and the way accents are implemented in french keyboards is so bad i wonder if i could make a specific layout that would send directly unicode / text instead of a key stroke.
at the moment i did macro that write alt+144 for É. But it's not very good, also if i could do things like @ on a specific layout would write down my full email.
anyway i'm not sure i can send something else than keystroke.
thank you again for taking the time of sharing all of this it's greatly appreciated.
-
But there is one thing that i wanted to do because i'm french and the way accents are implemented in french keyboards is so bad i wonder if i could make a specific layout that would send directly unicode / text instead of a key stroke.
at the moment i did macro that write alt+144 for É. But it's not very good, also if i could do things like @ on a specific layout would write down my full email.
In this aspect TMK for ErgoDox is not different from original TMK.
I think you are not first with such question, and most probably you'll find something useful if you'll try to search in TMK thread (http://geekhack.org/index.php?topic=41989).
-
All right thanks for pointing me out in the right direction. Looking into it.
-
oh i missed this, oh oh i wanna try this, i want media keys on my ergodox and they work fine on my phantom with TMK and it was pretty easy to program the phantom with TMK.
so here i go......
-
Hm, I seem to have installed the first version of the firmware. Was wondering why it was so sluggish :))
Though, I tried flashing your release .hex files, and in 98% of cases the keyboard hangs and the LED on the teensy lights up.
I am wondering if this could be because of the increased I2C bus frequency? My 4 pin cable is pretty long at 1 meter. Though I tried reverting I2C bus speeds to master branch and it did not work.
Any ideas? I'll keep trying :)
Edit
Applied I2C (https://github.com/cub-uanic/tmk_keyboard/commit/260d7b7707bd46c54964779a76d45a87af28ffdc) to master branch. Keyboard is much more responsive so it seem the scan frequency is not the problem. I'll continue this hunt tommorow.
Edit
Seem like this commit (https://github.com/cub-uanic/tmk_keyboard/commit/5329bbefee10503832d419733e6cfecb97e712cb)breaks my dox.
-
Hm, I seem to have installed the first version of the firmware. Was wondering why it was so sluggish :))
Though, I tried flashing your release .hex files, and in 98% of cases the keyboard hangs and the LED on the teensy lights up.
I am wondering if this could be because of the increased I2C bus frequency? My 4 pin cable is pretty long at 1 meter. Though I tried reverting I2C bus speeds to master branch and it did not work.
Any ideas? I'll keep trying :)
Edit
Applied I2C (https://github.com/cub-uanic/tmk_keyboard/commit/260d7b7707bd46c54964779a76d45a87af28ffdc) to master branch. Keyboard is much more responsive so it seem the scan frequency is not the problem. I'll continue this hunt tommorow.
Edit
Seem like this commit (https://github.com/cub-uanic/tmk_keyboard/commit/5329bbefee10503832d419733e6cfecb97e712cb)breaks my dox.
Master branch in my repo too old and actually not in development right now.
Please use https://github.com/cub-uanic/tmk_keyboard/tree/cub_layout instead.
If you want to make I2C slower, you can set TWBR = 12 (or even more) here: https://github.com/cub-uanic/tmk_keyboard/blob/cub_layout/keyboard/ergodox/twimaster.c#L38
Do you have same problems with Ben's firmware?
-
Master branch in my repo too old and actually not in development right now.
Please use https://github.com/cub-uanic/tmk_keyboard/tree/cub_layout instead.
If you want to make I2C slower, you can set TWBR = 12 (or even more) here: https://github.com/cub-uanic/tmk_keyboard/blob/cub_layout/keyboard/ergodox/twimaster.c#L38
Do you have same problems with Ben's firmware?
Yes, I am using the latest version from your branch. Like I said in the edit it is not the I2C speed that is causing me issues, but it is this specific commit (https://github.com/cub-uanic/tmk_keyboard/commit/5329bbefee10503832d419733e6cfecb97e712cb). If I go back one revision the firmware works as it should.
I have no idea how those changes are causing me issues tbh :-X
Hum, I rolled back the changes that you made in the commit I linked above. Now it works just fine on the latest version. Really strange that noone else is experiencing this.
Bens firmware worked great for the last few months though so I doubt the keyboard is faulty.
Edit
Found the issue!!
In ergodox.h the functions
inline void ergodox_led_all_on(void)
inline void ergodox_led_all_off(void)
Last line is ergodox_left_leds_update(); when it should be init_mcp23018();
After changing it to that the firmware boots and works. ;D
Does the fact that I dont have LEDs soldered on explain anything? Though I fail to see any dependancy...
-
Edit
Found the issue!!
In ergodox.h the functions
inline void ergodox_led_all_on(void)
inline void ergodox_led_all_off(void)
Last line is ergodox_left_leds_update(); when it should be init_mcp23018();
After changing it to that the firmware boots and works. ;D
Thanks, excellent catch!
Your fix is working, but call init_mcp23018() everywhere is overkill - it's enough to call it once during kbd initialization.
I improved it a bit and pushed to GitHub: https://github.com/cub-uanic/tmk_keyboard/commit/04949711f4abc89c921e48e35e8f818ebb5d3058
Please check how it works for you and give me some feedback.
Does the fact that I dont have LEDs soldered on explain anything? Though I fail to see any dependancy...
At my understanding - no, there is no any relation.
-
Excellent, it works! Thanks for the speedy reply.
I know it was overkill, but the only way to find it ^-^
Now to setup my own keymap. :)
Edit:
Thanks for porting TMK to dox and sharing it. :)
I've looked at TMK before, but never got around to attempt porting it.
-
This is great, it was pretty easy because i already used TMK for Phantom. Works Great!
MEDIA KEYS, GLORIOUS MEDIA KEYS! I HAVE MEDIA KEYS! (on windows)
Thanks all!
-
Chiming in to say this is awesome! Loving it for the media keys and the n-key rollover, plus of course the excellent layer support and customization options.
-
Is there a way to send shifted keys without having to write actions key for every single one?
Why would I want this? Because RDP sessions always delay recognition of the shift key; I'd like to create a layer of shifted keys to bypass the issue entirely.
Thoughts?
-
Short answer - afaik you can't do this in simple way, there is no direct support for such things in firmware.
Bit longer - you can write something what I did for KC_TEENSY, and in action_function() you can analyze which key was pressed and send what you want. This means you should set same value for all keys on layer, what you want to be shifted. Also, this means that you will have your layout definition in code, not in handy KEYMAP() macro.
Something like this:
.......
KEYMAP(
TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,
TRNS,FN31,FN31,FN31,FN31,FN31,TRNS,
..........
.......
enum function_id {
TEENSY_KEY,
SHIFTED_KEY,
};
static const uint16_t PROGMEM fn_actions[] = {
..........
ACTION_FUNCTION(SHIFTED_KEY), // FN31 - Shifted keys
};
.......
void action_function(keyrecord_t *event, uint8_t id, uint8_t opt)
{
if (id == TEENSY_KEY) {
........
else if ( id == SHIFTED_KEY) {
// explore event.event.pressed, event.event.key.col, event.event.key.row
// don't forget to differentiate key presses and releases
if (event.event.key.col==2 && event.event.key.row==2) ....; // do same thing as ACTION_MODS_TAP_KEY(MOD_LSFT, KC_Q)
}
}
And now main thing.
I think even if you do this - this will not save you.
But you can try, I can be wrong :)
Right now, when you use shifted keys over RDP - are they works correctly and without delays?
// Some day, when I will not be so lazy and busy - may be I'll do this, who knows...
-
Thanks Cub; yeah, turns out sending something like ACTION_MODS_TAP_KEY(MOD_LSFT, KC_Q) doesn't work, shift is delayed too much. So annoying! I have to hit shift and then wait a moment for it to register before continuing to type.
I'm also having problems getting a held down shift key to be recognized in logmein; anyone using that and noticed this issue with the latest logmein update?
-
Oh man I am so stoked to try this out! Will rebase my layout on top of this at lunch :D
-
Is there a simple step by step set of instructions for this anywhere? I could figure it out, but I really don't want to **** around with it too much. Just want dem media keys yo
-
...you can write something what I did for KC_TEENSY, and in action_function() you can analyze which key was pressed and send what you want...
I just did this for my layout, and it works like a dream. I did it to expand the number of macro keys above the limit of 32 FN codes, and it went just fine. I'm using it to create a layer that contains shortcuts like Alt F4 or Win L.
-
...you can write something what I did for KC_TEENSY, and in action_function() you can analyze which key was pressed and send what you want...
I just did this for my layout, and it works like a dream. I did it to expand the number of macro keys above the limit of 32 FN codes, and it went just fine. I'm using it to create a layer that contains shortcuts like Alt F4 or Win L.
Where we can see your code? ;)
-
Oh man I am so stoked to try this out! Will rebase my layout on top of this at lunch :D
Waiting for your fork ;)
-
Where we can see your code? ;)
https://github.com/simonmelhart/tmk_keyboard/blob/simon_layout/keyboard/ergodox/keymap_simon.h#L310
Created a helper function called simon_hotkey() that takes an action macro and copies code over from process_action() to do the right thing with it. I call that function from action_function() with the appropriate action macro, depending on the pressed key event.
-
Ok, I ported all the stuff that was in my key mapping from ben's firmware, as well as a few minor additions. As with before, the main feature is that it has hardware vim emulation. Now that I have all the beautiful TMK features I've cribbed the a/; tap keys instead of the interior stretch index keys. I suspect I'll be less sore at the end of the day with this :) FWIW I *can* notice the delay when typing a single a, like in this post, but it's not so much that it bothers me, I just notice it.
The only think missing from my previous layout is a numpad layer, and that's just because it's late and I rarely use that layer. I'll almost certainly do it when I get around to it. Anyway, thanks so much for the porting effort, I certainly appreciate it!
(my fork: https://github.com/frioux/tmk_keyboard)
(my keymapping: https://github.com/frioux/tmk_keyboard/blob/master/keyboard/ergodox/keymap_frew.h)
I look forward to looking into workman more as well.
-
Just wanted to chime in and report success. I was able to build this and flash it to my ergodox with no problem. Nice work and thanks, @cub-uanic and @hasu!
Still tweaking my layout but I've been really liking the dual-role modifiers. I think there's a lot of flexibility here with the custom actions. I do worry about running over the 32 function limit though -- I think I'm already using like 20-25 because I like to have a lot of pre-shifted keys. I think it would be cool to do an entire layer of Ctrl+shift+<key> or an entire layer of Ctrl+Alt+<Key>, but obviously I'll run out of slots before I could get that implemented.
@daerid: It's actually pretty darn easy.
1. $ git clone https://github.com/cub-uanic/tmk_keyboard.git2. $ cd tmk_keyboard/keyboard/ergodox3. $ make -f Makefile.lufa <which> where <which> is which layout you want to build
4. tweak the layout file and repeat step 3. (you can also create a new layout and add it as a build option, instead of stealing someone else's -- I figured this out without too much trouble just by following existing patterns in the code)
Here's the official documentation: https://github.com/cub-uanic/tmk_keyboard/blob/master/doc/build.md
-
Working on a keymap configurator for the tmk firmware, i think we should have a cli based alternative..:)
Thanks for making tmk work with ergodox!
[attachimg=1]
-
Wow.. That is what I dream for my Ergodox. Cant wait for this to live!
-
That's nice looking work. Do you have anything you're willing to share yet?
-
Wow.. That is what I dream for my Ergodox. Cant wait for this to live!
That's nice looking work. Do you have anything you're willing to share yet?
Thanks! It really can't do much at the moment, it parses the keyboard.h file and displays it. I'll try to get it do something a little more useful and then i'd be happy to share it with you!
It's going to work with both keyboard and mouse by the way, and even other keyboards. The plan is to make it do at least as much as the Massdrop web app does, and be as easy to use.
-
Hi guys, hope I'm not derailing this thread too much, it is related to TMK fw, but I made a post here (http://geekhack.org/index.php?topic=54288.msg1228614#msg1228614) about the problems I'm having with my Ergodox, could someone please run a quick matrix test using the TMK firmware and tell me if you see the same behaviour with yours? It's just one key combo.
Thanks again, I bloody love it but my Ergodox is driving me totally crazy!! :-\
-
I just did some measurements, and here is results:
- TMK with I2C ~ 93.5 matrix scans per second
- TMK without I2C ~ 1714.5 !!!
- Ben's firmware ~ 200
What about to Ben's fw - I didn't measure this time, I just remember he said this somewhere - Ben, please correct me if I'm wrong.
So, what I can say:
1. currently, with my port of TMK you can't type faster than 90 chars per second
2. I2C slowing everything down 18 times! - definitely, something should be optimized :)
Glad to let you know that I found root of evil :)
TWI library that I used (written by Peter Fleury <pfleury@gmx.ch> http://jump.to/fleury) by default use olny 100kHz speed on I2C bus, while Teensy can operate on up to 400 kHz. This library doesn't have possibility to change I2C bus speed via #define or parameter in Makefile, so I had to hack it.
After change I2C bus speed to 400 kHz I got scan rate 298 scans/second!
And after additional optimization (excluding redundant calls to I2C) I got final 317 scans/second!
Of course it's far away from I2C-less variant (1714.5) - but this is 3.4 times faster than it was :)
@fisofo: please try my latest updates on cub_layout branch: https://github.com/cub-uanic/tmk_keyboard/tree/cub_layout
UPDATE:
According to ATmega16/32 secification, it can operate on up to 400 kHz speed on I2C.
But it's possible to get 444 kHz (this is highest value), and seems it works well.
Update is just pushed to my branch, and with it scan rate is 341 scans/second :thumb:
I have strange problem with this version, my computer wake's up instantly if i try to put it in sleep mode win and mac :s
-
I have been making some progress on the keymap editor, it's not complete but it might be useable for basic needs.
Here's how it looks right now:
[attachimg=1]
The built in help texts should give you some hints on how to use it (think vim :thumb:), and some documentation along with install instructions can be found on the github page:
https://github.com/CJNE/vikeys
-
mmm, lovely CUI. Nice!
-
mmm, lovely CUI. Nice!
Thank you!
And thanks for the nice firmware, i love the flexibility of it :)
Has there been any talks about merging this fork into the main tmk repo, to make the ErgoDox officially supported? I'd be happy to help out with that if anything is needed to make that happen!
-
mmm, lovely CUI. Nice!
Thank you!
And thanks for the nice firmware, i love the flexibility of it :)
Has there been any talks about merging this fork into the main tmk repo, to make the ErgoDox officially supported? I'd be happy to help out with that if anything is needed to make that happen!
Yes, yes, please incoporate ergodox support
I have tried copy the ergodox folder into the main tmk code and it works.
Perhaps cub can send a pull request to hasu?
-
What are the pros and cons of TMK over the stock ergodox firmware?
-
What are the pros and cons of TMK over the stock ergodox firmware?
For me these are the advantages:
* Layer-Tap-Toggle feature lets me put my Fn and Fn-lock on the same key (5 taps to lock). I would need two keys for layer hold vs layer lock in Ben's firmware.
* Mods-Key feature lets you send any key combined with any modifiers which. The web-based tool at Massdrop that generates Ben's firmware only supports limited Shift-<key> options. With TMK you could for example put Ctrl-Alt-Del into a single keystroke. Many layouts I've seen and tried use this feature but I'm not using it at the moment. I think this feature is more important when you start getting into keyboards with far fewer keys than Ergodox has.
* Mods-Tap feature lets you give one key two roles. I'm using this feature for all of my modifier keys: on the bottom row I have LCTL dual with `~, LALT with NUBS, LGUI with LEFT, LSFT with RGHT, RSFT with UP, RGUI with DOWN, RALT with [{, and RCTL with ]} (Mac modifier order combined Kinesis bottom row keys). I can't do this with Ben's firmware.
I recommend reading https://github.com/tmk/tmk_keyboard/blob/master/doc/keymap.md to see what other options are available.
I found it easy to easy to just modify a keymap.c file and compile my own source but then I'm already comfortable with C and AVR programming.
If you prefer being able to download pre-compiled hex files, or if all the features you want are supported by the Massdrop config tool then you could stick with Ben's firmware, otherwise I'd give TMK a try.
-
What are the pros and cons of TMK over the stock ergodox firmware?
TMK also supports nkro, meaning it can sense an unlimited number of keys at once. This is essential for me for using it with Plover as a chorded keyboard for stenography.
TMK also has macros so you can make it do a lot of stuff when you hit a single key. I'm not sure if stock firmware can do this.
I have it set so when I hit a single key, it switches layers to a layer for steno (keys are rearranged), enters a combination of keys at once to activate the steno software, lights the led on the teensy and prints a message on the hid_debug screen to tell me that it has switched to the stenography layout. All from pressing a single key!
-
In my own defense, tap/hold keys and macro keys (which cover everything mentioned in the last two posts except for NKRO i think) are both possible in my firmware, and not difficult in rev-2. But in everyone else's defense, it's true that they're not supported by the Massdrop config tool. They're also very poorly documented at the moment, and probably not intuitively obvious to anyone but me :/ . I do plan to fix that someday -- once school stops bothering me :) .
Of course, Hasu's firmware is very good, and more mature than mine :) . And it does have NKRO and mouse keys -- and maybe a couple other things I can't recall at the moment -- that mine doesn't have, at least for now.
-
What are the pros and cons of TMK over the stock ergodox firmware?
I forgot one other feature I'm using that you can't do with the Massdrop firmware -- media keys. I have access to play/pause, next track, prev track, volume up, volume down, and mute.
It looks like you can do that with Ben's firmware as well if you compile from source rather than relying on Massdrop's tool.
-
One potential con: limited number of key functions. That is, in TMK, you can program up to 32 "special" keys, like layer switches and stuff, but if you want more, you need to get tricky with the action_function keys and reading key codes off and stuff. This had me worried at first, but it has worked out fine.
To echo clickclack, the NKRO seems to me to be the primary differentiator. I also like having my layout in code as opposed to the mass drop tool, but as ic points out, you can go source on his, too.
-
Ok thanks for the responses. Completely forgot I'd asked which is a nice surprise to find an array of responses!
So I think I'm sold on the modifiers. Is there a limit to the number of keys you can assign to a key? For example photoshop has a wince-inducing Option-Shift-Command-S save for web shortcut. I'd quite like access to that.
I've got a layout I've been tweaking, but I want to add helper functions to layer 1 https://www.massdrop.com/ext/ergodox/?referer=8NKMPV&hash=90050759c45b2f144b0eae83ba1d5e94
Would be pretty neat to assign a bunch of awkward shortcuts to that layer.
For the layer lock - do I have to press it five times or is that configurable? Can I just have a standard layer push/pop if I wanted?
I'm comfortable editing c files so no problem there. I like the idea of being able to place my layout under version control! Although I'd probably still use massdrop for quick layout visualisation!
-
Layer lock is totally configurable: I have mine set to 2.
-
Is it currently possible to use switches with integrated diodes with this firmware? I think it was in the OP that this kind of configuration wasn't supported at the time, but has anything changed?
Unfortunately, Ben's firmware doesn't compile on my system now.
-
Is it currently possible to use switches with integrated diodes with this firmware? I think it was in the OP that this kind of configuration wasn't supported at the time, but has anything changed?
Unfortunately, Ben's firmware doesn't compile on my system now.
You need to change the source code, but I opened half of the switches and changed the direction of the diodes.
-
What exactly do I need to change, if it's possible? I'm still getting familiar with the code and maybe I've missed something.
-
What exactly do I need to change, if it's possible? I'm still getting familiar with the code and maybe I've missed something.
I don't know exactly, I didn't change the code, I changed the switches.
If you really want to modify the code, I think you can check matrix.c (and maybe ergodox.c) and the read_cols(), select_row() and related functions
Also, since the diodes in the two halves will be in different direction, this should be taken into account when modifying the code.
-
Thanks for the reply. I don't seem to be getting anywhere with software, sooo...
-
Got the same problem, got a bit too solder happy with built in diodes :)
It is possible to fix it in firmware, was just inspecting the code. Going on vacation for a week, but will probably hack something together when I get back. Ill need to do some gut pulling it seems.
If you are in a hurry just swap the diodes, otherwise you can wait a week or two.
-
I have tried copy the ergodox folder into the main tmk code and it works.
Perhaps cub can send a pull request to hasu?
At first, I need to finish with 'official' part - I'd like to provide files for same mappings as in Ben's firmware (qwerty-kinesis-mod and others), so TMK fw could be used as drop-in replacement for Ben's fw.
Also I want to add support for semi-backlight, when backlight is not on each key, but on each half in whole.
After that I will be ready to send pull req to hasu.
Also, since the diodes in the two halves will be in different direction, this should be taken into account when modifying the code.
AFAIK this is not true.
On my kbd diodes soldered exactly same way on both left and right side.
Exactly as directed by assembly instruction on MD site: cathode of the diode (denoted with a line) connects to the square pad on the PCB.
Guys, so sorry but I don't have second kbd with diodes soldered unusual way, or built-in.
And unfortunately I don't have spare time to write support myself.
But I will be happy if someone will write it and send me pull req.
Also I will be happy if someone will send me for free :) new kit or assembled kbd (with swapped/built-in diodes) - in such case I will definitely add support and will make sure that it works properly :)
-
Also, since the diodes in the two halves will be in different direction, this should be taken into account when modifying the code.
AFAIK this is not true.
On my kbd diodes soldered exactly same way on both left and right side.
Exactly as directed by assembly instruction on MD site: cathode of the diode (denoted with a line) connects to the square pad on the PCB.
Sorry I didn't make the statement more clearly.
I mean if using switches with built-in diodes, the polarity of the diodes will be in opposite direction. Therefore in ben's firmware there are separate setting for diode direction in the two sides.
https://github.com/benblazak/ergodox-firmware/blob/master/src/keyboard/ergodox/options.h
Thanks for your work on this port, it is really great.
BTW, did you miss a line in Makefile?
include $(TOP_DIR)/protocol.mk
This is not necessary in ordinary use, but I need this to enable ps/2 converter code (for trackpoint)
It seems to increase the size of firmware though.
-
If there is still interest, I modded the firmware so that the left side can have its diodes reversed.
I can polish it up as its a hacked mess ATM and make it configurable via an include, if there is interest.
-
Cool! I'd definitely be interested in that, as I haven't had time to finish rebuilding my ergodox.
-
If there is still interest, I modded the firmware so that the left side can have its diodes reversed.
I can polish it up as its a hacked mess ATM and make it configurable via an include, if there is interest.
Great, thanks!
Waiting for pull request :)
-
Cool! I'd definitely be interested in that, as I haven't had time to finish rebuilding my ergodox.
Good to know :)
If there is still interest, I modded the firmware so that the left side can have its diodes reversed.
I can polish it up as its a hacked mess ATM and make it configurable via an include, if there is interest.
Great, thanks!
Waiting for pull request :)
;) Source needs to be tidied up. Also, should learn to use github :-[
It is a big hack but performance should be about the same.
-
it'd be nice to have an idiot's guide or even a full-blown app to create TMK firmware for ergodox... I'm for one don't have much knowledge about programming but still would love to be able to modify and update layouts using TMK rather than ben's firmware through massdrop thingy.
-
I think this work should be integrated in the main repo, you mentioned sending a PR when you had some more features up and running, but things work very well as it is.
Why not send a PR now, and if there are any other changes, send more PR's?
The current state of things is hurting further development IMO.
-
I've just started using this. The implementation is much cleaner than Ben's firmware and I do love the mouse keys. I have a few problems:
1) Whenever my computer reboots, I have to unplug and then plug in my keyboard in order for it to work. Before that the top LED (not the Teensy LED) is on and no input is registered.
2) I don't seem to have n-key rollover. The option is set in the makefile but according to online testers, I only have 6-key rollover.
EDIT:
Fixed 2). In common/host.c, I changed
keyboard_nkro = false;
to
keyboard_nkro = true;
-
An update to 1) above:
Whenever I set my computer to sleep, it is awaken immediately by my ErgoDox. The top left LED light comes on and then it won't accept input (as it doesn't on startup).
-
Thanks for the awesome work cub.
Im trying this firmware with the cub_layout branch.
For the layout im using, the "TAB" key is not working, instead it works as "SLSH"
Any idea what went wrong?
EQL, 1, 2, 3, 4, 5, ESC,
TAB, Q, W, E, R, T, FN1,
LCTRL, A, S, D, F, G,
LSFT, Z, X, C, V, B, FN0,
LGUI, NUHS, BSLS, _VOLUP, _VOLDOWN, LCTRL, LALT, HOME, BSPC, DELETE, END,
QUOT, 6, 7, 8, 9, 0, MINS,
LBRC, Y, U, I, O, P, RBRC,
H, J, K, L, SCLN, QUOT,
FN2, N, M, COMM, DOT, SLSH, RSFT,
LEFT, UP, DOWN, RGHT, CAPS, RALT, RCTL, PGDN, PGUP, ENT, SPC),
PS it works with massdrop configuration firmwares.
-
problem solved by compile .lufa.
Got the same problem jagriff got
-
I'm wanting to write a macro for a key, and having a bit of trouble figuring out how to do it. Could anyone share some examples of how one would define, say Fn3 to type Ctrl+A, Ctrl+C, Alt+Tab ...?
I also know some folks have done some work to give "meaning" to the LEDs (Since I never use caps, scroll or number lock and certainly don't need an indicator on my ergodox for those things) Would someone like to share their code on that front?
-
problem solved by compile .lufa.
Got the same problem jagriff got
What did you have to do to compile with lufa instead of pjrc? I made a new makefile and added a few things (mimicking the lufa makefile from one of the other keyboards) but I got some errors. I tried playing with it but couldn't get it to work. This was a while ago so I don't remember the errors.
I ask because I read somewhere that the windows boot problem is related to pjrc, not lufa. I loved using the tmk firmware, but having to fiddle with the usb port every time I changed to Windows (from Linux) made me switch back to Ben's firmware.
-
Ugh. Finally got it working -- I wanted full NKRO to play with stenotype software and Massdrop's configurator doesn't support that. Problems encountered, so far:
1. It's damn difficult to find right tmk software for ergodox! Nothing in readme.md says about ergodox!!! I was lucky to find some comment in this thread, otherwise I would not know anything about its avaiability...
2. Cub-uanic's firmware feels very very sluggish when installed. When I hit speeds of 60+ WPM it eats a lot of letters. The problem is, debounce is too high. I lowered it from 5 to 2 and now it's fast and trigger-happy again, like default one from Massdrop.
3. NKRO does NOT work even if Makefile says yes... I had to edit common/host.c and set
bool keyboard_nkro = true;
4. vikeys works, but crashes in select mode when I press 'x'. Also I did not find TRNS anywhere in menus and had to copy it from neighbor cell. Also it sets insert as INT, it breaks compiling, I had to replace it with INS. Also it uses horrible color palette -- tiny blue letters are very difficult to see on black background. But anyway, it's very useful and it saved me a lot of time (it would take ages to do all mapping in text editor).
-
@burbilog
When you have n-key-rollover compiled in you activate the feature by pressing LSHFT+RSHFT+N.
@cub-uanic
Would you mind to give hasu a pull request for your latest ergodox tree. Having ergodox support in upstream would be great!
-
@cub-uanic: you should merge that branch to master, i tried the firmware and was unable to use it until i searched on google and found this thread where i tried the cub branch, NOW i can use it with ergodox, otherwise is so damn slow to type on it that the keys are not even pressed correctly :)
-
Considering the situation in Ukraine, cub-uanic is not likely to handle this in the near future.
-
@burbilog
When you have n-key-rollover compiled in you activate the feature by pressing LSHFT+RSHFT+N.
Yeah, something deep in documentation, yes... is there any reason to run firmware without n-key-rollover by default?
-
Hi guys,
Sorry for long silence - I'm just too busy on work.
I'll try to answer to last questions.
Considering the situation in Ukraine, cub-uanic is not likely to handle this in the near future.
I'm living in Kharkov, and situation here is relatively clam and quiet (at least, for now).
@cub-uanic: you should merge that branch to master, i tried the firmware and was unable to use it until i searched on google and found this thread where i tried the cub branch
NOW i can use it with ergodox, otherwise is so damn slow to type on it that the keys are not even pressed correctly :)
I do not see my fork as finished and have to polish some things before sending pull req to @hasu.
Would you mind to give hasu a pull request for your latest ergodox tree. Having ergodox support in upstream would be great!
Yes, this will be good thing... but read my previous reply.
Don't see any need to rush, so please don't, thanks.
Problems encountered, so far:
1. It's damn difficult to find right tmk software for ergodox! Nothing in readme.md says about ergodox!!!
2. Cub-uanic's firmware feels very very sluggish when installed.
3. NKRO does NOT work even if Makefile says yes...
1. I'll be glad to see pull requests, especially for Ergodox-specific updates.
2. Don't use master branch from my fork - use https://github.com/cub-uanic/tmk_keyboard/tree/cub_layout instead.
3. Do not use pjrc, use lufa.
Want to repeat once more: I'll be glad to see any pull requests.
If you can't write code (and right now this is not really needed) - you can write documentation, like readme.md or FAQ.
If you can't write documentation (English is hard for you, or you just don't know correct answer) - you always can write questions.
I strictly prefer to use GitHub all the times, because it's hard and inconvenient to find in several pages on forum thread which question were answered and which are not.
Even to ask questions you can use GitHub's built-in editor, for example:
https://github.com/cub-uanic/tmk_keyboard/edit/cub_layout/keyboard/ergodox/Ergodox-FAQ.md
Don't hesitate to open bugs, feature requests and - yeah, again :) - send pull requests!
-
I'm living in Kharkov, and situation here is relatively clam and quiet (at least, for now).
Really glad to hear this! Hope things will get better...
I have made slight modifications to suit my need, mainly 80-key support and my custom keymap.
Will clean it and post, if someone is interested.
-
Don't see any need to rush, so please don't, thanks.
"Release early, release often" -- that's how Linux was built. Jokes aside, there is no need to merge everything into hasu's upstream, BUT Google, first post in this thread and various Plover-related websites they all point to your MAIN repository. And that's the problem, because your main repository doesn't say anything about using lufa or checking out some obscure branch. As result, everybody is doomed to do the same what I did: find about cub-uanic's firmware from the web, clone main branch and stumble upon bugs that were fixed many months ago...
This morning I found shayneholmes's fork with plover support, but it doesn't appear in searches like your firmware does :(
1. I'll be glad to see pull requests, especially for Ergodox-specific updates.
2. Don't use master branch from my fork - use https://github.com/cub-uanic/tmk_keyboard/tree/cub_layout instead.
3. Do not use pjrc, use lufa.
Okay. I go to that new link, git clone the url on that page, and huh? Where is Makefile.lufa? There is no Makefile.lufa... and no instructions how to fetch it :) Ok, ok, I know what to do, but somebody who isn't that familiar with git won't know what to do.
I strictly prefer to use GitHub all the times, because it's hard and inconvenient to find in several pages on forum thread which question were answered and which are not.
Okay. I went to your GitHub repository and where is Issues tab to fill a new issue?..
Please, please, just add a big notice in README.md in *main* branch saying that it's not actively developed and how to extract correct version of your firmware.
-
I have made slight modifications to suit my need, mainly 80-key support and my custom keymap.
Will clean it and post, if someone is interested.
I will be glad to see your pull req.
Okay. I go to that new link, git clone the url on that page, and huh? Where is Makefile.lufa? There is no Makefile.lufa... and no instructions how to fetch it :) Ok, ok, I know what to do, but somebody who isn't that familiar with git won't know what to do.
Okay. I went to your GitHub repository and where is Issues tab to fill a new issue?..
Please, please, just add a big notice in README.md in *main* branch saying that it's not actively developed and how to extract correct version of your firmware.
https://github.com/cub-uanic/tmk_keyboard/blob/cub_layout/keyboard/ergodox/Makefile.lufa
https://github.com/cub-uanic/tmk_keyboard/issues (surprisingly, it's not enabled by default and had to be enabled on repo settings)
Will be glad to get your pull req with fix for readme in master branch :)
Also, I fixed link in first post to point to cub_layout branch.
-
2. Don't use master branch from my fork - use https://github.com/cub-uanic/tmk_keyboard/tree/cub_layout instead.
This helps immensely! I was tinkering around with the old code, and despite being able to fix a few things, I couldn't get it to work as I wanted. I will test later on Windows.
-
Thanks for your work cub-uanic
Just got my ergodox from massdrop last week and I have a couple questions about this firmware
- I'm not sure what the Magic + H does, Is this a menu that will pop up regardless of what platform and program is open?
- I would like to configure my leds to indicate the active layer. I read that can be done, but I haven't seen an example for this firmware. Can someone please post an example or a link? Thanks
-
Thanks for your work cub-uanic
Just got my ergodox from massdrop last week and I have a couple questions about this firmware
- I'm not sure what the Magic + H does, Is this a menu that will pop up regardless of what platform and program is open?
- I would like to configure my leds to indicate the active layer. I read that can be done, but I haven't seen an example for this firmware. Can someone please post an example or a link? Thanks
See replies in latest update to https://github.com/cub-uanic/tmk_keyboard/blob/cub_layout/keyboard/ergodox/Ergodox-FAQ.md
-
cub-uanic,
I checked out the updated FAQ. I plan on adding the 3 left leds this weekend. Thanks for the info
-
I don't suppose anyone is using this firmware with OSX? I've been seeing some odd behaviour when I put my mac to sleep that after about 30 mins, it shuts down. (Ben's firmware doesn't have this behaviour for me)
Anyone else seeing anything like that? (this is with the lufa version)
-
I am on a Mac (10.9) and I haven't had this problem. When your Mac shuts down does it have a kernel panic, with the gray screen?
-
10.9.4 here and mostly I'm seeing in the console log a Sleep Wake Failure. This is on one of the new Mac Pros (6,1) so I wonder if there is something in there that is confusing the TMK firmware? My one thought was that it might be something to do with the Remote Wake feature that TMK has as Ben's original firmware doesn't support that. I'm also connecting via a usb hub if that's of any significance.
I've tried reverting to the original cub-uanic version without any of my changes and the issue is still there, whereas no problems with Ben's firmware. Thanks for any thoughts on this!
-
h1ro, I checked my console logs and didn't notice anything unusual. I would try without the USB hub. Sorry I couldn't be more help.
I wrote a little Ruby script to convert a password into the macro syntax, if anyone is interested:
https://gist.github.com/BlindLemonLipschitz/02fa5cbca244a25aa672 (https://gist.github.com/BlindLemonLipschitz/02fa5cbca244a25aa672)
-
@BlindLemonLipschitz thanks so much for checking your logs! I will continue to hunt for the issue :)
-
thanks cub and hasu for this, I am loving my ergodox more and more!
-
Hi,
Thank you so much cub-uanic for all your great work on tmk and implementing Ergodox compatibility.
I have a few questions if i may:
I am a bit of a noob but, i'm working on a "mod of Ergodox" to implement a 16X2 char LCD with some switches next to it, to be able to manually select the desired keyboard Layout from a list (displayed on the LCD and selected via switches next to the LCD)(basically one layout for each application, game...)
It is even possible to do it with a tweensy ++2 (46 I/O) and if i would have to rewrite huge portions of the code?
I'm wondering why is 32 the max amount of layers you can have? I mean could i use a 32 or 64bits variable instead of 16 to get more layers ? (Sorry if it's a stupid question as i said i am a bit of a noob)
And finally would it be even possible to create some kind of "profile structure", like each profile (selectable from my switches next to my LCD) would contain like 3 specific layers that would be available through the keyboard? An example i select the profile "MAYA" on my LCD and i have now access to 3 different layers i can switch from the keyboard itself, then when i'm done and close MAYA, i select the "DEFAULT" profile through the switches next my LCD and i now have access to 3 completely different layers.
Is all this just impossible or just really really difficult to achieve?
-
Hi all!
cub-uanic thank you so much for the ergodox port of TMK firmware!
I just recently received ErgoDox, assembled it and now I'm busy with its customization (programming). First of all, I've tried Ben Blazak's firmware and it was working quite well. But then I decided to try TMK firmware for ErgoDox and I see there are more great features (especially tapping feature)! TMK firmware is very configurable and I want to use its power.
And I'm puzzled. I want to have on the home row different keys: on the Layer0 there are usual hjkl (well, I use Dvorak so there are dhtn), on the Layer1 (which activates by means of, lets say, KEY1) there are navigation keys such as Left/Down/Up/Right, on the Layer2 there are -/PgDown/PgUp/-, on the Layer3 there will be probably the keys which will allow to focus windows (i3 windows manager). There is KEY2, which on Layer0 acts like a Alt key and on Layer1 acts like a LGUI. And you see there are a lot key combinations between mentioned keys and layers. Yes, instead of few-layers/many-keys I want many-layers/few-keys and configuration becomes a little bit complicated. Well, I configured everything and everything seems work but works not smoothly. For example, sometimes when I hit KEY1+KEY2+h and release these keys Layer1 stays active and overall very often after releasing I don't get Layer0 (with its hjkl on the home row). When I press that combination three layers are active. And in that context I want to believe that my question would be correct: how two of mentioned layers could be properly deactivated? Any suggestions about the best way to implement such configuration? May be there are common pitfalls?
Minor note: I cannot use ACTION_LAYER_SET_CLEAR(layer) for the KEY1 because I use ACTION_LAYER_TAP_KEY(1, KC_SPC) for it.
Also, there is a minor issue that I need to press KEY1 and KEY2 in strict order. Is possible to avoid that strictness?
Please note: everything written was about momentary switching between layers.
Thank you in advance!
-
Check this post and keymap doc for layer stuck problem.
http://geekhack.org/index.php?topic=57008.msg1492604#msg1492604
https://github.com/tmk/tmk_keyboard/blob/master/doc/keymap.md#31-momentary-switching
Minor note: I cannot use ACTION_LAYER_SET_CLEAR(layer) for the KEY1 because I use ACTION_LAYER_TAP_KEY(1, KC_SPC) for it.
Also, there is a minor issue that I need to press KEY1 and KEY2 in strict order. Is possible to avoid that strictness?
Use this configure and you can write same thing on Layer3 and Layer4.
Layer KEY1 KEY2
--------------------------------------------------------
0 TAP_KEY(1) MOMENTARY(2)
1 TAP_KEY(1) MOMENTARY(3)
2 MOMENTARY(4) MOMENTARY(2)
3 TAP_KEY(1) MOMENTARY(3)
4 MOMENTARY(4) MOMENTARY(2)
Or with using TRNS you can write keymap concisely like this.
Layer KEY1 KEY2
--------------------------------------------------------
0 TAP_KEY(1) MOMENTARY(2)
1 TRNS MOMENTARY(3)
2 MOMENTARY(3) TRNS
3 TRNS TRNS
-
Check this post and keymap doc for layer stuck problem.
http://geekhack.org/index.php?topic=57008.msg1492604#msg1492604
https://github.com/tmk/tmk_keyboard/blob/master/doc/keymap.md#31-momentary-switching
Minor note: I cannot use ACTION_LAYER_SET_CLEAR(layer) for the KEY1 because I use ACTION_LAYER_TAP_KEY(1, KC_SPC) for it.
Also, there is a minor issue that I need to press KEY1 and KEY2 in strict order. Is possible to avoid that strictness?
Use this configure and you can write same thing on Layer3 and Layer4.
Layer KEY1 KEY2
--------------------------------------------------------
0 TAP_KEY(1) MOMENTARY(2)
1 TAP_KEY(1) MOMENTARY(3)
2 MOMENTARY(4) MOMENTARY(2)
3 TAP_KEY(1) MOMENTARY(3)
4 MOMENTARY(4) MOMENTARY(2)
Or with using TRNS you can write keymap concisely like this.
Layer KEY1 KEY2
--------------------------------------------------------
0 TAP_KEY(1) MOMENTARY(2)
1 TRNS MOMENTARY(3)
2 MOMENTARY(3) TRNS
3 TRNS TRNS
Thank you very much hasu for the help!
Now I see that there is layer stuck problem but don't see any obvious way to configure everything without it. Also, it is not clear for me the way about avoiding keys order strictness (for example, I cannot use MOMENTARY for the Key2). I feel the lack of understanding how everything does work. And even if I'll get it then I don't think that everything would be clearer and better, as you see that there are additional layers required for additional key combinations. I afraid that I'll need a lot more layers to configure all desired combinations and in the end I'll get quite tricky configuration. Thereby you made me thinking that it would be probably easier and better (for further code understanding and maintenance) to write custom functions which will handle all complex multi-role key combinations.
Thank you!
-
Hi guys,
Here is small update:
- as asked by many people, now master branch is fresh and fully usable (actually it's same as cub_layout)
- refreshed core tmk files from tmp repo (should fix problem with sleeping)
- fixed compiling problem "keymap.c:211:46: error: unknown type name key_t"
- uploaded new release binaries to GitHub
-
Hey cub-uanic,
Thanks for porting this firmware to the ErgoDox! I've been using it for a few months now and love it.
I've never tried the mouse keys support before today, but so far I can't get it to work. I've pulled the latest from your repo, and verified that MOUSEKEY_ENABLE = yes is set in the make file, and using the lufa stack. I've defined a layer with the mouse movement, wheel movement, and buttons but none of them do anything. I keep thinking I'm missing a step to make them work, but if so I can't figure out what it is.
I'm running Windows 8.1 at the moment and don't have access to either a Linux or Mac machine so I can't see if it behaves any difference with a different OS.
-
Assuming that you have built firmware with correct keymap and build configuration, try one of these.
0) 'make clean' before build
1) change USB port, try other ports that you've never conected the keyboard.
2) remove all ErgoDox device entries in 'Device Manager'. You will see many entries under 'Human Interace Devices' in addition to 'Keyboards' and 'Mice and other pointing devices'.(in case Windows 7)
3) build with other USB VID or PID. you can change these in config.h.
When you change USB endpoint configuration(mouser key, nkro, console) you can have this kind of problem in Windows(at least in 7). Not sure but probably Windows caches driver setting somewhere using VID:PID as key so it cannot handle when seeing same VID:PID device with different endpoint configuration.
https://github.com/tmk/tmk_keyboard/wiki/FAQ-Build#edit-configuration-but-not-change
-
Thanks hasu, it was definitely windows caching the driver settings.
-
Are the media keys MNXT and MPREV supposed to work on OSX?
Volume, mute and play are working but not those two.
-
Hi, today I successfully built a trackpoint module into the right side of my ergodox keyboard following the tutorial in this thread: https://geekhack.org/index.php?topic=55960.0
and I'm extremely happy with the result (as I know very little about hardware stuff and C).
I wonder is it possible to include another trackpoint module into the left side of the ergodox,to have one at each side. As I said I know very little about hardware, but I'm eager to learn.
Could somebody point me to the right direction where to start?
Any help is appreciated.
Thank you!:)
-
I think there are 4 ways to do what you want:
1. build a left hand version of ergodox, so you will essentially have two ergodox (and teensy), each for one hand. The problem is that
you lost coordination between the two halves, such as layers and others.
2. modify the firmware, add support for additional PS/2 mouse device, problem is the second trackpoint will communicate to teensy through I2C, make the task a bit complicate.
3. connect two trackpoint module to one trackpoint controller. Each trackpoint module are actually one controller board connected to the trackpoint using 4 wires. You can connect the other trackpoint using 4 wires, but there will be an additional cable between the two halves, and I am not sure whether this will work with long cables (more than a few centimeters).
4. build an independent trackpoint module (only teensy and trackpoint) and connect to PC independently (not through your ergodox), this should be the easiest, but you will have one more USB connection. You can also add a USB hub in ergodox, to simplify your connection from ergodox to PC.
-
I think there are 4 ways to do what you want:
1. build a left hand version of ergodox, so you will essentially have two ergodox (and teensy), each for one hand. The problem is that
you lost coordination between the two halves, such as layers and others.
2. modify the firmware, add support for additional PS/2 mouse device, problem is the second trackpoint will communicate to teensy through I2C, make the task a bit complicate.
3. connect two trackpoint module to one trackpoint controller. Each trackpoint module are actually one controller board connected to the trackpoint using 4 wires. You can connect the other trackpoint using 4 wires, but there will be an additional cable between the two halves, and I am not sure whether this will work with long cables (more than a few centimeters).
4. build an independent trackpoint module (only teensy and trackpoint) and connect to PC independently (not through your ergodox), this should be the easiest, but you will have one more USB connection. You can also add a USB hub in ergodox, to simplify your connection from ergodox to PC.
I'd like to aim for the second option: wire the second trackpoint module to the MCP23018 and communicate via the existing I2C connection. But I don't really know where to start.
-
Hi,
Just wanted to say thank you to hasu and cub-uanic for all their contributions to the ergodox project. It changed my life!
Set up my ergodox in a way where I dont even need a mouse to do my work!
Love you guys! :thumb:
-
I finally got around to playing with the ErgoDox port of the TMK firmware. I'm still working on finalizing my own layout, but I've created a Dvorak layout based on Ben Blazak's dvorak-kinesis-mod layout.
I've also added the ability to hit both shift keys to toggle capslock (most of the code starts at line 363), and it's part of the keymap_dvorak.h below. Once I figure out github, I'll send cub-uanic a pull request:
static const uint8_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
// ........................................................................
// Layer0: default, dvorak in keyboard, qwerty in OS;
// Based on Ben Blazak's dvorak-kinesis-mod layout.
//
// left hand
// ,--------------------------------------------------.
// | = + | 1 ! | 2 @ | 3 # | 4 $ | 5 % | Esc |
// |--------+------+------+------+------+-------------|
// | Tab | ' " | , < | . > | p P | y Y | +L2 |
// |--------+------+------+------+------+------| |
// | CapsLk | a A | o O | e E | u U | i I |------|
// |--------+------+------+------+------+------| ~L2 |
// |LSft2Cap| ; : | q Q | j J | k K | x X | |
// `--------+------+------+------+------+-------------'
// | LGui | ` ~ | \ | | Left | Rght |
// `----------------------------------'
// ,-------------.
// | LCtl | LAlt |
// ,------|------|------|
// | | | Home |
// | BkSp | Del |------|
// | | | End |
// `--------------------'
//
// right hand
// ,--------------------------------------------------.
// | +L1 | 6 ^ | 7 & | 8 * | 9 ( | 0 ) | - _ |
// |------+------+------+------+------+------+--------|
// | +L2 | f F | g G | c C | r R | l L | / ? |
// | |------+------+------+------+------+--------|
// |------| d D | h H | t T | n N | s S | \ | |
// | ~L2 |------+------+------+------+------+--------|
// | | b B | m M | w W | v V | z Z |RSft2Cap|
// `-------------+------+------+------+------+--------'
// | Up | Down | [ { | ] } | RGui |
// `----------------------------------'
// ,-------------.
// | RAlt | RCtl |
// |------+------+------.
// | PgUp | | |
// |------| Entr | Spce |
// | PgDn | | |
// `--------------------'
//
KEYMAP( // Layer0: default, dvorak in keyboard, qwerty in OS;
// Based on Ben Blazak's dvorak-kinesis-mod layout.
// left hand
EQL, 1, 2, 3, 4, 5, ESC,
TAB, QUOT, COMM, DOT, P, Y, FN2,
CAPS, A, O, E, U, I,
FN29, SCLN, Q, J, K, X, FN4,
LGUI, GRV, BSLS, LEFT, RGHT,
LCTL, LALT,
HOME,
BSPC, DEL, END,
// right hand
FN1, 6, 7, 8, 9, 0, MINS,
FN2, F, G, C, R, L, SLSH,
D, H, T, N, S, BSLS,
FN4, B, M, W, V, Z, FN30,
UP, DOWN, LBRC, RBRC, RGUI,
RALT, RCTL,
PGUP,
PGDN, ENT, SPC
),
// ........................................................................
// Layer1: number pad;
// Based on Ben Blazak's dvorak-kinesis-mod layout.
//
// left hand
// ,--------------------------------------------------.
// | = + | 1 ! | 2 @ | 3 # | 4 $ | 5 % | Esc |
// |--------+------+------+------+------+-------------|
// | Tab | ' " | , < | . > | p P | y Y | +L2 |
// |--------+------+------+------+------+------| |
// | | a A | o O | e E | u U | i I |------|
// |--------+------+------+------+------+------| ~L2 |
// |LSft2Cap| ; : | q Q | j J | k K | x X | |
// `--------+------+------+------+------+-------------'
// | LGui | Ins | \ | | Left | Rght |
// `----------------------------------'
// ,-------------.
// | LCtl | LAlt |
// ,------|------|------|
// | | | Home |
// | BkSp | Del |------|
// | | | End |
// `--------------------'
//
// right hand
// ,--------------------------------------------------.
// | -L1 | | NmLk | Kp / | Kp * | Kp - | ScrLk |
// |------+------+------+------+------+------+--------|
// | +L2 | | Kp 7 | Kp 8 | Kp 9 | Kp + | PrtScn |
// | |------+------+------+------+------+--------|
// |------| | Kp 4 | Kp 5 | Kp 6 | Kp + | Pause |
// | ~L2 |------+------+------+------+------+--------|
// | | | Kp 1 | Kp 2 | Kp 3 | KEnt |RSft2Cap|
// `-------------+------+------+------+------+--------'
// | Kp 0 | Kp 0 | Kp . | KEnt | |
// `----------------------------------'
// ,-------------.
// | RAlt | RCtl |
// |------+------+------.
// | PgUp | | |
// |------| Entr | Spce |
// | PgDn | | |
// `--------------------'
//
KEYMAP( // Layer1: number pad;
// Based on Ben Blazak's dvorak-kinesis-mod layout.
// left hand
TRNS, TRNS, TRNS, TRNS, TRNS, TRNS, TRNS,
TRNS, TRNS, TRNS, TRNS, TRNS, TRNS, TRNS,
NO, TRNS, TRNS, TRNS, TRNS, TRNS,
TRNS, TRNS, TRNS, TRNS, TRNS, TRNS, TRNS,
TRNS, INS, TRNS, TRNS, TRNS,
TRNS, TRNS,
TRNS,
TRNS, TRNS, TRNS,
// right hand
TRNS, NO, NLCK, PSLS, PAST, PMNS, SLCK,
TRNS, NO, P7, P8, P9, PPLS, PSCR,
NO, P4, P5, P6, PPLS, PAUS,
TRNS, NO, P1, P2, P3, PENT, TRNS,
P0, P0, PDOT, PENT, NO,
TRNS, TRNS,
TRNS,
TRNS, TRNS, TRNS
),
// ........................................................................
// Layer2: symbols and function keys;
// Based on Ben Blazak's dvorak-kinesis-mod layout.
//
// left hand
// ,--------------------------------------------------.
// | = + | F1 | F2 | F3 | F4 | F5 | F11 |
// |--------+------+------+------+------+-------------|
// | Tab | { | } | [ { | ] } | | -L2 |
// |--------+------+------+------+------+------| |
// | CapsLk | ; : | / ? | - _ | 0 ) | : |------|
// |--------+------+------+------+------+------| ~L3 |
// |LSft2Cap| 6 ^ | 7 & | 8 * | 9 ( | + | |
// `--------+------+------+------+------+-------------'
// | LGui | ` ~ | \ | | Left | Rght |
// `----------------------------------'
// ,-------------.
// | LCtl | LAlt |
// ,------|------|------|
// | | | Home |
// | BkSp | Del |------|
// | | | End |
// `--------------------'
//
// right hand
// ,--------------------------------------------------.
// | F12 | F6 | F7 | F8 | F9 | F0 | Power |
// |------+------+------+------+------+------+--------|
// | +L2 | | _ | < | > | $ | Vol Up |
// | |------+------+------+------+------+--------|
// |------| \ | | 1 ! | ( | ) | = + | Vol Dn |
// | ~L3 |------+------+------+------+------+--------|
// | | * | 2 @ | 3 # | 4 $ | 5 % | Mute |
// `-------------+------+------+------+------+--------'
// | Up | Down | [ { | ] } | RGui |
// `----------------------------------'
// ,-------------.
// | RAlt | RCtl |
// |------+------+------.
// | PgUp | | |
// |------| Entr | Spce |
// | PgDn | | |
// `--------------------'
//
KEYMAP( // Layer2: symbols and function keys;
// Based on Ben Blazak's dvorak-kinesis-mod layout.
// left hand
TRNS, F1, F2, F3, F4, F5, F11,
TRNS, FN5, FN6, LBRC, RBRC, NO, TRNS,
TRNS, SCLN, SLSH, MINS, 0, FN7,
TRNS, 6, 7, 8, 9, FN8, FN3,
TRNS, TRNS, TRNS, TRNS, TRNS,
TRNS, TRNS,
TRNS,
TRNS, TRNS, TRNS,
// right hand
F12, F6, F7, F8, F9, F10, POWER,
TRNS, NO, FN9, FN10, FN11, FN12, _VOLUP,
BSLS, 1, FN13, FN14, EQL, _VOLDOWN,
FN3, FN15, 2, 3, 4, 5, _MUTE,
TRNS, TRNS, TRNS, TRNS, TRNS,
TRNS, TRNS,
TRNS,
TRNS, TRNS, TRNS
),
// ........................................................................
// Layer3: keyboard functions
// Based on Ben Blazak's dvorak-kinesis-mod layout.
//
// left hand
// ,--------------------------------------------------.
// | Teensy | | | | | | |
// |--------+------+------+------+------+-------------|
// | | | | | | | |
// |--------+------+------+------+------+------| |
// | | | | | | |------|
// |--------+------+------+------+------+------| |
// | | | | | | | |
// `--------+------+------+------+------+-------------'
// | | | | | |
// `----------------------------------'
// ,-------------.
// | | |
// ,------|------|------|
// | | | |
// | | |------|
// | | | |
// `--------------------'
//
// right hand
// ,--------------------------------------------------.
// | +L0 | | | | | | |
// |------+------+------+------+------+------+--------|
// | | | | | | | |
// | |------+------+------+------+------+--------|
// |------| | | | | | |
// | |------+------+------+------+------+--------|
// | | | | | | | |
// `-------------+------+------+------+------+--------'
// | | | | | |
// `----------------------------------'
// ,-------------.
// | | |
// |------+------+------.
// | | | |
// |------| | |
// | | | |
// `--------------------'
//
KEYMAP( // Layer3: keyboard functions
// Based on Ben Blazak's dvorak-kinesis-mod layout.
// left hand
FN31, NO, NO, NO, NO, NO, NO,
NO, NO, NO, NO, NO, NO, NO,
NO, NO, NO, NO, NO, NO,
NO, NO, NO, NO, NO, NO, NO,
NO, NO, NO, NO, NO,
NO, NO,
NO,
NO, NO, NO,
// right hand
FN0, NO, NO, NO, NO, NO, NO,
NO, NO, NO, NO, NO, NO, NO,
NO, NO, NO, NO, NO, NO,
NO, NO, NO, NO, NO, NO, NO,
NO, NO, NO, NO, NO,
NO, NO,
NO,
NO, NO, NO
),
/*
// templates to copy from
KEYMAP( // LayerN: transparent on edges + hard-defined thumb keys,
// all others are empty
// left hand
TRNS, NO, NO, NO, NO, NO, NO,
TRNS, NO, NO, NO, NO, NO, TRNS,
TRNS, NO, NO, NO, NO, NO,
TRNS, NO, NO, NO, NO, NO, TRNS,
TRNS, TRNS, TRNS, LALT, LGUI,
TRNS, TRNS,
TRNS,
LCTL, LSFT, TRNS,
// right hand
NO, NO, NO, NO, NO, NO, TRNS,
TRNS, NO, NO, NO, NO, NO, TRNS,
NO, NO, NO, NO, NO, TRNS,
TRNS, NO, NO, NO, NO, NO, TRNS,
RGUI, RALT, TRNS, TRNS, TRNS,
TRNS, TRNS,
TRNS,
TRNS, RSFT, RCTL
),
KEYMAP( // LayerN: fully transparent
// left hand
TRNS, TRNS, TRNS, TRNS, TRNS, TRNS, TRNS,
TRNS, TRNS, TRNS, TRNS, TRNS, TRNS, TRNS,
TRNS, TRNS, TRNS, TRNS, TRNS, TRNS,
TRNS, TRNS, TRNS, TRNS, TRNS, TRNS, TRNS,
TRNS, TRNS, TRNS, TRNS, TRNS,
TRNS, TRNS,
TRNS,
TRNS, TRNS, TRNS,
// right hand
TRNS, TRNS, TRNS, TRNS, TRNS, TRNS, TRNS,
TRNS, TRNS, TRNS, TRNS, TRNS, TRNS, TRNS,
TRNS, TRNS, TRNS, TRNS, TRNS, TRNS,
TRNS, TRNS, TRNS, TRNS, TRNS, TRNS, TRNS,
TRNS, TRNS, TRNS, TRNS, TRNS,
TRNS, TRNS,
TRNS,
TRNS, TRNS, TRNS
),
*/
};
/* id for user defined functions & macros */
enum function_id {
TEENSY_KEY,
// CUSTOM_KEY,
LSFT_2_CAP,
RSFT_2_CAP,
};
/*
* Fn action definition
*/
static const uint16_t PROGMEM fn_actions[] = {
[0] = ACTION_LAYER_SET(0, ON_PRESS), // FN0 = Set Layer0
[1] = ACTION_LAYER_TOGGLE(1), // FN1 = Toggle Layer1
[2] = ACTION_LAYER_TOGGLE(2), // FN2 = Toggle Layer2
[3] = ACTION_LAYER_MOMENTARY(3), // FN3 = Momentary Layer3
[4] = ACTION_LAYER_MOMENTARY(2), // FN4 = Momentary Layer2
[5] = ACTION_MODS_KEY(MOD_LSFT, KC_LBRACKET), // FN5 = shift+[ -> {
[6] = ACTION_MODS_KEY(MOD_LSFT, KC_RBRACKET), // FN6 = shift+] -> }
[7] = ACTION_MODS_KEY(MOD_LSFT, KC_SCOLON), // FN7 = shift+; -> :
[8] = ACTION_MODS_KEY(MOD_LSFT, KC_EQUAL), // FN8 = shift+= -> +
[9] = ACTION_MODS_KEY(MOD_LSFT, KC_MINUS), // FN9 = shift+- -> _
[10] = ACTION_MODS_KEY(MOD_LSFT, KC_COMMA), // FN10 = shift+, -> <
[11] = ACTION_MODS_KEY(MOD_LSFT, KC_DOT), // FN11 = shift+. -> >
[12] = ACTION_MODS_KEY(MOD_LSFT, KC_4), // FN12 = shift+4 -> $
[13] = ACTION_MODS_KEY(MOD_LSFT, KC_9), // FN13 = shift+9 -> (
[14] = ACTION_MODS_KEY(MOD_LSFT, KC_0), // FN14 = shift+0 -> )
[15] = ACTION_MODS_KEY(MOD_LSFT, KC_8), // FN15 = shift+8 -> *
[29] = ACTION_FUNCTION(LSFT_2_CAP), // FN29 = Toggle CapsLock
// if both Shifts hit
[30] = ACTION_FUNCTION(RSFT_2_CAP), // FN30 = Toggle CapsLock
// if both Shifts hit
[31] = ACTION_FUNCTION(TEENSY_KEY), // FN31 = Teensy bootloader
};
void action_function(keyrecord_t *record, uint8_t id, uint8_t opt)
{
// print("action_function called\n");
// print("id = "); phex(id); print("\n");
// print("opt = "); phex(opt); print("\n");
if (id == TEENSY_KEY) {
clear_keyboard();
print("\n\nJump to bootloader... ");
_delay_ms(50);
bootloader_jump(); // should not return
print("not supported.\n");
}
// Toggle capslock when pressing both left and right shift keys
//
if (id == LSFT_2_CAP || id == RSFT_2_CAP) {
uint8_t curr_weak_mods = 0;
// Set weak_mods value for each shift key
//
if (id == LSFT_2_CAP) {
dprintf("->left shift: %u\n", id);
curr_weak_mods = MOD_BIT(KC_LSHIFT);
} else {
dprintf("->right shift: %u\n", id);
curr_weak_mods = MOD_BIT(KC_RSHIFT);
}
if (record->event.pressed) {
// Get the previous weak_mods value
//
uint8_t prev_weak_mods = get_weak_mods();
dprintf("-->prev_weak_mods: %u\n", prev_weak_mods);
// When a shift key is pressed, check previous weak_mods value.
// If 0, then no shift key is held down.
// If not 0, then at least one shift key is held down.
//
if (prev_weak_mods != 0) {
// Toggle capslock if more than one shift key is pressed.
//
dprintf("--->press, toggle capslock\n");
add_key(KC_CAPSLOCK);
send_keyboard_report();
del_key(KC_CAPSLOCK);
send_keyboard_report();
} else {
// Set the appropriate weak_mods value if just one shift
// key is pressed.
//
dprintf("--->press, curr_weak_mods: %u\n", curr_weak_mods);
add_weak_mods(curr_weak_mods);
send_keyboard_report();
}
} else {
// Unset the weak_mods value when shift key is released.
//
dprintf("--->release, curr_weak_mods: %u\n", curr_weak_mods);
del_weak_mods(curr_weak_mods);
send_keyboard_report();
}
}
/*
* just an example of custom key implementation
* not really needed with custom keymap_fn_to_action(),
* because it will allow you to have 32 FN** keys on EACH layer
*
keyevent_t event = record->event;
if (id == CUSTOM_KEY) {
uint8_t layer = biton32(layer_state);
uint8_t col = event.key.col;
uint8_t row = event.key.row;
uint8_t handled = 0;
if (event.pressed) {
if (layer == XXX && col == XXX && row == XXX) {
action_macro_play(
MACRO(
...........
END)
);
handled++;
}
}
}
if (!handled) {
print("custom key not handled");
print(": layer "); pdec(layer);
print(", col "); pdec(col);
print(", row "); pdec(row);
print("\n");
}
}
*/
}
/*
* Translates Fn keycode to action.
*
* Allows for more than 32 Fn keycodes. This will provide up to 32 Fn
* keycodes per layer.
*
* This overrides the keymap_fn_to_action() function found at the end of
* keymap.c with an #if defined.
*
static const uint16_t PROGMEM fn_actions_1[] = {
[1] = ACTION_LAYER_TOGGLE(1), // FN1 = Toggle Layer1
[2] = ACTION_LAYER_TOGGLE(2), // FN2 = Toggle Layer2
[4] = ACTION_LAYER_MOMENTARY(2), // FN4 = Momentary Layer2
[29] = ACTION_FUNCTION(LSFT_2_CAP), // FN29 = Toggle CapsLock
// if both Shifts hit
[30] = ACTION_FUNCTION(RSFT_2_CAP), // FN30 = Toggle CapsLock
// if both Shifts hit
};
static const uint16_t PROGMEM fn_actions_2[] = {
[2] = ACTION_LAYER_TOGGLE(2), // FN2 = Toggle Layer2
[3] = ACTION_LAYER_MOMENTARY(3), // FN3 = Momentary Layer3
[5] = ACTION_MODS_KEY(MOD_LSFT, KC_LBRACKET), // FN5 = shift+[ -> {
[6] = ACTION_MODS_KEY(MOD_LSFT, KC_RBRACKET), // FN6 = shift+] -> }
[7] = ACTION_MODS_KEY(MOD_LSFT, KC_SCOLON), // FN7 = shift+; -> :
[8] = ACTION_MODS_KEY(MOD_LSFT, KC_EQUAL), // FN8 = shift+= -> +
[9] = ACTION_MODS_KEY(MOD_LSFT, KC_MINUS), // FN9 = shift+- -> _
[10] = ACTION_MODS_KEY(MOD_LSFT, KC_COMMA), // FN10 = shift+, -> <
[11] = ACTION_MODS_KEY(MOD_LSFT, KC_DOT), // FN11 = shift+. -> >
[12] = ACTION_MODS_KEY(MOD_LSFT, KC_4), // FN12 = shift+4 -> $
[13] = ACTION_MODS_KEY(MOD_LSFT, KC_9), // FN13 = shift+9 -> (
[14] = ACTION_MODS_KEY(MOD_LSFT, KC_0), // FN14 = shift+0 -> )
[15] = ACTION_MODS_KEY(MOD_LSFT, KC_8), // FN15 = shift+8 -> *
[29] = ACTION_FUNCTION(LSFT_2_CAP), // FN29 = Toggle CapsLock
// if both Shifts hit
[30] = ACTION_FUNCTION(RSFT_2_CAP), // FN30 = Toggle CapsLock
// if both Shifts hit
};
// Layer3: keyboard functions
// Based on Ben Blazak's dvorak-kinesis-mod layout.
static const uint16_t PROGMEM fn_actions_3[] = {
[0] = ACTION_LAYER_SET(0, ON_PRESS), // FN0 = Set Layer0
[31] = ACTION_FUNCTION(TEENSY_KEY), // FN31 = Teensy bootloader
};
#define FN_ACTIONS_SIZE (sizeof(fn_actions) / sizeof(fn_actions[0]))
#define FN_ACTIONS_1_SIZE (sizeof(fn_actions_1) / sizeof(fn_actions_1[0]))
#define FN_ACTIONS_2_SIZE (sizeof(fn_actions_2) / sizeof(fn_actions_2[0]))
#define FN_ACTIONS_3_SIZE (sizeof(fn_actions_3) / sizeof(fn_actions_3[0]))
action_t keymap_fn_to_action(uint8_t keycode)
{
uint8_t layer = biton32(layer_state);
action_t action;
action.code = ACTION_NO;
if (layer == 1 && FN_INDEX(keycode) < FN_ACTIONS_1_SIZE) {
action.code = pgm_read_word(&fn_actions_1[FN_INDEX(keycode)]);
}
if (layer == 2 && FN_INDEX(keycode) < FN_ACTIONS_2_SIZE) {
action.code = pgm_read_word(&fn_actions_2[FN_INDEX(keycode)]);
}
if (layer == 3 && FN_INDEX(keycode) < FN_ACTIONS_3_SIZE) {
action.code = pgm_read_word(&fn_actions_3[FN_INDEX(keycode)]);
}
// By default, use fn_actions from default layer 0.
// This is needed to get mapping for same key, that was used switch
// to some layer, to have possibility to switch layers back
if (action.code == ACTION_NO && FN_INDEX(keycode) < FN_ACTIONS_SIZE) {
action.code = pgm_read_word(&fn_actions[FN_INDEX(keycode)]);
}
return action;
}
*/
-
Just come across this thread, as the media keys in the original firmware did not work. I've made a simple Colemak/ QWERTY dual layer key map based on the source.
Next step I'll try to config the LED. ^-^
Thanks for the great work cub :thumb:
EDIT:
I just come across a weird situation, sometimes if I toggle my Colemak and QWERTY quickly, the toggle sometimes fail... Any thought please?
Or is it my fault of coding?
//
// jc: personalized Ergodox configuration
//
static const uint8_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
KEYMAP( // Layer0: default Colemak layout
// left hand
ESC, 1 ,2 ,3 ,4 ,5 ,EQL ,
TAB, Q ,W ,F ,P ,G ,FN1 ,
LSFT,A ,R ,S ,T ,D ,
LCTL,Z ,X ,C ,V ,B ,LBRC,
LALT,HOME,PGUP,PGDN,END ,
LGUI,MUTE,
VOLU,
BSPC,DEL ,VOLD,
// right hand
MINS, 6, 7, 8, 9, 0, GRV,
FN1 , J, L, U, Y,SCLN,BSLS,
H, N, E, I, O,QUOT,
RBRC, K, M,COMM, DOT,SLSH,RCTL,
LEFT,DOWN, UP,RGHT,CAPS,
MPLY,CALC,
MPRV,
MNXT,ENT , SPC
),
KEYMAP( // Layer1: QWERTY layer
// left hand
TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,
TRNS,Q ,W ,E ,R ,T ,TRNS,
TRNS,A ,S ,D ,F ,G ,
TRNS,Z ,X ,C ,V ,B ,TRNS,
TRNS,TRNS,TRNS,TRNS,TRNS,
TRNS,TRNS,
TRNS,
TRNS,TRNS,TRNS,
// right hand
TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,
TRNS, Y, U, I, O, P,TRNS,
H, J, K, L,SCLN,TRNS,
TRNS, N, M,TRNS,TRNS,TRNS,TRNS,
TRNS,TRNS,TRNS,TRNS,TRNS,
TRNS,TRNS,
TRNS,
TRNS,TRNS,TRNS
),
KEYMAP( // Layer2: function key layer
// left hand
FN2 ,F1 ,F2 ,F3 ,F4 ,F5 ,F11 ,
TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,
TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,
TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,
TRNS,TRNS,TRNS,TRNS,TRNS,
INS ,PSCR,
PAUS,
TRNS,TRNS,FN0 ,
// right hand
F12, F6, F7, F8, F9, F10,NLCK,
TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,
TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,
TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,
TRNS,TRNS,TRNS,TRNS,SLCK,
TRNS,TRNS,
TRNS,
TRNS,TRNS,TRNS
),
};
/* id for user defined functions */
enum function_id {
TEENSY_KEY,
};
/*
* Fn action definition
*/
static const uint16_t PROGMEM fn_actions[] = {
// Teensy key
ACTION_FUNCTION(TEENSY_KEY), // FN0 - Teensy key
// Layers switching
ACTION_LAYER_MOMENTARY(2), // FN1 - temporarily switch to Layer2 keys (f keys)
ACTION_LAYER_TOGGLE(1), // FN2 - Toggle Layer1 switch between Colemak and QEWRTY layout
};
void action_function(keyrecord_t *event, uint8_t id, uint8_t opt)
{
print("action_function called\n");
print("id = "); phex(id); print("\n");
print("opt = "); phex(opt); print("\n");
if (id == TEENSY_KEY) {
clear_keyboard();
print("\n\nJump to bootloader... ");
_delay_ms(250);
bootloader_jump(); // should not return
print("not supported.\n");
}
}
-
I don't know if it is mandatory but what if you add the index on the left of your FN lines?
/*
* Fn action definition
*/
static const uint16_t PROGMEM fn_actions[] = {
// Teensy key
[0] = ACTION_FUNCTION(TEENSY_KEY), // FN0 - Teensy key
// Layers switching
[1] = ACTION_LAYER_MOMENTARY(2), // FN1 - temporarily switch to Layer2 keys (f keys)
[2] = ACTION_LAYER_TOGGLE(1), // FN2 - Toggle Layer1 switch between Colemak and QEWRTY layout
};
-
(I deleted my post because I shouldn't be replying while tired.)
-
Can someone give me a hint on how to find out if this is compatible with the infinity ErgoDox?
-
Can someone give me a hint on how to find out if this is compatible with the infinity ErgoDox?
They are not compatible, Infinity uses different CPU.
-
Any chance of integrating the MCP23018 into the main TMK repo? It looks like the fork is now missing a year or so of updates.
-
Any chance of integrating the MCP23018 into the main TMK repo? It looks like the fork is now missing a year or so of updates.
Why not use QMK?