Announce: TMK firmware for ErgoDox

[bobkare]

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?

[hasu]

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]

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!

[fisofo]

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

[hasu]

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.

[cub-uanic]

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?

[hasu]

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

Code: [Select]

# 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.

[cub-uanic]

Thanks, with your proposed modifications all works like charm!

// incorrect values is result of previous experiments

[bobkare]

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.

[fisofo]

Thanks guys, those latest changes resolved the issues I was having and now it builds with the lufa version just fine. Sweet!

[dyuri]

Thanks for the port cub-uanic and hasu, works like a charm using the LUFA stack!

[cub-uanic]

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!

[hoggy]

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.

[cub-uanic]

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.

[hoggy]

Got it working again - thanks!

I think I got your mod confused with Ben's - sorry.

I'll start on a dvorak layout soon.

[kigiri]

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.

[cub-uanic]

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.

[kigiri]

All right thanks for pointing me out in the right direction. Looking into it.

[Glod]

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......

[Tensor]

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 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 breaks my dox.

[cub-uanic]

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 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 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?

[Tensor]

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. If I go back one revision the firmware works as it should.
I have no idea how those changes are causing me issues tbh 

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.   

Does the fact that I dont have LEDs soldered on explain anything? Though I fail to see any dependancy...

[cub-uanic]

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.   

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.

[Tensor]

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.

[Glod]

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!
 

[wuqe]

 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.

[fisofo]

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?

[cub-uanic]

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:

Code: [Select]

.......
    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...

[fisofo]

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?

[frew]

Oh man I am so stoked to try this out!  Will rebase my layout on top of this at lunch 

[daerid]

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

[wuqe]

...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.

[cub-uanic]

...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?

[cub-uanic]

Oh man I am so stoked to try this out!  Will rebase my layout on top of this at lunch 

Waiting for your fork

[wuqe]

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.

[frew]

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.

[jeffgran]

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.

Code: [Select]

$ git clone https://github.com/cub-uanic/tmk_keyboard.git2.

Code: [Select]

$ cd tmk_keyboard/keyboard/ergodox3.

Code: [Select]

$ 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

[CJNE]

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!

[mikelanding]

Wow.. That is what I dream for my Ergodox. Cant wait for this to live!

[kod]

That's nice looking work.  Do you have anything you're willing to share yet?

[CJNE]

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.

[clickclack123]

Hi guys, hope I'm not derailing this thread too much, it is related to TMK fw, but I made a post here 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!! 

[mr.bean]

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 

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

[CJNE]

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:


The built in help texts should give you some hints on how to use it (think vim  ), and some documentation along with install instructions can be found on the github page:
https://github.com/CJNE/vikeys

[hasu]

mmm, lovely CUI. Nice!

[CJNE]

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!

[plainbriny]

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?

[squarefrog]

What are the pros and cons of TMK over the stock ergodox firmware?

[wjanssens]

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.

[clickclack123]

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!