TMK keyboard firmware

[profet]

Post a link to the product you are using and its circuit in particular. This will help you to get more advice from people here.

This is the product page: https://www.adafruit.com/products/2661

[a-c]

Sounds like one of these. http://www.adafruit.com/products/2661

Probably need to set the CPU frequency to 8Mhz in your makefile.

[profet]

Sounds like one of these. http://www.adafruit.com/products/2661

Probably need to set the CPU frequency to 8Mhz in your makefile.

hrm... just tried setting: 

F_CPU = 8000000

but same problem.

[profet]

hrm... tried LUFA instead of pjrc with changed clock speed... that seems promising... will report back after dinner


thanks for the heads up.

[hasu]

Hmm, TMK's PJRC protocol module does not support 8MHz and it expects 16MHz.

Changed PLLCSR setting like the below and it seems to work now. But I don't think you have a reason to stick to PJRC instead of LUFA.

Code: [Select]

diff --git a/tmk_core/protocol/pjrc/usb.h b/tmk_core/protocol/pjrc/usb.h
index a195b67..881a1ef 100644
--- a/tmk_core/protocol/pjrc/usb.h
+++ b/tmk_core/protocol/pjrc/usb.h
@@ -71,7 +71,7 @@ void usb_remote_wakeup(void);
 #define USB_FREEZE() (USBCON = ((1<<USBE)|(1<<FRZCLK)))
 #elif defined(__AVR_ATmega32U4__)
 #define HW_CONFIG() (UHWCON = 0x01)
-#define PLL_CONFIG() (PLLCSR = 0x12)
+#define PLL_CONFIG() (PLLCSR = 0x02)
 #define USB_CONFIG() (USBCON = ((1<<USBE)|(1<<OTGPADE)))
 #define USB_FREEZE() (USBCON = ((1<<USBE)|(1<<FRZCLK)))
 #elif defined(__AVR_AT90USB646__)


[mrbishop]

so ive built a keyboard using the GH60 TMK firmware. all the default settings everything works except for 2 keys on row 3 seem to be shifted. not sure whats going on any help would be great.
the Z key is offset and the B key is as well. all the other keys in that row/column work.

here is the keymap

     * ,-----------------------------------------------------------.
     * |`| 1| 2| 3| 4| 5| 6=| 7| 8| 9|0|-|6=|BKSP|
     * |-----------------------------------------------------------|
     * |TAB|q| w|e|r|t|y]|u|i|o|p|[]|[]|y]\|
     * |-----------------------------------------------------------|
     * |caps|a|s|d|f|g|h|j|k|l|;|'|enter|
     * |-----------------------------------------------------------|
     * |shift|  |z|x|c|   |b|n|m|,|.|shift|
     * |-----------------------------------------------------------|
     * |ctrl|super|alt|         space            |alt|super|menu|???|
     * `-----------------------------------------------------------'
original thread with pictures and gh60 compile folder
https://geekhack.org/index.php?topic=77450.0

[hasu]

