Author Topic: Announce: TMK firmware for ErgoDox  (Read 51832 times)

0 Members and 1 Guest are viewing this topic.

Offline cub-uanic

  • Thread Starter
  • Posts: 72
  • Location: Ukraine, Kharkov
Announce: TMK firmware for ErgoDox
« 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.
« Last Edit: Sat, 26 July 2014, 11:17:20 by cub-uanic »

ErgoDox Classic - Stock Clears
Teenesis - Kinesis Advantage powered by Teensy


Offline daerid

  • Posts: 4275
  • Location: Denver, CO
    • Rossipedia
Re: Announce: TMK firmware for ErgoDox
« Reply #2 on: Thu, 05 September 2013, 00:56:28 »

so....... media keys... yes no maybe?

This

Offline TD22057

  • Posts: 172
  • Location: Southern California
Re: Announce: TMK firmware for ErgoDox
« Reply #3 on: Fri, 06 September 2013, 12:45:00 »
so....... media keys... yes no maybe?

Media is fully supported by TMK so yes.

Offline fisofo

  • Posts: 65
Re: Announce: TMK firmware for ErgoDox
« Reply #4 on: Fri, 06 September 2013, 17:47:16 »
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:
Quote
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
« Last Edit: Fri, 06 September 2013, 17:50:14 by fisofo »

Offline fisofo

  • Posts: 65
Re: Announce: TMK firmware for ErgoDox
« Reply #5 on: Sat, 07 September 2013, 08:35:30 »
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. :/

Offline cub-uanic

  • Thread Starter
  • Posts: 72
  • Location: Ukraine, Kharkov
Re: Announce: TMK firmware for ErgoDox
« Reply #6 on: Sat, 07 September 2013, 09:19:03 »
... 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.

ErgoDox Classic - Stock Clears
Teenesis - Kinesis Advantage powered by Teensy

Offline cub-uanic

  • Thread Starter
  • Posts: 72
  • Location: Ukraine, Kharkov
Re: Announce: TMK firmware for ErgoDox
« Reply #7 on: Sat, 07 September 2013, 09:26:40 »
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.

ErgoDox Classic - Stock Clears
Teenesis - Kinesis Advantage powered by Teensy

Offline fisofo

  • Posts: 65
Re: Announce: TMK firmware for ErgoDox
« Reply #8 on: Sat, 07 September 2013, 09:43:56 »
... 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.
« Last Edit: Sat, 07 September 2013, 09:45:27 by fisofo »

Offline hasu

  • Posts: 3116
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: Announce: TMK firmware for ErgoDox
« Reply #9 on: Sat, 07 September 2013, 23:44:04 »
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.

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

TMK products:HHKB Alt  ⌨ConvertersAlps64FC660C AltFC980C Alt

Offline CommunistWitchDr

  • Posts: 479
  • Location: St. Louis, MO
  • >implying keyboards
Re: Announce: TMK firmware for ErgoDox
« Reply #10 on: Sat, 07 September 2013, 23:48:40 »
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?

Offline hasu

  • Posts: 3116
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: Announce: TMK firmware for ErgoDox
« Reply #11 on: Sun, 08 September 2013, 00:13:20 »
CommunistWitchDr,
No. tmk doesn't support that feature.
« Last Edit: Sun, 08 September 2013, 00:16:36 by hasu »
TMK products:HHKB Alt  ⌨ConvertersAlps64FC660C AltFC980C Alt

Offline fisofo

  • Posts: 65
Re: Announce: TMK firmware for ErgoDox
« Reply #12 on: Sun, 08 September 2013, 12:40:45 »
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:

Quote
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:

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

Offline fisofo

  • Posts: 65
Re: Announce: TMK firmware for ErgoDox
« Reply #13 on: Sun, 08 September 2013, 13:15:14 »
@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!

Offline cub-uanic

  • Thread Starter
  • Posts: 72
  • Location: Ukraine, Kharkov
Re: Announce: TMK firmware for ErgoDox
« Reply #14 on: Sun, 08 September 2013, 13:58:04 »
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

ErgoDox Classic - Stock Clears
Teenesis - Kinesis Advantage powered by Teensy

Offline CommunistWitchDr

  • Posts: 479
  • Location: St. Louis, MO
  • >implying keyboards
Re: Announce: TMK firmware for ErgoDox
« Reply #15 on: Sun, 08 September 2013, 17:03:50 »
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?

Offline cub-uanic

  • Thread Starter
  • Posts: 72
  • Location: Ukraine, Kharkov
Re: Announce: TMK firmware for ErgoDox
« Reply #16 on: Sun, 08 September 2013, 18:13:05 »
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

