TMK keyboard firmware

[naasfu]

I spent some time wondering why some of my layers would not take effect while I had another layer activated.  Then I found this issue item that explained my incorrect assumption about TMK layers.  I thought layers would pile up as a stack as you activated them, but there is only the fixed ordering of layers that we defined in the first place.  I moved the layers that I wanted to activate to the end of the layer definitions array, and that fixed it.

hasu, could you please a note to the documentation that specifically says that the layers do not stack based on the order in which you activate them?  You do have the explanation of the stack and how layers are turned on/off, but I guess people (like me, oops) may assume that layers might get stacked according to their activation order, so maybe specifically call out that is not the case.

Anyways, very cool stuff.

[Koren]

I fiddled around with things and I think I am getting close. You can see my current keymap, which does not work fully, at https://gist.github.com/Eric-L-T/9c3f8093eacca1b905cb. I intended the last function to reset empty_scans to zero whenever any key is pressed, but it seems that I am misunderstanding record->event.pressed. Can someone help?

I think you may understand how record->event.pressed but be wrong about the function itself...

It's called only if you press a FN* key (not the function keys on a keyboard, the TMK action keys in the TMK keymap)

But yes, it's doable using only the keymap file, although probably a bit uglier:

1) create a variable
matrix_row_t matrix_previous[MATRIX_ROWS]

2) at the start of the matrix user function :
for each i in 0..MATRIX_ROWS-1
- check whether matrix_previous != matrix
- if so, reset your counter to 0, and copy matrix to matrix_previous

(if you want the counter to only reset on keypresses and not releases, you can replace != by < for the reset, but still copy if !=)

[e_l_tang]

Sorry, I'm not understanding what you want me to put in matrix_scan_user. Also, I don't need action_function anymore, correct?

I also updated my code to rely on the timer, which will give more predictable results than the matrix will. Does that change anything?

Edit: This may be a dumb question, but I'm curious to know its answer. Will my timer variable overflow? If so, what will happen?

[Koren]

Sorry, I'm not understanding what you want me to put in matrix_scan_user.

Something like this:

Code: [Select]