I think your 'z' key is offset physically comparing to GH60.
GH60 has 'z' on col2 of row3(let's say index starts from 0) but your 'z' on col1. Note that GH60 has ISO\ on that place(row3, col1).

Fix your hardware if you want to make your board compatible to GH60. Or change keymap code in keymap_common.h.

[nephiel]

Hasu is right - the GH60 board has an extra ISO key on the matrix between the left Shift and Z, and your wiring is missing that key. Rewiring that row from Z to B, but skipping that key, should fix the problem.

[mrbishop]

@hasu i guess i dont understand as the keymap_common.h has an ansi section. which is what i used to wire my board. i guess i dont fully understand how all the firmware files interact or are configured to make it work. i'd love alittle more direction. here or in PM. sorry for being a noob i appreciate all the help i can get!  thanks again.

[mrbishop]

[mrbishop]

wel i got Z working in theproper placeby removing one of the key definitions in common.h (K31) but i can't seem to get the same result with the B key. -_-

[suicidal_orange]

@hasu i guess i dont understand as the keymap_common.h has an ansi section. which is what i used to wire my board. i guess i dont fully understand how all the firmware files interact or are configured to make it work. i'd love alittle more direction. here or in PM. sorry for being a noob i appreciate all the help i can get!  thanks again.

Your Z is on column 1 (yellow = 0 red = 1) but your keymap has a gap putting it in column 2.  I know next to nothing about TMK but your Z row in the keymap is wired up like this

|shift|z|x|c|v|b|n|m|,|.|/| |shift|

not this

shift| |z|x|c|   |b|n|m|,|.|shift|

Maybe there's a good reason you have no "v" or "/" in your map (and other strangeness) but give it a try?

[mrbishop]

@suicidal_orange. the map i posted wasto demonstratethe issue i am having. i like the Z and V key    what i'm trying to accomplish is an ANSI 60% Poker layers usingthe GH60 wireing. which has worked with the exception of the Z,V,6,Y,=



so i boned something up somewhere but i'm lost as to where

[mrbishop]

looks like the close square bracket does this as well "y]" sigh so close yet so far.

[suicidal_orange]

Ok... I guess common.h is keymap_common.h in the GH60 folder?  If so I think you need to change the ANSI sections to

    K30, K31, K32, K33, K34, K35, K36, K37, K38, K39, K3A,delete K3B           K3D, \
and
    K30, K31, K32, K33, K34, K35, K36, K37, K38, K39, K3A, NO, NO,  K3D, \


I'm not sure why you're trying to pretend this is a GH60, why not build it from scratch so you know how it works?

[mrbishop]

Well it's my first attempt so I thought it best to emulate something first for better understanding and to try to figure out how to fix issues like this with my code.

[profet]

Well thanks to everyone here I was able to get the Bluefruit micro working with TMK over USB...

Now the hard part... Bluetooth.

Could someone attempt to explain to me the architecture of the "protocol" modules? I see there is already a bluefruit protocol module but I'm thinking that if I want to use hardware SPI then I may need to start from scratch.

So protocols... can multiple be active at once?

Is there an event I can hook into somewhere/somehow that will allow me to capture keys and process them over SPI to the bluetooth module?

[mrbishop]

Ok... I guess common.h is keymap_common.h in the GH60 folder?  If so I think you need to change the ANSI sections to

    K30, K31, K32, K33, K34, K35, K36, K37, K38, K39, K3A,delete K3B           K3D, \
and
    K30, K31, K32, K33, K34, K35, K36, K37, K38, K39, K3A, NO, NO,  K3D, \


I'm not sure why you're trying to pretend this is a GH60, why not build it from scratch so you know how it works?

the suggestion doesn't seem to be working unless i'm just doing it completely wrong. and this doesn't address the other keys.

saddly i dont understand enough about how the firmware code works. i'll see if i can figure it out using the documents at the head of this post.

[mrbishop]

all is working now. thanks again for all the help Suicidal_orange. most was hardware issues. solder breaks etc microscopic amount was software. hopefully i'm now better equipped for my next project and future projects to come, 40% and full 114Key monster as well as led back lit versions and pcb creation. 

[hasu]

Could someone attempt to explain to me the architecture of the "protocol" modules? I see there is already a bluefruit protocol module but I'm thinking that if I want to use hardware SPI then I may need to start from scratch.

So protocols... can multiple be active at once?

Is there an event I can hook into somewhere/somehow that will allow me to capture keys and process them over SPI to the bluetooth module?

Host-side "protocol" is a module(driver) to communicate with host computer, the protocol module is comprised of some functions whitch send key and mouse envent to host. 'host_diriver_t' is a struct includes pointers to those functions, which is what you have to implement.

LUFA protocol driver is defined in here:
https://github.com/tmk/tmk_keyboard/blob/master/tmk_core/protocol/lufa/lufa.c#L63-L75

And RN-42 protocol diver is located in:
https://github.com/tmk/tmk_keyboard/blob/master/keyboard/hhkb/rn42/rn42.c#L11-L24


You can change protocols in turn,  for example, my HHKB Bluetooth controller exchanges LUFA USB protocol and RN-42 BT protocol by BT module status or key combination.

https://github.com/tmk/tmk_keyboard/blob/master/keyboard/hhkb/rn42/rn42_task.c#L73-L81
https://github.com/tmk/tmk_keyboard/blob/master/keyboard/hhkb/rn42/rn42_task.c#L368-L378

[mrbishop]

keyboard stops responding after my computer goes to sleep. all the settings in device manager say wake on power save. is this a know bug or is there a fix for it?
other information. computer in question is a microsoft surface pro 3
works great until sleep. then i have to unplug and plug back in for it to start working again.

[ratch]

Does anyone know how you would switch the number keys so that by default they send the shifted versions and when holding down the shift key, they send the unshifted versions? I tried using an action function, but I don't think trying to track the state of your shift key in the action function is the way to go about it.

[profet]

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.

[Charger]

oh random question hasu, I seem to recall seeing you post about rotary encoders before and I was wondering if anything for them ever made it into the tmk firmware?

[hasu]

profet, nice. keep us updated!
And intresting product, Adafruit has really nice tutorials and resouce of information.

Charger, no. I still have some encoders around and idea of etch-a-stketch mouse somewhere in mind. But I don't know when I can code for it.

[hasu]

Does anyone know how you would switch the number keys so that by default they send the shifted versions and when holding down the shift key, they send the unshifted versions? I tried using an action function, but I don't think trying to track the state of your shift key in the action function is the way to go about it.

you can use get_mods() in action.h to know current modifier state and static variable to "track the state"?

[hasu]

I tried my HHKB(TMK/LUFA) on lenovo X201s running Widows 10 and confirmed it works even after a few sleep and resume cycles.

keyboard stops responding after my computer goes to sleep. all the settings in device manager say wake on power save. is this a know bug or is there a fix for it?
other information. computer in question is a microsoft surface pro 3
works great until sleep. then i have to unplug and plug back in for it to start working again.

[GuilleAcoustic]

It reminds me that I never thanked you for your firmware. It is used everyday inside my M0110, so .... Arigatou gozaima****a !

[mrbishop]

Hmmm not sure then I'll look again at my firmware. It's on windows 8.1 pro. It's joined to a domain so it's not on 10 yet

[Charger]

Charger, no. I still have some encoders around and idea of etch-a-stketch mouse somewhere in mind. But I don't know when I can code for it.

I was thinking more about using one for a volume control but an etch a sketch mouse sounds interesting as well

[ratch]

Does anyone know how you would switch the number keys so that by default they send the shifted versions and when holding down the shift key, they send the unshifted versions? I tried using an action function, but I don't think trying to track the state of your shift key in the action function is the way to go about it.

you can use get_mods() in action.h to know current modifier state and static variable to "track the state"?

I tried this:

Code: [Select]

     
              if (record->event.pressed) {
shift_mod = get_mods()&(MOD_BIT(KC_LSHIFT)|MOD_BIT(KC_RSHIFT));
initial_mods_state = get_mods();
        if (shift_mod) {
    del_mods(shift_mod);
    add_key(KC_1);
    send_keyboard_report();
} else {
    add_mods(MOD_BIT(KC_LSHIFT));
                    add_key(KC_1);
    send_keyboard_report();
}
    } else {
del_key(KC_1);
clear_mods();
add_mods(initial_mods_state); // don't know what happened to the state of the physical shift switch between press and release
send_keyboard_report();
    }

If I release shift before releasing 1, then I get stuck with the shift modifier. I also tried moving all of it into event.pressed, but if I push and hold 1, it outputs something like "!11111".

[hasu]

This kind of thing is not straight and coding is likely to be heuristic and adhoc. It is difficult to find a smart and straight answer.

get_mods() returns logical state of modifiers, not physical key. If you want to track state of physical Shift key you will have to write action function for Shift.

[ratch]

This kind of thing is not straight and coding is likely to be heuristic and adhoc. It is difficult to find a smart and straight answer.

get_mods() returns logical state of modifiers, not physical key. If you want to track state of physical Shift key you will have to write action function for Shift.

Thanks for your responses, Hasu.

Do you have an example of what that might look like? Since I'm updating the logical state of the modifiers, it doesn't seem like get_mods() will help me figure out what the modifier state should be after releasing 1. Rather than try to check the physical keys, is there a way for me to essentially re-sync the modifiers so they're back to what they should be?

I think I understand. So I would need an action function that updates both the logical modifier state and the state of the key which I'm trying to track. I'll give is a try and see what happens.

[hasu]

Ah, OK. I just saw your post was edited now

anyway, what I meant is like below.

Code: [Select]

static uint8_t physical_mods = 0;     
                                 
void action_function(keyrecord_t *record, uint8_t id, uint8_t opt)
{                                 
    switch (id) {                 
        case REVESED_SHIFT_1:     
            ... your code presented above ...     
            break;               
        case MY_LSHIFT:           
            if (record->event.pressed) {
                physical_mods |= MOD_BIT(KC_LSHIFT);
                register_code(KC_LSHIFT);
            } else {             
                physical_mods &= ~MOD_BIT(KC_LSHIFT);
                unregister_code(KC_LSHIFT);
            }                     
            break;               
    }                             
}


[ratch]

Ah, OK. I just saw your post was edited now

anyway, what I meant is like below.

Code: [Select]

static uint8_t physical_mods = 0;     
                                 
void action_function(keyrecord_t *record, uint8_t id, uint8_t opt)
{                                 
    switch (id) {                 
        case REVESED_SHIFT_1:     
            ... your code presented above ...     
            break;               
        case MY_LSHIFT:           
            if (record->event.pressed) {
                physical_mods |= MOD_BIT(KC_LSHIFT);
                register_code(KC_LSHIFT);
            } else {             
                physical_mods &= ~MOD_BIT(KC_LSHIFT);
                unregister_code(KC_LSHIFT);
            }                     
            break;               
    }                             
}


Seems to work exactly how I expected. The only downside to this method is that the shift modifier is active when holding down any of the numbers. Pressing other keys before releasing a number will have a shift modifier active, but I suppose it's not a big concern. Thanks, Hasu!

[hasu]

ratch, great.
Can you post your code and share it? It would be useful for someone else. Thanks,

[ratch]

ratch, great.
Can you post your code and share it? It would be useful for someone else. Thanks,

Sure thing.

https://github.com/matthewjf/tmk_firmware/blob/master/keyboard/gh60/keymap_poker.c

[ratch]

One more question. I made a small change to layer_state_set so that it also updates the keyboard LEDs. When I tap or toggle a layer, it will update the LEDs no problem. When I press & hold, there's a slight delay between when I press the key and the LEDs update. If I tap that same key, there's no delay. Do you have any idea why this might be happening? All my other key presses recognize the correct layer (no delay).

[nephiel]

One more question. I made a small change to layer_state_set so that it also updates the keyboard LEDs. When I tap or toggle a layer, it will update the LEDs no problem. When I press & hold, there's a slight delay between when I press the key and the LEDs update. If I tap that same key, there's no delay. Do you have any idea why this might be happening? All my other key presses recognize the correct layer (no delay).

A tap is sent as soon as you release a key that's been held for less than TAPPING_TERM milliseconds, so it's immediate. But that means it takes TAPPING_TERM milliseconds of holding down a key for it to react as a press & hold - that might be the 'delay' you see.

You can define TAPPING_TERM to a lower value in config.h. I think by default it's set to 500 or something like that, so that's 0.5 seconds, I'd try 200.

In any case, there must always be some delay, otherwise there'd be no way for the board to tell apart a tap from a press & hold.

[ratch]

One more question. I made a small change to layer_state_set so that it also updates the keyboard LEDs. When I tap or toggle a layer, it will update the LEDs no problem. When I press & hold, there's a slight delay between when I press the key and the LEDs update. If I tap that same key, there's no delay. Do you have any idea why this might be happening? All my other key presses recognize the correct layer (no delay).

A tap is sent as soon as you release a key that's been held for less than TAPPING_TERM milliseconds, so it's immediate. But that means it takes TAPPING_TERM milliseconds of holding down a key for it to react as a press & hold - that might be the 'delay' you see.

You can define TAPPING_TERM to a lower value in config.h. I think by default it's set to 500 or something like that, so that's 0.5 seconds, I'd try 200.

In any case, there must always be some delay, otherwise there'd be no way for the board to tell apart a tap from a press & hold.

Interesting. I've never really noticed a delay on my key presses when holding a layer key but it's definitely possible that it appears there as well. I could probably test this by jacking up the tapping_term but it's really not a big deal. I just wanted to make sure there wasn't a better place for me to be updating the LEDs. From the sound of it, the behavior is expected. Thanks, nephiel!

[nephiel]

Note the delay only counts when holding a single key - there is no delay when tapping a second key while holding the first one, because as soon as the second one is tapped, it overrides the hold on the first. So you'd never really notice it unless you use LEDs to show layer state (I do, too).

[BlueNalgene]

Hardware issue question:

I put together an Alps64 to test, and row 4 is misbehaving.  Any time I press a key in row 4, all of the the keys in the column are 'pressed'.  e.g. when I press 43, it sends the signals for 13, 23, 33, 43, 53, 63, 73.  The notable exception is switch K41, which has no switch installed, yet when I short the connection (closing the circuit) it only sends 41.  All of the diodes appear to be in the correct orientation.  I can't find the issue.  I would think if there was a problem like loose solder, the keystrokes would be sending constantly.

[VinnyCordeiro]

Hardware issue question:

I put together an Alps64 to test, and row 4 is misbehaving.  Any time I press a key in row 4, all of the the keys in the column are 'pressed'.  e.g. when I press 43, it sends the signals for 13, 23, 33, 43, 53, 63, 73.  The notable exception is switch K41, which has no switch installed, yet when I short the connection (closing the circuit) it only sends 41.  All of the diodes appear to be in the correct orientation.  I can't find the issue.  I would think if there was a problem like loose solder, the keystrokes would be sending constantly.

Did you hand-soldered the microcontroller on the PCB? This same behavior happened on a prototype keyboard I made and I found that it was caused by a short circuit on microcontroller pins. I solved the problem using solder wick on them.

[BlueNalgene]

Hardware issue question:

I put together an Alps64 to test, and row 4 is misbehaving.  Any time I press a key in row 4, all of the the keys in the column are 'pressed'.  e.g. when I press 43, it sends the signals for 13, 23, 33, 43, 53, 63, 73.  The notable exception is switch K41, which has no switch installed, yet when I short the connection (closing the circuit) it only sends 41.  All of the diodes appear to be in the correct orientation.  I can't find the issue.  I would think if there was a problem like loose solder, the keystrokes would be sending constantly.

Did you hand-soldered the microcontroller on the PCB? This same behavior happened on a prototype keyboard I made and I found that it was caused by a short circuit on microcontroller pins. I solved the problem using solder wick on them.

No, this is a hasu creation which he oven soldered.  When I discovered the error, I checked solder joints.  There was a bad spot on the microcontroller.  I used wick on it, and it did not help.  Although, I might have made it a mess.

[hasu]

Hmm, assuming diodes are in correct direction short circuit on adjacent pins of MCU is most likely cause. Can you drag solder on pins again with flux?

[BlueNalgene]

Hmm, assuming diodes are in correct direction short circuit on adjacent pins of MCU is most likely cause. Can you drag solder on pins again with flux?

I brought it to my lab since I have better tools here.  If I get a free moment I will play with it and report back. 

I'm leaving the country today, and I was hoping to take this with me.  Can you imagine a whole week without a keyboard?

[BlueNalgene]

Wicking did not fix the problem. 

The 'bad spot' I noticed before was some solder connecting two pins on the controller.  Checking the KiCAD files for 23 and 24, these should be connected.  Therefore it isn't an issue.

[BlueNalgene]

I must have not said the magic words.  I checked the diodes with a multimeter, and checked that they weren't shorting across the diodes.  Then I unsoldered the switches in the 4 row.  When I soldered them back in, everything was fixed.  Magic.

[deductivemonkee]

I must have not said the magic words.  I checked the diodes with a multimeter, and checked that they weren't shorting across the diodes.  Then I unsoldered the switches in the 4 row.  When I soldered them back in, everything was fixed.  Magic.

Phew! You had me worried for a second

[hasu]

Great. Glad to hear that.

I had shallow sleep last night and this still scares me terribly, because annoying hardware/soldering problem like this can be happened to many Alps GB paticipants and most of them probably are not patient and don't have decent tools unlike you. Now I worry about diffculty in discrimination between their problem or my failure on board production.

Anyway, my worry is off topic here.