ErgoDox Classic - Stock Clears
Teenesis - Kinesis Advantage powered by Teensy

Offline wjanssens

  • Posts: 4
Re: Announce: TMK firmware for ErgoDox
« Reply #17 on: Sun, 08 September 2013, 18:20:00 »
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.

Offline cub-uanic

  • Thread Starter
  • Posts: 72
  • Location: Ukraine, Kharkov
Re: Announce: TMK firmware for ErgoDox
« Reply #18 on: Sun, 08 September 2013, 18:42:31 »
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:
« Last Edit: Sun, 08 September 2013, 18:59:00 by cub-uanic »

ErgoDox Classic - Stock Clears
Teenesis - Kinesis Advantage powered by Teensy

Offline fisofo

  • Posts: 65
Re: Announce: TMK firmware for ErgoDox
« Reply #19 on: Sun, 08 September 2013, 20:28:06 »

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!

Offline CommunistWitchDr

  • Posts: 479
  • Location: St. Louis, MO
  • >implying keyboards
Re: Announce: TMK firmware for ErgoDox
« Reply #20 on: Fri, 13 September 2013, 11:01:21 »
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.

Offline daerid

  • Posts: 4275
  • Location: Denver, CO
    • Rossipedia
Re: Announce: TMK firmware for ErgoDox
« Reply #21 on: Fri, 13 September 2013, 12:07:56 »
Media is fully supported by TMK so yes.

Clarification: media key support on Windows?

Offline TD22057

  • Posts: 172
  • Location: Southern California
Re: Announce: TMK firmware for ErgoDox
« Reply #22 on: Fri, 13 September 2013, 12:12:55 »
Media is fully supported by TMK so yes.

Clarification: media key support on Windows?

Short: yes
Long: Read: https://github.com/tmk/tmk_keyboard

Offline daerid

  • Posts: 4275
  • Location: Denver, CO
    • Rossipedia
Re: Announce: TMK firmware for ErgoDox
« Reply #23 on: Fri, 13 September 2013, 12:15:03 »
So how would I adapt my layout generated from MassDrop to this firmware?

Offline CommunistWitchDr

  • Posts: 479
  • Location: St. Louis, MO
  • >implying keyboards
Re: Announce: TMK firmware for ErgoDox
« Reply #24 on: Fri, 13 September 2013, 15:36:35 »
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.

Offline TD22057

  • Posts: 172
  • Location: Southern California
Re: Announce: TMK firmware for ErgoDox
« Reply #25 on: Fri, 13 September 2013, 16:03:57 »
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.

Offline fisofo

  • Posts: 65
Re: Announce: TMK firmware for ErgoDox
« Reply #26 on: Sat, 14 September 2013, 18:07:30 »
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?

Offline cub-uanic

  • Thread Starter
  • Posts: 72
  • Location: Ukraine, Kharkov
Re: Announce: TMK firmware for ErgoDox
« Reply #27 on: Sat, 14 September 2013, 19:28:43 »
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.

ErgoDox Classic - Stock Clears
Teenesis - Kinesis Advantage powered by Teensy

Offline cub-uanic

  • Thread Starter
  • Posts: 72
  • Location: Ukraine, Kharkov
Re: Announce: TMK firmware for ErgoDox
« Reply #28 on: Sat, 14 September 2013, 20:11:03 »
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.

ErgoDox Classic - Stock Clears
Teenesis - Kinesis Advantage powered by Teensy

Offline fisofo

  • Posts: 65
Re: Announce: TMK firmware for ErgoDox
« Reply #29 on: Sat, 14 September 2013, 20:27:39 »
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 ;)

Offline cub-uanic

  • Thread Starter
  • Posts: 72
  • Location: Ukraine, Kharkov
Re: Announce: TMK firmware for ErgoDox
« Reply #30 on: Sat, 14 September 2013, 21:34:53 »
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.

ErgoDox Classic - Stock Clears
Teenesis - Kinesis Advantage powered by Teensy

Offline fisofo

  • Posts: 65
Re: Announce: TMK firmware for ErgoDox
« Reply #31 on: Sat, 14 September 2013, 23:34:43 »
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!

Offline cub-uanic

  • Thread Starter
  • Posts: 72
  • Location: Ukraine, Kharkov
Re: Announce: TMK firmware for ErgoDox
« Reply #32 on: Sun, 15 September 2013, 06:55:02 »
@fisofo
We got excellent answer on GitHub, please read it carefully.

ErgoDox Classic - Stock Clears
Teenesis - Kinesis Advantage powered by Teensy

Offline fisofo

  • Posts: 65
