TMK keyboard firmware

[njbair]

I just discovered the existence of the Teensy-LC, made by PJRC who also make the original Teensy 2.0. Here are the specs:

• 48 MHz ARM Cortex-M0+ processor
• 62K Flash
• 8K RAM
• hardware Serial, SPI & I2C, USB
• 27 I/O pins

Would the ChibiOS build work with the Cortex M0+? The really cool part is that the whole board is only $12.

[flabbergast]

Would the ChibiOS build work with the Cortex M0+? The really cool part is that the whole board is only $12.

Yes. (The "Cortex Mn" does not actually mean that much in this context, it's about whether ChibiOS supports the particular chip that's on the LC (MKL27Z64), and with my patches in does.)

[njbair]

Would the ChibiOS build work with the Cortex M0+? The really cool part is that the whole board is only $12.

Yes. (The "Cortex Mn" does not actually mean that much in this context, it's about whether ChibiOS supports the particular chip that's on the LC (MKL27Z64), and with my patches in does.)

You know, only after asking this did I think to check the code just now, and there it is right in your Makefile. What about RAM? 8K doesn't sound like much but I know keymaps and such are stored in flash using PROGMEM.

Speaking of which, I thought things like PROGMEM and uint8_t were specific to avr-gcc. But an ARM firmware doesn't use avr-gcc, does it?

[flabbergast]

RAM: Just for comparison, atmega32u4 has 2.5kB RAM, atmega32u2 (on alps64) has 1kB RAM. 8kB is not too much, but certainly enough. ChibiOS kernel takes about 1-1.5kB in normal configuration (i.e. no debug options enabled {EDIT: by this I mean internal ChibiOS debug, not the TMK DEBUG.}, but also not trying to go absolutely minimal). The TMK onekey example on LC (everything enabled) uses about 3kB of LC's RAM.