for(int i=0; i<MATRIX_ROWS; ++i) {
    if (matrix[i] != prev_matrix[i]) {
        prev_matrix[i] = matrix[i]
        empty_scans = 0;
    }Or the equivalent timer reset.

Also, I don't need action_function anymore, correct?

Not for this, at least.

I also updated my code to rely on the timer, which will give more predictable results than the matrix will. Does that change anything?

Probably not (although I don't really see why it would be more predictable... easier threshold value? During inactivity, the scan rate is probably really stable, and you won't probably mind a couple milliseconds in such a timer), but I'm not sure exactly how the timers work in this case. Any link?

Edit: This may be a dumb question, but I'm curious to know its answer. Will my timer variable overflow? If so, what will happen?

It's never a dumb question to think about overflows.

If you use uint32, you'll probably need something like a year without a keypress to overflow, so you're safe. With 16 bits, it's far more tricky. An additional reason to look how timers work.

If you managed the counter yourself, you can stop incrementing if you're over the threshold.

But in the worst case, you'll trigger the "return to layer 1" each time you do a complete cycle. Depending on how you program this return, it shouldn't be a problem.

[e_l_tang]

I integrated your code. However, the resulting keymap, which I have put in my gist, does not compile. Here is what I get:

Code: [Select]

-------- begin --------
avr-gcc (GCC) 4.9.3
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Size before:
   text    data     bss     dec     hex filename
  19410      82     159   19651    4cc3 planck.elf


mkdir -p obj_planck/keymaps
Compiling C: keymaps/eric_mac.c
avr-gcc -c -mmcu=atmega32u4 -gdwarf-2 -DF_CPU=16000000UL -DINTERRUPT_CONTROL_ENDPOINT -DBOOTLOADER_SIZE=4096 -DF_USB=16000000UL -DARCH=ARCH_AVR8 -DUSB_DEVICE_ONLY -DUSE_FLASH_DESCRIPTORS -DUSE_STATIC_OPTIONS="(USB_DEVICE_OPT_FULLSPEED | USB_OPT_REG_ENABLED | USB_OPT_AUTO_PLL)" -DFIXED_CONTROL_ENDPOINT_SIZE=8  -DFIXED_NUM_CONFIGURATIONS=1 -DPROTOCOL_LUFA -DBOOTMAGIC_ENABLE -DMOUSEKEY_ENABLE -DMOUSE_ENABLE -DEXTRAKEY_ENABLE -DCONSOLE_ENABLE -DCOMMAND_ENABLE -DBACKLIGHT_ENABLE -DVERSION=af6163f -Os -funsigned-char -funsigned-bitfields -ffunction-sections -fdata-sections -fno-inline-small-functions -fpack-struct -fshort-enums -fno-strict-aliasing -Wall -Wstrict-prototypes -Wa,-adhlns=obj_planck/keymaps/eric_mac.lst -I. -I../.. -I../../tmk_core -I../../quantum -I../../tmk_core/protocol/lufa -I../../tmk_core/protocol/lufa/LUFA-git -I../../tmk_core/common -std=gnu99 -include config.h -MMD -MP -MF .dep/obj_planck_keymaps_eric_mac.o.d  keymaps/eric_mac.c -o obj_planck/keymaps/eric_mac.o
keymaps/eric_mac.c: In function 'matrix_scan_user':
keymaps/eric_mac.c:181:7: error: 'matrix' undeclared (first use in this function)
   if (matrix[i] != prev_matrix[i]) {
       ^
keymaps/eric_mac.c:181:7: note: each undeclared identifier is reported only once for each function it appears in
keymaps/eric_mac.c:181:20: error: 'prev_matrix' undeclared (first use in this function)
   if (matrix[i] != prev_matrix[i]) {
                    ^
make: *** [obj_planck/keymaps/eric_mac.o] Error 1

[hasu]

I spent some time wondering why some of my layers would not take effect while I had another layer activated.  Then I found this issue item that explained my incorrect assumption about TMK layers.  I thought layers would pile up as a stack as you activated them, but there is only the fixed ordering of layers that we defined in the first place.  I moved the layers that I wanted to activate to the end of the layer definitions array, and that fixed it.

hasu, could you please a note to the documentation that specifically says that the layers do not stack based on the order in which you activate them?  You do have the explanation of the stack and how layers are turned on/off, but I guess people (like me, oops) may assume that layers might get stacked according to their activation order, so maybe specifically call out that is not the case.

Anyways, very cool stuff.

Filed under "TODO" tag.
https://github.com/tmk/tmk_keyboard/issues/310

Oh my, already too many TODOs!
https://github.com/tmk/tmk_keyboard/labels/TODO

[hasu]

BTW, recent big thing is flabbergast's Chibios backend merger.
Now we can use Cortex-M with the 'chibios' in addition to existent 'mbed' stack. Chibios support many kind of STM32 and Kinetis.
https://github.com/tmk/tmk_keyboard/blob/master/README.md#20160210

Thank you, flabbergast!

[e_l_tang]

I figured out some of the problems and was able to compile my keymap. However, my keyboard still resets regardless of whether I am actively using it. I have no idea how to fix this. Anyone who wants to help can see my keymap at https://gist.github.com/Eric-L-T/9c3f8093eacca1b905cb.

[naasfu]

I spent some time wondering why some of my layers would not take effect while I had another layer activated.  Then I found this issue item that explained my incorrect assumption about TMK layers.  I thought layers would pile up as a stack as you activated them, but there is only the fixed ordering of layers that we defined in the first place.  I moved the layers that I wanted to activate to the end of the layer definitions array, and that fixed it.

hasu, could you please a note to the documentation that specifically says that the layers do not stack based on the order in which you activate them?  You do have the explanation of the stack and how layers are turned on/off, but I guess people (like me, oops) may assume that layers might get stacked according to their activation order, so maybe specifically call out that is not the case.

Anyways, very cool stuff.

Filed under "TODO" tag.
https://github.com/tmk/tmk_keyboard/issues/310

Oh my, already too many TODOs!
https://github.com/tmk/tmk_keyboard/labels/TODO

thanks, hasu.

and haha, TODOs always love to pile up.

[e_l_tang]

hasu, you might want to take a look at the documentation of QMK Firmware and see if any of it is of any use to you. Although it is lacking in some repects, most of what's there is high-quality. Also, do you have any idea what might be wrong with my keymap?

[Koren]

I integrated your code. However, the resulting keymap, which I have put in my gist, does not compile.

Sorry about that...

You probably need a

Code: [Select]

#include "matrix.h"in the preamble of the file and a

Code: [Select]

matrix_row_t prev_matrix[MATRIX_ROWS]somewhere in the file, too.

It seems that you figured the second part, but after a quick look at the code, I'm not sure the first part is correct. Please add the include and replace "matrix_state" by "matrix" and try again...

However, my keyboard still resets regardless of whether I am actively using it. I have no idea how to fix this.

What do you mean by "reset"? Return to layer 1 even if you're typing?

It may be because of the problem above (the include). If not, I'd be curious to know more about the timer functions, I'd like to know how they work to help you, but I can't find anything?

[e_l_tang]

Now I get this error message:

Code: [Select]

-------- begin --------
avr-gcc (GCC) 4.9.3
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Size before:
   text    data     bss     dec     hex filename
  19390      82     167   19639    4cb7 planck.elf


mkdir -p obj_planck/keymaps
Compiling C: keymaps/eric_mac.c
avr-gcc -c -mmcu=atmega32u4 -gdwarf-2 -DF_CPU=16000000UL -DINTERRUPT_CONTROL_ENDPOINT -DBOOTLOADER_SIZE=4096 -DF_USB=16000000UL -DARCH=ARCH_AVR8 -DUSB_DEVICE_ONLY -DUSE_FLASH_DESCRIPTORS -DUSE_STATIC_OPTIONS="(USB_DEVICE_OPT_FULLSPEED | USB_OPT_REG_ENABLED | USB_OPT_AUTO_PLL)" -DFIXED_CONTROL_ENDPOINT_SIZE=8  -DFIXED_NUM_CONFIGURATIONS=1 -DPROTOCOL_LUFA -DBOOTMAGIC_ENABLE -DMOUSEKEY_ENABLE -DMOUSE_ENABLE -DEXTRAKEY_ENABLE -DCONSOLE_ENABLE -DCOMMAND_ENABLE -DBACKLIGHT_ENABLE -DVERSION=af6163f -Os -funsigned-char -funsigned-bitfields -ffunction-sections -fdata-sections -fno-inline-small-functions -fpack-struct -fshort-enums -fno-strict-aliasing -Wall -Wstrict-prototypes -Wa,-adhlns=obj_planck/keymaps/eric_mac.lst -I. -I../.. -I../../tmk_core -I../../quantum -I../../tmk_core/protocol/lufa -I../../tmk_core/protocol/lufa/LUFA-git -I../../tmk_core/common -std=gnu99 -include config.h -MMD -MP -MF .dep/obj_planck_keymaps_eric_mac.o.d  keymaps/eric_mac.c -o obj_planck/keymaps/eric_mac.o
keymaps/eric_mac.c: In function 'matrix_scan_user':
keymaps/eric_mac.c:176:7: error: 'matrix' undeclared (first use in this function)
   if (matrix[i] != prev_matrix[i]) {
       ^
keymaps/eric_mac.c:176:7: note: each undeclared identifier is reported only once for each function it appears in
make: *** [obj_planck/keymaps/eric_mac.o] Error 1

Yes, that's what I mean. I don't think there is much documentation on the timer feature; I'm not too sure how it works either. Anyway, its code can be found in the files named "timer.*."

[hasu]

you have to listen to compiler error messages word by word at first. in most cases GCC is correct and exact in general, believe it from the bottom of your heart if you can't understand it then Google is your friend.

your problem is that you don't declare matrix in this 'compilarion unit' or keymaps/eric_mac.c. In C compiler see just one file at a time basically so matrix[] defined in other file is not visible to GCC. To solve this you can use '#include' directive which makes specified file to be visible from current compilation unit.

this explanation is based on my iffy C knowledge you better learn how #include works from good C books or resources on line.

I hope this helps.

keymaps/eric_mac.c: In function 'matrix_scan_user':
keymaps/eric_mac.c:176:7: error: 'matrix' undeclared (first use in this function)
   if (matrix != prev_matrix) {
       ^

[redbanshee]

Hasu, I have a question for you... what exactly is so different about Quantum (QMK) compared to your repo? Sorry if this has already been covered (its a long thread!) just wondering what the main difference is?

[e_l_tang]

I already had "include "matrix.h"" at the top of my file when I got that error message.

[e_l_tang]

QMK is a fork of TMK maintained by Jack Humbert of Ortholinear Keyboards. It just contains some added features.

[redbanshee]

QMK is a fork of TMK maintained by Jack Humbert of Ortholinear Keyboards. It just contains some added features.

Thanks eric, I am aware that its a fork of tmk, I was just wondering how it differs exactly. "It just contains some added features." just wondering what those features are...

[e_l_tang]

A few things that I can think of right now are shortcuts for defining keymaps, built-in support for WS2812 RGB LED strips, and a few extra functions that can be used in keymap files.

[Darkshado]

Pro tip: Github now lets you compare across forks directly from their website.

Or: add the other repo as a remote and use git difftool + your favorite compare tool. I've used Meld in Linux and WinMerge in Windows, both FOSS; as well as Beyond Compare, $. There's command line options for the difftool command to compare between different remotes as well as compare a directory instead of a file.

[regack]

A few things that I can think of right now are shortcuts for defining keymaps, built-in support for WS2812 RGB LED strips, and a few extra functions that can be used in keymap files.

It's easier for someone less familiar with coding to change between column driven or row driven polling, and easier to set up your row/column pins.  It is probably not very important to most people, but QMK doesn't support the ATMEGA32U2, but TMK does.

[Koren]

I already had "include "matrix.h"" at the top of my file when I got that error message.

Yes, but I was actually wrong with that. It's actually not enough. I'm discussing this from memory, and I had not spent enough time checking everything was correct.

Hasu is right, the answer is in the error message: he can't find the table called "matrix"

That's because the declaration of the "matrix" table is *not* in matrix.h (I think I have included it to get access to the matrix_row_t definition).

It's defined somewhere in a .c file written for your board. You can find the correct file using grep (or any full-text research function). It's usually in a file called "matrix.c" in a directory called like your board/keyboard.

Unfortunately, it's defined as

Code: [Select]

static matrix_row_t matrix[MATRIX_ROWS];
You'll have to remove the static keyword in this file...

I know you wanted to modify only the keymap file, but I must say I run out of ideas :/ Just removing the "static" keyword shouldn't be a huge modification, though.

After that, you have to add a

Code: [Select]

extern matrix_row_t matrix[MATRIX_ROWS];in your keymap file.

And that should compile (and hopefully work).

[Koren]

It is probably not very important to most people, but QMK doesn't support the ATMEGA32U2, but TMK does.

I'd be curious to know why the support has been dropped? Is it because the fork is older than Atmega32U2 support in TMK and they never bothered to merge the branches? Or is there some incompatibility?

[e_l_tang]

Now I'm getting a lot of error messages saying that I have multiple definitions for a ton of things. Thanks for trying, though.

hasu, do you know of any simpler way to detect when any key is pressed?

[njbair]

BTW, recent big thing is flabbergast's Chibios backend merger.
Now we can use Cortex-M with the 'chibios' in addition to existent 'mbed' stack. Chibios support many kind of STM32 and Kinetis.
https://github.com/tmk/tmk_keyboard/blob/master/README.md#20160210

Thank you, flabbergast!

This sounds cool. Will this new stack affect the Infinity?

I am primarily curious about media keys support and boot magic for the Infinity.

[flabbergast]

This sounds cool. Will this new stack affect the Infinity?

I am primarily curious about media keys support and boot magic for the Infinity.

You'll have the option to either use mbed backend as before, or the chibios one. The chibios one should support both of these (if it does not, please report!).

[Koren]

Now I'm getting a lot of error messages saying that I have multiple definitions for a ton of things. Thanks for trying, though.

A ton? That's strange... I know it works, I use it myself. It's just that it's difficult to debug via a forum.

I think it would be quicker if I was trying to compile it myself. What board from QMK firmware do you use?

[e_l_tang]

I'm using a Planck. By the way, are you familiar with strong modifiers and weak modifiers? If so, could you briefly explain them to me? I can't seem to find any documentation on them.

[regack]

It is probably not very important to most people, but QMK doesn't support the ATMEGA32U2, but TMK does.

I'd be curious to know why the support has been dropped? Is it because the fork is older than Atmega32U2 support in TMK and they never bothered to merge the branches? Or is there some incompatibility?

I think I shouldn't have said 'doesn't support' so much as 'support has been skipped'.  It's not that you can't make it work (I have) but QMK assumes that you have all of the registers (B, C, D, E, F) without taking into account that the ATmega32u2 only has B, C & D.  QMK also assumes access to Timer3 and other output compare registers, which aren't there on the U2.  I intend to make my branch more generic to support the U4 and U2, but I haven't gotten to it yet.

[njbair]

This sounds cool. Will this new stack affect the Infinity?

I am primarily curious about media keys support and boot magic for the Infinity.

You'll have the option to either use mbed backend as before, or the chibios one. The chibios one should support both of these (if it does not, please report!).

This is great news!

hasu, any word on when we can expect these updates to show up in the core branch?

[e_l_tang]

It would seem from the documentation at https://github.com/tmk/tmk_keyboard#20160210 that ChibiOS is already part of TMK.

[njbair]

It would seem from the documentation at https://github.com/tmk/tmk_keyboard#20160210 that Chibios is already part of TMK.

Yep, I was asking about the core branch.

[hasu]

It would seem from the documentation at https://github.com/tmk/tmk_keyboard#20160210 that Chibios is already part of TMK.

Yep, I was asking about the core branch.

I didn't update core branch any more, instead I'll maintain tmk_core repository for same purpose. The repository integreated chibios. You will be able to git-subtree or submodule it to start your own project.
https://github.com/tmk/tmk_core

core branch didn't seem to be useful or tmk_core repository makes more sense to me. Probably I'll remove core branch some later.

[e_l_tang]

hasu, I am tailoring TMK/QMK to my needs and I am wondering if the behaviors I am implementing would be of any use to others.

Would you consider adding any of the following to TMK?

• a timeout which will reset the keyboard to its default state after a certain period of inactivity
• an initialization sequence which will turn off Caps Lock, Scroll Lock, and Num Lock when plugging the keyboard in
• a solution to the issue described at https://github.com/jackhumbert/qmk_firmware/issues/156
• momentary switching to lower layers
• the ability to detect whether the host system is a Mac
• a redesign of weak_mods and real_mods

[njbair]

It would seem from the documentation at https://github.com/tmk/tmk_keyboard#20160210 that Chibios is already part of TMK.

Yep, I was asking about the core branch.

I didn't update core branch any more, instead I'll maintain tmk_core repository for same purpose. The repository integreated chibios. You will be able to git-subtree or submodule it to start your own project.
https://github.com/tmk/tmk_core

core branch didn't seem to be useful or tmk_core repository makes more sense to me. Probably I'll remove core branch some later.

OK thanks. I'll just switch my personal repo to pull in the master branch, then adjust the TMK_DIR in the Makefiles accordingly. Thanks for clearing that up.

So I'm trying to compile this infinity_chibios firmware. I downloaded ChibiOS from Sourceforge, and symlinked it to tmk_core/tools/chibios/chibios, but I still get the following error when I try to compile the Infinity firmware:

Code: [Select]

../../module/tmk/tmk_core/tool/chibios/chibios.mk:88: ../../module/tmk/tmk_core/tool/chibios/chibios/os/common/ports/ARMCMx/compilers/GCC/mk/startup_k20x5.mk: No such file or directory
make: *** No rule to make target '../../module/tmk/tmk_core/tool/chibios/chibios/os/common/ports/ARMCMx/compilers/GCC/mk/startup_k20x5.mk'.  Stop.
When I list the contents of the directory in question, I do not see startup_k20x5.mk, but I do see these:

Code: [Select]

startup_k20x.mk
startup_kl2x.mk
startup_stm32f0xx.mk
startup_stm32f1xx.mk
startup_stm32f3xx.mk
startup_stm32f4xx.mk
startup_stm32l0xx.mk
startup_stm32l1xx.mk
What am I missing?

[flabbergast]

@njbair: The thing is that at the moment you'll need to get my branch of chibios, which has a more up-to-date kinetis support.

{Merging this to something more official in chibios is in the works, but it may take a bit. Meanwhile I'm more-less keeping up with the chibios mainline.}

[njbair]

@njbair: The thing is that at the moment you'll need to get my branch of chibios, which has a more up-to-date kinetis support.

{Merging this to something more official in chibios is in the works, but it may take a bit. Meanwhile I'm more-less keeping up with the chibios mainline.}

That's good to know. However, the readme links to the official ChibiOS site. Did I miss something in the Readme about using your branch?

[flabbergast]

@njbair: The thing is that at the moment you'll need to get my branch of chibios, which has a more up-to-date kinetis support.

{Merging this to something more official in chibios is in the works, but it may take a bit. Meanwhile I'm more-less keeping up with the chibios mainline.}

That's good to know. However, the readme links to the official ChibiOS site. Did I miss something in the Readme about using your branch?

It does, but now I realise it may not be quite clear, sorry (the MCUs in Teensy 3.x and Infinity and Whitefox are all Freescale Kinetis line).

To use, unpack or symlink ChibiOS {currently 3.0.2} to tmk_core/tool/chibios/chibios. For Kinetis support, you'll need a fork which implements the USB driver, e.g. this one.

[e_l_tang]

Everyone, a redditor solved my problem. Thanks for trying, though. See my gist for my new keymap.

[njbair]

@njbair: The thing is that at the moment you'll need to get my branch of chibios, which has a more up-to-date kinetis support.

{Merging this to something more official in chibios is in the works, but it may take a bit. Meanwhile I'm more-less keeping up with the chibios mainline.}

That's good to know. However, the readme links to the official ChibiOS site. Did I miss something in the Readme about using your branch?

It does, but now I realise it may not be quite clear, sorry (the MCUs in Teensy 3.x and Infinity and Whitefox are all Freescale Kinetis line).

To use, unpack or symlink ChibiOS {currently 3.0.2} to tmk_core/tool/chibios/chibios. For Kinetis support, you'll need a fork which implements the USB driver, e.g. this one.

Just following up. I got this working this morning. I cloned your ChibiOS repo this morning and copied over my existing Infinity keymap into the ChibiOS folder. I had to comment out the INFINITY_PROTOTYPE flag in the Makefile, but other than that it worked perfectly out of the box.

I'm super psyched to finally have media keys support on my Infinity boards! I'll have to test out boot magic sometime soon and make sure that's working. Flabbergast, you've given the Infinity a new lease on life! Thanks to you and hasu for all your hard work. Hopefully I can find a way to contribute, despite my unfamiliarity with embedded programming.

[battletux]

Does anyone know how I can get the back lights for Fn, wasd and escape working for the GH60? I've soldered in the resistors to the required points on the PCB and added in the LEDs for the relevant switches, however I can not figure out how to get anything but the caps lock light to work.


Thanks.

[hasu]

you will need to check schematic of PCB to know how to control and write code.

my GH 60 firmware doesn't support any LEDs except for caps lock, if you didn't know.

[axtran]

Does anyone know how I can get the back lights for Fn, wasd and escape working for the GH60? I've soldered in the resistors to the required points on the PCB and added in the LEDs for the relevant switches, however I can not figure out how to get anything but the caps lock light to work.


Thanks.

I think you're mistaking the GH60 TMK config with what sounds like your board, being a Satan GH60. Unfortunately, the Satan GH60 has nothing to do with the original GH60 other than improperly stealing it's name.

You'll have better luck finding QMK guides of people who've already done backlight configuration, than making your own TMK config.

[a-c]

He may have a Rev B board. As described here: http://blog.komar.be/gh60-evolution/

[axtran]

True, I'm making an assumption... I do know the gh60 config in TMK has nothing but lock indicators, and hasu is also working on more advanced LED API changes.

[njbair]

I'm trying to figure out how to use the Child Lock magic command. The readme file says it's lshift+rshift+caps, but that doesn't work for me. I have not changed the default magic key combination, and lshift+rshift does work for most other magic commands, but Child Lock never works. Am I missing something?

[flabbergast]

@njbair: Did you #define KEYBOARD_LOCK_ENABLE somewhere (e.g. in the Makefile)?

[flog]

Using cubanics tmk firmware on my ergodox. Works great but Im having issues when connecting it to a kvm switch at work. The firmware doesnt seem to boot(leds do not flash when connected) I dont know how much difference there are between cubanics and the original tmk. The kvm has both usb and ps/2 on it. Tried connecting the ergodox to usb and ps/2 via a usb-to-ps/2 adapter. Any ideas how to get it to work?

[njbair]

@njbair: Did you #define KEYBOARD_LOCK_ENABLE somewhere (e.g. in the Makefile)?

That was it. I didn't have that option in my Makefile. It's there now, recompiled and locking like a charm. Thanks!

Now I just wish there was a way to default to locked on boot. I could always make a layer full of NO's, and set the boot magic default layer to that, but it would be nice if it was an option to use the built-in lock functionality. Either way, this should do well enough to keep my 4-year-old from doing any damage when I step away.

[shaymdev]

Haven't done any C coding since college... moving from C# back to C has proven... interesting.

Still trying to figure out how to gethe the bluefruit micro working in Bluetooth mode. It would really open the door to a whole host of bluetooth keyboards.

TMK seems to function perfectly in USB mode on this controller.

I also purchased one of these:  http://www.adafruit.com/product/2829

Basically the same thing as the bluefruit micro but the battery port is built in.

profet or anyone else: Any news on getting tmk working with the bluefruit feather 32u4?

I'm very interested in building a new version of my custom build using bluetooth low energy and that controller looks like the best option right now. I'd love it if I can use my existing tmk fork because of all the awesome stuff hasu has baked in that I don't want to live without (and I know I probably don't even use the half of what it's capable of)

Once I can verify the firmware works with it I'm very interested to see how battery life is since I tend to want to force myself to work in a pretty tight space I'd probably want to find the smallest battery that I can get away with. Will tmk's sleep functionality come in handy here?

I also saw today the adafruit bluefruit feather m0 which I'm wondering if the new chibios stuff from flabbergast means that controller would work just as well as the 32u4 version?

[flabbergast]

I think TMK supports bluefruit (the one with atmega32u4); at least there is some code in TMK towards that (I don't have one so I can't test).
For the new bluefruit M0 - that one has an ATSAMD chip, and these are not supported by chibios (yet).

The thing about ARM MCUs is that there are several major manufacturers (Freescale+NXP, ST, ATMEL), and the code is *not* compatible between them (sure, the basic core is the same, but all the other hardware features (e.g. GPIO) are implemented differently). Chibios has support for STM32s and Kinetises, but not much yet for LPC and ATSAM.