Re: Announce: TMK firmware for ErgoDox
« Reply #33 on: Sun, 15 September 2013, 17:27:30 »
Yeah, that's a great explanation, thanks for the heads up!

Offline fisofo

  • Posts: 65
Re: Announce: TMK firmware for ErgoDox
« Reply #34 on: Sun, 15 September 2013, 22:06:24 »
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

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

@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). Any idea how to do that in TMK? I monkeyed around a bit, but couldn't nail it down.

Offline fisofo

  • Posts: 65
Re: Announce: TMK firmware for ErgoDox
« Reply #35 on: Sun, 15 September 2013, 22:11:48 »
@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.

Offline cub-uanic

  • Thread Starter
  • Posts: 72
  • Location: Ukraine, Kharkov
Re: Announce: TMK firmware for ErgoDox
« Reply #36 on: Mon, 16 September 2013, 06:25:54 »
@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). 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

ErgoDox Classic - Stock Clears
Teenesis - Kinesis Advantage powered by Teensy

Offline hasu

  • Posts: 3116
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: Announce: TMK firmware for ErgoDox
« Reply #37 on: Mon, 16 September 2013, 09:04:14 »
@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). 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!


Quote
@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.
TMK products:HHKB Alt  ⌨ConvertersAlps64FC660C AltFC980C Alt

Offline ic07

  • Posts: 190
Re: Announce: TMK firmware for ErgoDox
« Reply #38 on: Mon, 16 September 2013, 11:34:57 »
Is there any way to force your function to be placed at a lower address in PROGMEM, regardless of the total firmware size?

Offline cub-uanic

  • Thread Starter
  • Posts: 72
  • Location: Ukraine, Kharkov
Re: Announce: TMK firmware for ErgoDox
« Reply #39 on: Mon, 16 September 2013, 11:40:44 »
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?...

ErgoDox Classic - Stock Clears
Teenesis - Kinesis Advantage powered by Teensy

Offline ic07

  • Posts: 190
Re: Announce: TMK firmware for ErgoDox
« Reply #40 on: Mon, 16 September 2013, 12:06:32 »
The avr-libc documentation is pretty good (especially see the user manual reference sections), as is the ATMega32U4 datasheet.  Dean Camera's written some nice tutorials that I've found useful from time to time.  And if you're ever board, my references page lists almost every useful link I've looked at during this project, lol.

Specifically, to learn about PROGMEM, I'd start with this (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).

Offline ic07

  • Posts: 190
Re: Announce: TMK firmware for ErgoDox
« Reply #41 on: Mon, 16 September 2013, 12:20:31 »
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.

Offline hasu

  • Posts: 3116
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: Announce: TMK firmware for ErgoDox
« Reply #42 on: Mon, 16 September 2013, 19:08:31 »
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
Code: [Select]
const uint8_t keymaps[][MATRIX_ROWS][MATRIX_COLS] __attribute__ ((section (".keymap.keymaps"))) = {

then lastly gave this option to gcc(ld).
Code: [Select]
-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?
TMK products:HHKB Alt  ⌨ConvertersAlps64FC660C AltFC980C Alt

Offline ic07

  • Posts: 190
Re: Announce: TMK firmware for ErgoDox
« Reply #43 on: Mon, 16 September 2013, 21:35:41 »
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...

Offline hasu

  • Posts: 3116
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: Announce: TMK firmware for ErgoDox
« Reply #44 on: Wed, 18 September 2013, 02:50:42 »
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. :)
TMK products:HHKB Alt  ⌨ConvertersAlps64FC660C AltFC980C Alt

Offline fisofo

  • Posts: 65
Re: Announce: TMK firmware for ErgoDox
« Reply #45 on: Wed, 18 September 2013, 20:38:57 »
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?

Offline hasu

  • Posts: 3116
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: Announce: TMK firmware for ErgoDox
« Reply #46 on: Wed, 18 September 2013, 20:57:24 »
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
TMK products:HHKB Alt  ⌨ConvertersAlps64FC660C AltFC980C Alt

Offline fisofo

  • Posts: 65
Re: Announce: TMK firmware for ErgoDox
« Reply #47 on: Wed, 18 September 2013, 23:21:53 »
Good to know, thanks hasu!

Offline fisofo

  • Posts: 65
Re: Announce: TMK firmware for ErgoDox
« Reply #48 on: Sun, 22 September 2013, 21:17:24 »
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!

Offline bobkare

  • Posts: 5
  • Location: Norway
Re: Announce: TMK firmware for ErgoDox
« Reply #49 on: Mon, 23 September 2013, 12:08:59 »
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.