PROGMEM: This is AVR specific. On ARMs, it's enough to declare a variable 'const' and it goes automatically into the flash space and doesn't occupy RAM. (That's one of the advantages of having a single address space.)

uint8_t: I think this is a generic gcc thing (I'm 100% sure it's at least a generic embedded GCC thing).

[rsac]

uint8_t: I think this is a generic gcc thing (I'm 100% sure it's at least a generic embedded GCC thing).

It is a C99 (and C++11) thing: https://en.wikipedia.org/wiki/C_data_types#Fixed-width_integer_types

[rsac]

I just discovered the existence of the Teensy-LC, made by PJRC who also make the original Teensy 2.0.

Would the ChibiOS build work with the Cortex M0+? The really cool part is that the whole board is only $12.

There is also the Mapple Mini that you can find clones (made by baite, for example) for less than $5 shipped, from China. The only downside is that it is much longer than a Teensy. For you it might not be better, but for people from outside USA it means not dealing with the high USA international shipping and export restrictions on teensy LC.

Oh, it also don't have an EEPROM. @flabbergast: the teensy LC also has only a few bytes of (emulated) EEPROM. Is this a problem? How easy it is to use an external EEPROM chip with TMK? I'm also curious on how much bigger or smaller (in flash size) is TMK when compiled for ARM Cortex M vs AVR 8bit.

[flabbergast]

Oh, it also don't have an EEPROM. @flabbergast: the teensy LC also has only a few bytes of (emulated) EEPROM. Is this a problem? How easy it is to use an external EEPROM chip with TMK? I'm also curious on how much bigger or smaller (in flash size) is TMK when compiled for ARM Cortex M vs AVR 8bit.

Depends on your programming experience. You just need to replace 'eeprom_read_byte' and 'eeprom_write_byte' functions.
The standard TMK only uses 7 bytes of EEPROM. (I intend to do EEPROM emulation a-la LC also for EEPROM-less STM32s. There is  an example code from ST that does this, so it is definitely doable.)

Firmware size - it depends a lot more on the particular features that you enable/disable then on the architecture. Of course if you use ChibiOS backend, then the binary is somewhat (2-6kB) bigger than bare metal. The fact that ARMs are 32bit tends to increase the memory consumption slightly (alignment requirements), but again, the actual chip hardware has much more influence on this as well (e.g. the size and number of USB buffers, etc).

[rsac]

Depends on your programming experience. You just need to replace 'eeprom_read_byte' and 'eeprom_write_byte' functions.

Ok, it seems that the hardest part would be interfacing with the external EEPROM. I have no experience with those hardware things. I will probably avoid that part though. I'm going to experiment with a micro-sd reader anyway. I want to log key press statistics, including digraphs, trigraphs, etc, and latter try to implement programmable macros. Given that, I can make those functions write to a Fat32 file. If you isn't faster. You will implement this?

As for the firmware size between architectures, of course the comparison should be with between equivalent tmk features (say, all of them).

[flabbergast]

Having done both, I find interfacing with EEPROMs way easier that interfacing with (micro)SD cards. For EEPROMs it's basically enough to read its datasheet and use SPI or I2C; with microSD it's SPI but the point is that the protocol is quite a bit more complicated. Also this gives you raw blocks (like doing 'dd' in linux). You'll then need to do a FAT read/write layer.
However there are libraries for everything, so it's not very hard, it's just that you'll need to plug several of them together.

About the EEPROM emulation - yes, I mean to implement that (I mean the application note you linked) but start with STM32F0, because I have no F4s That will be good enough for the cca 10 bytes of EEPROM that TMK uses; however I would not recommend logging into flash with this, because of the limited number of flash erase operations (I think it's generally around 10000 guaranteed). You can maybe get away with this if you use a MCU with a very large flash (like 512kB or such) and use a lot of flash for wear levelling (almost all of it), and be smart about writing to it.

Firmware size: As a rule of thumb, I would expect the firmwares using the ChibiOS backend to be more-less 5kB bigger than the bare metal AVR ones (so e.g. 20kB vs 25kB). But in the memory consumption there is a "bigger" difference, maybe 3kB more (but this time it's 1kB vs 4kB).

[e_l_tang]

What exactly does ChibiOS do? Does it act as a "translator" between TMK and ARM chips?

[flabbergast]

I started writing some notes about this. Not really finished in any way, but they hopefully contain an answer to this question:
text file

[Moistgun]

Hi, Im trying to create a hex file to program my hand wire project.
Im following Matt30's guide but I cant get the thing to compile

would someone be willing to try to compile this for me?
its just the GH60 folder.
I think thats all that is needed right?

https://www.dropbox.com/s/zps95d2kr3f9lif/gh60.zip?dl=0


the error im getting can be seen on this thread.
https://geekhack.org/index.php?topic=80853.msg2119862#msg2119862

[flabbergast]

It's this: https://github.com/tmk/tmk_keyboard/issues/99
{It comes up every few weeks. Try to get rid of as much of winavr from your computer as you can; or else you can get weird errors from basic tools (make, grep) even when you'll be using a completely different toolchain.}

[Moistgun]

I tried it in linux to compile but I ended up with something else that I don't understand

In file included from keymap_poker.c:1:0:
keymap_common.h:46:1: error: parameter name missing
 ) { \
 ^

also at the bottom
make: *** [obj_gh60_lufa/keymap_poker.o] Error 1



in my keymap_common.h it shows

K40, K41,      K43,                K47,                K4B, K4C, K4D, \
) { \

[e_l_tang]

Your first KEYMAP macro needs a closing parenthesis like that of your second one.

[Moistgun]

Your first KEYMAP macro needs a closing parenthesis like that of your second one.

My first set starts with (  and ends with )
how am i doing it wrong?

[Moistgun]

My error code said it needed a parenthesis, but the true error was a trailing comma after the last key in the keymap
K40, K41,      K43,                K47,                K4B, K4C, K4D, \
) { \

[e_l_tang]

You're correct about that extra comma in keymap_common.h, but I don't see a closing parenthesis for the first KEYMAP macro in keymap_poker.c.

[Moistgun]

Oh, I see, I was only looking through the common file for errors 

Thanks Eric-t Ill give it a shot tonight.

[njbair]

So I'm trying something a little more complicated here with a function action. So far it's working in concept, but my board goes haywire after using the feature a few times.

Basically, I'm trying to emulate the behavior of the Mac keyboard layout Dvorak - QWERTY Command, where the board uses Dvorak layout, but when you hold down the Command button, it switches the alphas to QWERTY layout, so you can still use the familiar one-handed Ctrl+C, Ctrl+V, etc., that we are all so used to. I've got it mostly working with the following code:

Code: [Select]

uint32_t default_layer_state;
uint32_t qwerty_fallback_previous_state;

void action_function(keyrecord_t *record, uint8_t id, uint8_t opt __attribute__ ((unused))) {
    switch (id) {
        case F_CTRL_QWERTY_FALLBACK:
            if (record->event.pressed) {
                qwerty_fallback_previous_state = default_layer_state;
                default_layer_set(1UL<<L_QWERTY);
                add_weak_mods(MOD_LCTL);
            } else {
                default_layer_set(1UL<<qwerty_fallback_previous_state);
                del_weak_mods(MOD_LCTL);
            }
            break;
    }
};

But after using the Ctrl key 3 times in a row, it messes up the keymap and all the keys get mixed up.

Interestingly, if I use Ctrl twice, then manually switch the default layer, I can use Ctrl again. But the moment I use it 3 times in a row without manual intervention in between, the keymap goes haywire.

Any ideas? It sounds like a memory issue but I don't know enough about C to say for sure.

[e_l_tang]

Why are you playing with default_layer_state? Why don't you just use ACTION_LAYER_MODS?

[rsac]

Having done both, I find interfacing with EEPROMs way easier that interfacing with (micro)SD cards. For EEPROMs it's basically enough to read its datasheet and use SPI or I2C; with microSD it's SPI but the point is that the protocol is quite a bit more complicated. Also this gives you raw blocks (like doing 'dd' in linux). You'll then need to do a FAT read/write layer.
However there are libraries for everything, so it's not very hard, it's just that you'll need to plug several of them together.

About the EEPROM emulation - yes, I mean to implement that (I mean the application note you linked) but start with STM32F0, because I have no F4s That will be good enough for the cca 10 bytes of EEPROM that TMK uses; however I would not recommend logging into flash with this, because of the limited number of flash erase operations (I think it's generally around 10000 guaranteed). You can maybe get away with this if you use a MCU with a very large flash (like 512kB or such) and use a lot of flash for wear levelling (almost all of it), and be smart about writing to it.

Firmware size: As a rule of thumb, I would expect the firmwares using the ChibiOS backend to be more-less 5kB bigger than the bare metal AVR ones (so e.g. 20kB vs 25kB). But in the memory consumption there is a "bigger" difference, maybe 3kB more (but this time it's 1kB vs 4kB).

I mean that messing with microSDs is something I wanted to do anyway, so doing the EEPROM that way is no extra work. What I'm kinda hoping is that someone has already done a nice library to abstract everything about it, like sdfatlib or SD library in arduino. I havent looked deeply yet, but here seems to be a fat32 demo for chibios. Don't seem as friendly as Arduino's SD lib but probably workable.

As for wear levelling, I will partially trust the microSD one, but I also plan to write the updates in batches that can be summed up latter. I have plenty of space, and plenty of time when I try to read it back. As for security, I don't think it will be a problem, but I can encrypt it with my public key. Or an one time pad, if the former is too dificult/impractical.

And for the firmware size, you are saying that code compiled for ARM Cortex M will be about the exact same size than for AVR8? The only difference is the ChibiOS overhead? Besides higher memory consumption.

[flabbergast]

@rsac: Yes, in my experience code compiled for ARM has more-less the same size as the same code compiled for AVR. The resulting binary size depends much much more on the optimisation level enabled in GCC and also on the particular GCC release.
However this comparison is pretty much moot, because it would require completely hardware-independent code. The hardware-specific portions of the code (HAL) will make the resulting firmware size differ quite a bit even within ARM MCUs themselves (for instance the size of the USB buffers, if not dynamically allocated).

[njbair]

Why are you playing with default_layer_state? Why don't you just use ACTION_LAYER_MODS?

Because the QWERTY layer is at the bottom of the stack. You can't switch to a lower layer.

[e_l_tang]

Why not put that layer at the top of the stack?

[njbair]

Why not put that layer at the top of the stack?

Well, reasons. Firstly, Boot Magic reads its commands based on the layout at layer 0, which I want to be QWERTY so that I can make EEPROM changes without having to mentally translate keymaps (the keycaps are still in QWERTY layout, despite my preference for Dvorak). Secondly, that doesn't really solve the problem, just hacks around it. And I don't want to define two identical QWERTY layers because DRY.

Anyway, I managed to find my bug. When you set the default layer to, say, layer 2, you have to bit-shift that 2. I was storing the previous default_layer_state in a placeholder variable, but when I was reassigning it I was absentmindedly doing 1UL<<qwerty_fallback_previous_state, which was bit-shifting an already bit-shifted value, effectively causing the default layer to double in value each time. Mine went from 1 to 2 to 4 to 16, and since I don't have sixteen layers defined, it was pulling keycodes from somewhere outside the correct memory range. Thus, haywire layout.

So now I've got the best of both worlds for Ctrl shortcuts. If I use the HHKB Ctrl (Caps Lock position), I can use the current layout. This is how I normally type, and for the most part I'm used to cut/copy/paste/etc. on Dvorak. But for left-handed use while mousing, I can use the Ctrl in the standard bottom-left positon, which re-maps the alphas to QWERTY until I release it. It's a pretty cool setup!

Oh, and Right Ctrl is remapped to Caps Lock, so I can still use the Keyboard Lock magic command (lshift+rshift+caps). I have kids and they like to bang on keyboards. Hardware-lock is invaluable to me.

[Kalp1]

Hello coders, It's been 2 days that I'm struggling with my AMJ40's firmware.

I've found a fonctional one on Github, but I want to edit the keymap. So I opened keymap_default with Mfile and changed the keymap.
Build the firmware, load it on AMJ40, but I'm back with the older keymap.

Do I need to change something else in Makefile, config.h or keymap_common.h ??

I tried removing driver, changing VID and PID, nothing worked.

Newbie there. Excuse me if this basic question have been already asked, but I've read build/keymap's core/faq and found nothing about this.

Edited keymap:

Code: [Select]

  /* Keymap 0: Default Layer
     * ,-------------------------------------------------.
     * |Esc | Q|  W|  E|  R|  T|  Y|  U|  I|  O|  P| Bs  |
     * |-------------------------------------------------|
     * |Tab  |  A|  S|  D|  F|  G|  H|  J|  K|  L|  Ent |
     * |-------------------------------------------------|
     * |Shift   |  Z|  X|  C|  V|  B|  N|  M|  /| SFT|FN0|
     * |-------------------------------------------------|
     * |Ctrl|Win |Alt |       Space            | ' |Ctrl|
     * `-------------------------------------------------'
     */
    KEYMAP(
        ESC, Q,   W,   E,   R,   T,   Y,   U,   I,   O,   P, BSPC,\
        TAB,A,   S,   D,   F,   G,   H,   J,   K,   L,       ENT,\
        LSFT,     Z,   X,   C,   V,   B,   N,   M, SLSH,RSFT,  FN0,\
        LCTL,LGUI,LALT,          SPC,                  QUOT,RCTL),
Original:

Code: [Select]

   /* Keymap 0: Default Layer
     * ,-------------------------------------------------.
     * |Esc | Q|  W|  E|  R|  T|  Y|  U|  I|  O|  P| Bs  |
     * |-------------------------------------------------|
     * |Caps  |  A|  S|  D|  F|  G|  H|  J|  K|  L|  Ent |
     * |-------------------------------------------------|
     * |Shift   |  Z|  X|  C|  V|  B|  N|  M|  /| SFT|FN0|
     * |-------------------------------------------------|
     * |Ctrl|Win |Alt |       Space            | Alt |Ctrl|
     * `-------------------------------------------------'
     */
    KEYMAP(
        ESC, Q,   W,   E,   R,   T,   Y,   U,   I,   O,   P, BSPC,\
        CAPS,A,   S,   D,   F,   G,   H,   J,   K,   L,       ENT,\
        LSFT,     Z,   X,   C,   V,   B,   N,   M, SLSH,RSFT,  FN0,\
        LCTL,LGUI,LALT,          SPC,                  RALT,RCTL),

[flabbergast]

Depends on which firmware are you actually using. Some of the forks (e.g. Kai Ryu's) actually store the keymap in EEPROM, so even if you flash a new firmware, it may still be using the keymap it finds in EEPROM. You can try using bootmagic to erase the EEPROM settings (usually holding Space+Backspace during power-up). See https://github.com/tmk/tmk_keyboard#general .

[Kalp1]

Depends on which firmware are you actually using. Some of the forks (e.g. Kai Ryu's) actually store the keymap in EEPROM, so even if you flash a new firmware, it may still be using the keymap it finds in EEPROM. You can try using bootmagic to erase the EEPROM settings (usually holding Space+Backspace during power-up). See https://github.com/tmk/tmk_keyboard#general .

Thank you for your fast response, I will try it.

Edit: It worked ! But lost backlight in the process
I'll try to build another firmware or maybe try to "dump" Eeprom

I' ve also seen bugs with  key from the last alpha row that send input from bottom row, like C doing C+SPACE, B doing B+ALT ...

[Kalp1]

So it' s seems that this firmware https://github.com/AMJKeyboard/AMJ40 doesn' t support backlight.

So I used the HEX file, that the sellor from taobao send to me, and everything worked fine again.
But I still can' t edit the layout, since I only have the hex file.

Do you think it is possible to reverse build HEX file ?

[kasakka]

I'm looking to make a custom 60% but I really like the "R.Alt + Spacebar = Arrow keys" toggle on my Pok3r. Is something like that possible with the TMK firmware as it's not really toggling a layer but just remapping a few buttons?

I'm going custom because Pok3r can't do numpad keys and alt keycodes and I'd like to play around with the layout a bit.

[hasu]

I'm looking to make a custom 60% but I really like the "R.Alt + Spacebar = Arrow keys" toggle on my Pok3r. Is something like that possible with the TMK firmware as it's not really toggling a layer but just remapping a few buttons?

I'm going custom because Pok3r can't do numpad keys and alt keycodes and I'd like to play around with the layout a bit.

I don't know how Pok3r works actually, but this keymap can emulate Poer X including arrow keys toggle.
https://github.com/tmk/tmk_keyboard/blob/master/keyboard/gh60/keymap_poker.c

As you can see it is a bit tricky or not easy.

[e_l_tang]

@kasakka That functionality can be very easily enabled with a macro.

[kasakka]

I'm looking to make a custom 60% but I really like the "R.Alt + Spacebar = Arrow keys" toggle on my Pok3r. Is something like that possible with the TMK firmware as it's not really toggling a layer but just remapping a few buttons?

I'm going custom because Pok3r can't do numpad keys and alt keycodes and I'd like to play around with the layout a bit.

I don't know how Pok3r works actually, but this keymap can emulate Poer X including arrow keys toggle.
https://github.com/tmk/tmk_keyboard/blob/master/keyboard/gh60/keymap_poker.c

As you can see it is a bit tricky or not easy.

Cool, thanks for the reply. I think what I'll end up doing is setting that section permanently as arrow keys and using a Fn button next to shift to make them do something else when needed (probably just PgUp,PgDn,Home and End).

[ProCarpet]

Hello there i've been working again on my keyboard recently and have made some progression. I've used matt3o's

More

https://deskthority.net/workshop-f7/how-to-build-your-very-own-keyboard-firmware-t7177.html

guid to build my firmware and to correct it(at least i thougth i had done this). But when i plug in my teensy i behaves strangely it posts a few random keys and then nothing, just to go haywaer from time to time. Once i had it pluged in on a devboard where i had waired all the cols to gnd but one and connected this to rowx with a switch and it returned w as it should whenever i pressed the button.
I've been unable to sort out the problem on why it goes haywire from time to time neither have i been able to reliably reproduce said behaiviour.
I hope someone here can help me, because im at lose.

I've pluged in the teens2.0 on such a device:

More

Here is a picture of my matrix(i know its not fully connected yet and the ressistors are unnecesary):

More

                                                                                       
And the code i've written:https://www.dropbox.com/s/j0iyzltbnnsyalj/gh60.rar?dl=0

Edit: I tried running aqua key while teensy is pluged in it starts by spmaing F3,3,4,E,D and moves then to F5 and oters.  (note it didnt press the Win key that was me)
I left it pluged in for a good 10secs or so.

More

Edit2:In the config.h where 5 and 13 defined for the rows and cols fixed that but didn't fix my problem :/


I hope someone can help me with this 

[Columnaire]

Hi I have a new question. I have an Ergodox EZ and I have one of the three LEDs indicate the Caps Lock function. That works fine. I would like the same light to turn on when I press the Shift key (and turn off when I release it). How do I determine whether Shift is being held down?

[e_l_tang]

@Columnaire You have to put #include "action_util.h" at the top of your keymap file. That will allow you to test the condition (keyboard_report->mods & (MOD_BIT(KC_LSFT) | MOD_BIT(KC_RSFT))).

[e_l_tang]

@ProCarpet It doesn't look like you have a column connected to E6. Also, your unselect_rows function does not look right.

[ProCarpet]

@ProCarpet It doesn't look like you have a column connected to E6. Also, your unselect_rows function does not look right.

Thans for your reply
ive removed col E6 and have switched the zeros for ones ind the unselect_rows
It now spits out diferent charakters but still doesnt work
updated version https://www.dropbox.com/s/7c58rq789xw0s3f/gh60_2.rar?dl=0

[a-c]

LSB is on the right. Your bits are backwards.

Code: [Select]

/* Row pin configuration
 * row: 0   1   2   3   4   5 
 * pin: B0  B1  B2  B3  D0  B7
 */
static void unselect_rows(void)
{
    // Hi-Z(DDR:0, PORT:0) to unselect
    DDRD  &= ~0b10000000;
    PORTD &= ~0b10000000;
    DDRB  &= ~0b11110001;
    PORTB &= ~0b11110001;
}


[ProCarpet]

Thanks alot a-c, it now does no longer spam random stuff. It also has a normal output. Just the programm doesnt corespond with the pins yet somehow ill look in to that now.
Edit: i'm an idiot and should have known better everything works just fine i tested the Y switch and in aqua key Y lighted up on row 3 but i have it on row 1 because i modified the us layout duhh. 

[Columnaire]

(keyboard_report->mods & (MOD_BIT(KC_LSFT) | MOD_BIT(KC_RSFT))).

Thank you, Eric-T, that was exactly what I needed!

[kekman]

Hi, are there any resources for programming leds? by default my board has 2 backlighting options, breathing and full backlit with 3 levels of brightness. however, it's factory flashed so I'm not sure how they did it, and I'm looking at setting up some custom effects

[e_l_tang]

@kekman What keyboard do you have?

[kekman]

A GH60

[e_l_tang]

@kekman You're in luck. Your keyboard is one of the few keyboards directly supported by TMK. Its folder is at https://github.com/tmk/tmk_keyboard/tree/master/keyboard/gh60. What light effects do you want to program?

[kekman]

some of the effects on ducky shine keyboards, such as lighting keypresses, and pulse out from keypress. i have experience with programming kb with tmk before, but never tried programming leds.

[e_l_tang]

You're going to need individually addressable LEDs for those effects. Are you sure you have them? If your keyboard's LEDs are all at the same brightness level at a given time, you probably don't.

[kekman]

I doubt it. Are there any resources regarding the matter though? I want to test what I'm able to do with it and see what happens from there.

[goflo]

Got another problem again 
I'm just rewiring a Maltron 3D keyboard with a Teensy2++

Got 7 rows and 19 columns, so I had to use the 1UL<<16 for responses of my last 3 columns.
Now I got the following problem....if I press a key from column 16 I get multiple key presses.
Mostly the next 2 keys to the right, one key gives me the next 3 keys to the right.

All other columns and rows work fine, it's just that one column that goes wild.
I'm pretty sure my soldering is quite ok, but I got the ping it through with my multimeter.

Any ideas if that could be some wrong configuration?