Author Topic: TMK keyboard firmware  (Read 819763 times)

0 Members and 1 Guest are viewing this topic.

Offline suicidal_orange

  • * Global Moderator
  • Posts: 4771
  • Location: England
Re: TMK keyboard firmware
« Reply #1150 on: Sun, 10 January 2016, 13:06:50 »
Haha, why didn't I think of that!  Seems the config was correct for Caps to work but definitely no light...

I'm going to wait until I have the correct value resistors to solder in before testing further, perhaps I'm just not making good enough contact (though I get light from the GPIO + and - pads, so pretty sure I am)



120/100g linear Zealio R1  
GMK Hyperfuse
'Split everything' perfection  
MX Clear
SA Hack'd by Geeks     
EasyAVR mod

Offline flabbergast

  • Posts: 234
  • Location: UK
Re: TMK keyboard firmware
« Reply #1151 on: Sun, 10 January 2016, 14:53:46 »
Forgot to say: these LEDs are powered through the MCU, so the resistors should be enough so that they don't draw too much power (I think the rules are 20mA per pin, 100mA all things together).

Offline mastermachetier

  • Posts: 59
Re: TMK keyboard firmware
« Reply #1152 on: Sun, 10 January 2016, 19:33:54 »
Hey first of all thank you for the awesome firmware its beautiful. I am pretty new to the world of hardware and also coding. I have a apple standard keyboard M0116 that i converted from adb using the tmk firmware. It is working beautifully, the next step i would like to do is convert it to bluetooth. I saw the bluetooth protocol in the repo this is just if you are using serial. I have a bluefruit ez-link that supports serial , but i also have a bluefruit le spi that supports bluetooth hid. https://learn.adafruit.com/introducing-the-adafruit-bluefruit-spi-breakout/hidkeyboard  . So after all that my questions are

1. Is there an advantage to using the bluetooth hid instead of serial ? If so how hard would it be to implement and where would I begin.
2. How do I add the bluefruit protocol in the firmware to the makefile for the adb converter .

Thanks !

Offline mastermachetier

  • Posts: 59
Re: TMK keyboard firmware
« Reply #1153 on: Mon, 11 January 2016, 17:40:16 »
"posted by mistake" :(

Offline zeroni13

  • Posts: 97
  • Location: Oslo, Norway
Re: TMK keyboard firmware
« Reply #1154 on: Sat, 16 January 2016, 07:55:42 »
Hi,

I'm trying to build TMK for my Ghost Squid controller, but it won't build correctly
It works with other keyboards in the other folders.

Here is the output from my terminal: http://hastebin.com/omuhusiday.tex

Could anyone please help me figure out what's wrong?

I'm have not changed anything in the folder and the guide tell me to simply

"Move to this directory then just run make like:

$ make -f Makefile.lufa"

Should not be that hard, maybe I'm just really stupid today..
Phantom with Silver Vortex Case   Keychron Q6 Pro ISO Knob
                               

Offline hasu

  • Thread Starter
  • Posts: 3471
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: TMK keyboard firmware
« Reply #1155 on: Sat, 16 January 2016, 08:03:35 »
maybe you need to update your toolchain.

Offline a-c

  • Posts: 196
  • Location: USA
Re: TMK keyboard firmware
« Reply #1156 on: Sat, 16 January 2016, 09:41:29 »
Same error with winavr

Compiles fine in Linux.

Offline flabbergast

  • Posts: 234
  • Location: UK
Re: TMK keyboard firmware
« Reply #1157 on: Sat, 16 January 2016, 10:49:51 »
Please do not use winavr, it is way too old by now. Errors/problems like this pop up here or on DT every couple of months. The way to update the toolchain is either this, or just get cygwin/msys separately and install the toolchain from e.g. here.

Offline suicidal_orange

  • * Global Moderator
  • Posts: 4771
  • Location: England
Re: TMK keyboard firmware
« Reply #1158 on: Sun, 17 January 2016, 05:43:23 »
I'm being stupid again, can someone please point out where?

This works perfectly (Fn0 as will be outputs a K as a placeholder)
Code: [Select]
#include "keymap_common.h"

/*
 * Custom Layout
 */
const uint8_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
    /* 0: Default layer
     * ,------------------------------------------------------------.
     * |Esc|  1|  2|  3|  4|  5|  6|  7|  8|  9|  0|  -|  =|  `| Del|
     * |------------------------------------------------------------|
     * |Tab  |  Q|  W|  E|  R|  T|  Y|  U|  I|  O|  P|  [|  ]|Return|
     * |------------------------------------------------------------|
     * |Ctrl  |  A|  S|  D|  F|  G|  H|  J|  K|  L|  ;|  '|   #|Bksp|
     * |------------------------------------------------------------|
     * |Shft| \|  Z|  X|  C|  V|  B|  N|  M|  ,|  .|  /|Shft|    Fn0|
     * |------------------------------------------------------------|
     * |Ctrl|Gui |Alt |      Space             | Alt| Gui| APP| Ctrl|
     * `------------------------------------------------------------'
     */
    KEYMAP_HHKB(
        ESC, 1,   2,   3,   4,   5,   6,   7,   8,   9,   0,   MINS,EQL, GRV, DEL,\
        TAB, Q,   W,   E,   R,   T,   Y,   U,   I,   O,   P,   LBRC,RBRC,ENT,     \
        LCTL,A,   S,   D,   F,   G,   H,   J,   K,   L,   SCLN,QUOT,NUHS,BSPC,    \
        LSFT,NUBS,Z,   X,   C,   V,   B,   N,   M,   COMM,DOT, SLSH,RSFT,   K,   \
        LCTL,  LGUI,LALT,          SPC,                   RALT,APP,RGUI,RCTL),

};

const uint16_t PROGMEM fn_actions[] = {};

but adding a layer makes FN0 output a G?

Code: [Select]
#include "keymap_common.h"

/*
 * Custom Layout
 */
const uint8_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
    /* 0: Default layer
     * ,------------------------------------------------------------.
     * |Esc|  1|  2|  3|  4|  5|  6|  7|  8|  9|  0|  -|  =|  `| Del|
     * |------------------------------------------------------------|
     * |Tab  |  Q|  W|  E|  R|  T|  Y|  U|  I|  O|  P|  [|  ]|Return|
     * |------------------------------------------------------------|
     * |Ctrl  |  A|  S|  D|  F|  G|  H|  J|  K|  L|  ;|  '|   #|Bksp|
     * |------------------------------------------------------------|
     * |Shft| \|  Z|  X|  C|  V|  B|  N|  M|  ,|  .|  /|Shft|    Fn0|
     * |------------------------------------------------------------|
     * |Ctrl|Gui |Alt |      Space             | Alt| Gui| APP| Ctrl|
     * `------------------------------------------------------------'
     */
    KEYMAP_HHKB(
        ESC, 1,   2,   3,   4,   5,   6,   7,   8,   9,   0,   MINS,EQL, GRV, DEL,\
        TAB, Q,   W,   E,   R,   T,   Y,   U,   I,   O,   P,   LBRC,RBRC,ENT,     \
        LCTL,A,   S,   D,   F,   G,   H,   J,   K,   L,   SCLN,QUOT,NUHS,BSPC,    \
        LSFT,NUBS,Z,   X,   C,   V,   B,   N,   M,   COMM,DOT, SLSH,RSFT,FN0,   \
        LCTL,  LGUI,LALT,          SPC,                   RALT,APP,RGUI,RCTL),

    /* 1: FN layer
     * ,------------------------------------------------------------.
     * |LED| F1| F2| F3| F4| F5| F6| F7| F8| F9|F10|F11|F12|Ins|Del |
     * |------------------------------------------------------------|
     * |Tab  |  Q|  W|  E|  R|  T|  Y|  U|  I|  O|  P|  [|  ]|Return|
     * |------------------------------------------------------------|
     * |Ctrl  |  A|  S|  D|  F|  G|  H|  J|  K|  L|  ;|  '|   #|Bksp|
     * |------------------------------------------------------------|
     * |Shft| \|  Z|  X|  C|  V|  B|  N|  M|  ,|  .|  / | Up |    Fn|
     * |------------------------------------------------------------|
     * |Ctrl|Gui |Alt |      Space             | Alt|Left|Down|Right|
     * `------------------------------------------------------------'
     */
    KEYMAP_HHKB(
        TRNS, F1,  F2,  F3,  F4,  F5,  F6,  F7,  F8,  F9,  F10, F11, F12, INS, DEL,\
        TAB, Q,   W,   E,   R,   T,   Y,   U,   I,   O,   P,   LBRC,RBRC,ENT,     \
        LCTL,A,   S,   D,   F,   G,   H,   J,   K,   L,   SCLN,QUOT,NUHS,BSPC,    \
        LSFT,NUBS,Z,   X,   C,   V,   B,   N,   M,   COMM,DOT, SLSH,UP,TRNS,   \
        LCTL,  LGUI,LALT,          SPC,                   RALT,LEFT,DOWN,RGHT),
};
const uint16_t PROGMEM fn_actions[] = {};

I've changed just about every file in the gh60 folder to create this "all keys" variant starting from HHKB as it had the split backspace but thought once it worked for one layer it would work for all.  Guess not!
120/100g linear Zealio R1  
GMK Hyperfuse
'Split everything' perfection  
MX Clear
SA Hack'd by Geeks     
EasyAVR mod

Offline a-c

  • Posts: 196
  • Location: USA
Re: TMK keyboard firmware
« Reply #1159 on: Sun, 17 January 2016, 07:28:14 »
Do you have FN0 defined as an action?

Offline Koren

  • Posts: 133
  • Location: France
Re: TMK keyboard firmware
« Reply #1160 on: Sun, 17 January 2016, 08:15:11 »
Do you have FN0 defined as an action?

I think that's the problem... There's apparently no action defined for FN0,
Code: [Select]
const uint16_t PROGMEM fn_actions[] = {};(although it could be done in a different fashion)

Not sure what FN0 should do, but since I don't see a layer switch, I guess it's the goal. So something like
Code: [Select]
const uint16_t PROGMEM fn_actions[] = {
    [0] = ACTION_LAYER_TAP_TOGGLE(1)
};
would probably be welcome...

Offline suicidal_orange

  • * Global Moderator
  • Posts: 4771
  • Location: England
Re: TMK keyboard firmware
« Reply #1161 on: Sun, 17 January 2016, 09:53:31 »
Do you have FN0 defined as an action?

I think that's the problem... There's apparently no action defined for FN0,
Code: [Select]
const uint16_t PROGMEM fn_actions[] = {};(although it could be done in a different fashion)

Not sure what FN0 should do, but since I don't see a layer switch, I guess it's the goal. So something like
Code: [Select]
const uint16_t PROGMEM fn_actions[] = {
    [0] = ACTION_LAYER_TAP_TOGGLE(1)
};
would probably be welcome...

Told you I was being stupid :))  That of course fixed it - thanks!
120/100g linear Zealio R1  
GMK Hyperfuse
'Split everything' perfection  
MX Clear
SA Hack'd by Geeks     
EasyAVR mod

Offline Koren

  • Posts: 133
  • Location: France
Re: TMK keyboard firmware
« Reply #1162 on: Sun, 17 January 2016, 12:36:25 »
Told you I was being stupid :))  That of course fixed it - thanks!
Definitively not stupid (you need to be quite skilled to compile and upload the firmware, already), just unaware of how things work in the firmware (yet). Happy that things are running now... Feel free to ask if there's anything else!

Offline deductivemonkee

  • Posts: 572
  • Location: Canada BC
  • Professional Lurker
Re: TMK keyboard firmware
« Reply #1163 on: Mon, 18 January 2016, 11:53:59 »
The oneshot shift on the alps64 tmk editor seems to act as a normal shift.
oh yeah I saw that crazy **** if that doesn't win I'm deleting my account

/ orthodox - 78g zealios / alps64 - mtsc / sentraq s-60x rgb - gat blues / let's split - 67g zealios / let's split - 67g zealios /

Offline MrCyprus

  • Posts: 14
  • Location: Arizona
    • SunStruck Magazine
Re: TMK keyboard firmware
« Reply #1164 on: Mon, 18 January 2016, 14:44:58 »
Is there any word on support for the teensy 3.2?  I accidentally ordered one and am now trying to decide if I should try to make it work or just save myself some trouble and get a 2.

Offline flabbergast

  • Posts: 234
  • Location: UK
Re: TMK keyboard firmware
« Reply #1165 on: Mon, 18 January 2016, 15:01:36 »
Is there any word on support for the teensy 3.2?  I accidentally ordered one and am now trying to decide if I should try to make it work or just save myself some trouble and get a 2.
There is, but not for the rookies. Things work (e.g. the infinity keyboard, or the whitefox (WF uses the same chip as Teensy 3.2)), but still rather beta, expect to run into bugs and/or compilation problems.

Offline henz

  • * Exquisite Elder
  • Posts: 1284
  • What?
Re: TMK keyboard firmware
« Reply #1166 on: Mon, 18 January 2016, 15:17:32 »
Is there any word on support for the teensy 3.2?  I accidentally ordered one and am now trying to decide if I should try to make it work or just save myself some trouble and get a 2.

i wrote some code in teensyduino if your interested, its using the keyboard library which is included in arduino:

https://github.com/ageaenes/teensykb

I guess you need some basic coding skills to make it work with whatever board you want to use it with, mine is for a handwired apple m0116.

I did the same blunder as you did, although it was at the time 3.1 i bought :)


Offline MrCyprus

  • Posts: 14
  • Location: Arizona
    • SunStruck Magazine
Re: TMK keyboard firmware
« Reply #1167 on: Mon, 18 January 2016, 15:18:11 »
Is there any word on support for the teensy 3.2?  I accidentally ordered one and am now trying to decide if I should try to make it work or just save myself some trouble and get a 2.
There is, but not for the rookies. Things work (e.g. the infinity keyboard, or the whitefox (WF uses the same chip as Teensy 3.2)), but still rather beta, expect to run into bugs and/or compilation problems.

Thanks!  I will take a look at this and make a decision from there.

Offline hasu

  • Thread Starter
  • Posts: 3471
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: TMK keyboard firmware
« Reply #1168 on: Mon, 18 January 2016, 21:51:03 »
The oneshot shift on the alps64 tmk editor seems to act as a normal shift.

I confirmed it works.
I think 'oneshot modifier' doesn't work like what you expect. It works as normal modifier in most cases except for when you tap(press and release quickly) it.

This description is confusing? TMK requires documenation improvement as always :D your contribution is welcomed.
https://github.com/tmk/tmk_keyboard/blob/master/tmk_core/doc/keymap.md#43-oneshot-modifier

Offline Kaibz

  • Posts: 48
  • Location: AFK but not too much
Re: TMK keyboard firmware
« Reply #1169 on: Thu, 21 January 2016, 08:31:47 »
I have been using this firmware for more than a year and it is awesome and once again thanks to Hasu for his amazing work!!!! I actually think that because of this firmware i have one of the best gamer keyboard you can find not only because of nkro but also the 1000hz polling rate which makes it very reactive.

I have one question that may seem stupid but honestly i am still a beginner and i just want to learn....I know that this firmware is very advanced, complex and written in C and i'll never be able to understand it as much as i would like. But if i wanted to make a firmware for a 84 keys keyboard by modifying one of the examples of the arduino IDE like this one, like Henz did :

Code: [Select]
#include <Keypad.h>

const byte ROWS = 4; //four rows
const byte COLS = 4; //four columns
//define the cymbols on the buttons of the keypads
char hexaKeys[ROWS][COLS] = {
  {'0','1','2','3'},
  {'4','5','6','7'},
  {'8','9','A','B'},
  {'C','D','E','F'}
};
byte rowPins[ROWS] = {3, 2, 1, 0}; //connect to the row pinouts of the keypad
byte colPins[COLS] = {7, 6, 5, 4}; //connect to the column pinouts of the keypad

//initialize an instance of class NewKeypad
Keypad customKeypad = Keypad( makeKeymap(hexaKeys), rowPins, colPins, ROWS, COLS);

void setup(){
  Serial.begin(9600);
}
 
void loop(){
  char customKey = customKeypad.getKey();
 
  if (customKey){
    Serial.println(customKey);
  }
}


My question is, the difference between the 2 firmwares would it be that the code would run slower and that i wouldn't get 1000hz polling rate as i do with TKM? Or that i wouldn't have the ability to implement NKRO? Or would it be just less reliable....?
On the other hand it would make things easier for me to implement a LCD for example, as i would have acces to libraries right?

Thank you.

« Last Edit: Thu, 21 January 2016, 08:56:17 by Kaibz »
Sharing the knowledge

Offline hasu

  • Thread Starter
  • Posts: 3471
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: TMK keyboard firmware
« Reply #1170 on: Thu, 21 January 2016, 18:34:13 »
I think there is no reason why Arduino prevents you from making keyboard that you described. Arduino is powerful option, in particular due to its community and enormous libraries. You cannot go wrong with Arduino.

I don't know "1000hz polling" definition in gaming community but I don't think TMK is so fast by default. You will be able to improve it easily, though.

Offline Kaibz

  • Posts: 48
  • Location: AFK but not too much
Re: TMK keyboard firmware
« Reply #1171 on: Fri, 22 January 2016, 07:40:12 »
Thank you Hasu i will try with the Arduino as a learning experience.

If i may, when you say i should be able to improve the polling rate easily in TMK....May i know which file i should look into to do that?

Cheers.
Sharing the knowledge

Offline Koren

  • Posts: 133
  • Location: France
Re: TMK keyboard firmware
« Reply #1172 on: Fri, 22 January 2016, 14:26:51 »
If i may, when you say i should be able to improve the polling rate easily in TMK....May i know which file i should look into to do that?
I'm pretty sure that the firmware run "as fast as it can". But it performs a lot of things that you may not need. You can increase the pollrate either by optimizing the source code, or, more easily, by (carefully) removing features.

That being said, many switches need debounce, and I'm not sure the firmware will be the biggest hurdle to reach a 1000Hz polling rate.

Offline deductivemonkee

  • Posts: 572
  • Location: Canada BC
  • Professional Lurker
Re: TMK keyboard firmware
« Reply #1173 on: Sat, 23 January 2016, 13:38:12 »
Im trying to compile my .hex, but keep getting the error
Code: [Select]
In file included from keymap_plain.c:1:0:
keymap_common.h:23:21: fatal error: keycode.h: No such file or directory
 #include "keycode.h"
oh yeah I saw that crazy **** if that doesn't win I'm deleting my account

/ orthodox - 78g zealios / alps64 - mtsc / sentraq s-60x rgb - gat blues / let's split - 67g zealios / let's split - 67g zealios /

Offline Koren

  • Posts: 133
  • Location: France
Re: TMK keyboard firmware
« Reply #1174 on: Sat, 23 January 2016, 13:46:39 »
Im trying to compile my .hex, but keep getting the error
Code: [Select]
In file included from keymap_plain.c:1:0:
keymap_common.h:23:21: fatal error: keycode.h: No such file or directory
 #include "keycode.h"
Do you have a keycode.h file in the /common directory of the firmware source?

If so, it's a path issue, but it should be OK. How do you compile it? Make? Could you paste the last compilation command that failed? (probably a line beginning by avr-gcc a couple lines above the error)

Offline deductivemonkee

  • Posts: 572
  • Location: Canada BC
  • Professional Lurker
Re: TMK keyboard firmware
« Reply #1175 on: Sat, 23 January 2016, 13:49:48 »
Im trying to compile my .hex, but keep getting the error
Code: [Select]
In file included from keymap_plain.c:1:0:
keymap_common.h:23:21: fatal error: keycode.h: No such file or directory
 #include "keycode.h"
Do you have a keycode.h file in the /common directory of the firmware source?

If so, it's a path issue, but it should be OK. How do you compile it? Make? Could you paste the last compilation command that failed? (probably a line beginning by avr-gcc a couple lines above the error)

keycode.h is in the tmk_core/common file.
I compile it with cygwin terminal
Code: [Select]
mkdir -p obj_alps64
Compiling C: keymap_plain.c
avr-gcc -c -mmcu=atmega32u2 -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 -DVERSION= -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_alps64/keymap_plain.lst -I. -ID -I\KeyboardStuff\TMK\tmk_keyboard-master\tmk_core -ID -I\KeyboardStuff\TMK\tmk_keyboard-master\tmk_core/protocol/lufa -ID -I\KeyboardStuff\TMK\tmk_keyboard-master\tmk_core/protocol/lufa/LUFA-git -ID -I\KeyboardStuff\TMK\tmk_keyboard-master\tmk_core/common -std=gnu99 -include config.h -MMD -MP -MF .dep/obj_alps64_keymap_plain.o.d  keymap_plain.c -o obj_alps64/keymap_plain.o
In file included from keymap_plain.c:1:0:
keymap_common.h:23:21: fatal error: keycode.h: No such file or directory
 #include "keycode.h"
« Last Edit: Sat, 23 January 2016, 14:00:05 by Deductivemonkee »
oh yeah I saw that crazy **** if that doesn't win I'm deleting my account

/ orthodox - 78g zealios / alps64 - mtsc / sentraq s-60x rgb - gat blues / let's split - 67g zealios / let's split - 67g zealios /

Offline Koren

  • Posts: 133
  • Location: France
Re: TMK keyboard firmware
« Reply #1176 on: Sat, 23 January 2016, 14:25:19 »
keycode.h is in the tmk_core/common file.
Seems OK. You can check that it's readable and the directory has execute and read permissions, but I doubt that's the issue.

It seems that path includes are there, but

-I\KeyboardStuff\TMK\tmk_keyboard-master\tmk_core/common

is a bit strange. When I compile it under cygwin, I only have slashes (/) in paths, not backslashes. And beginning with a / would be strange, too... is KeyboardStuff a directory in your root cygwin directory?

How did you generate your makefile? The problem probably lies there...

Offline deductivemonkee

  • Posts: 572
  • Location: Canada BC
  • Professional Lurker
Re: TMK keyboard firmware
« Reply #1177 on: Sat, 23 January 2016, 14:28:43 »
keycode.h is in the tmk_core/common file.
Seems OK. You can check that it's readable and the directory has execute and read permissions, but I doubt that's the issue.

It seems that path includes are there, but

-I\KeyboardStuff\TMK\tmk_keyboard-master\tmk_core/common

is a bit strange. When I compile it under cygwin, I only have slashes (/) in paths, not backslashes. And beginning with a / would be strange, too... is KeyboardStuff a directory in your root cygwin directory?

How did you generate your makefile? The problem probably lies there...

i fixed the slashes, my makefile was the one in the alps64 dir, thats what board its for. KeyboardStuff is in my D: drive
oh yeah I saw that crazy **** if that doesn't win I'm deleting my account

/ orthodox - 78g zealios / alps64 - mtsc / sentraq s-60x rgb - gat blues / let's split - 67g zealios / let's split - 67g zealios /

Offline Koren

  • Posts: 133
  • Location: France
Re: TMK keyboard firmware
« Reply #1178 on: Sat, 23 January 2016, 14:49:29 »
i fixed the slashes
And? Any change?

my makefile was the one in the alps64 dir, thats what board its for.
Often, projects don't come with a makefile... because the makefile will be slightly different depending on which compiler/tools you use. But I don't see a configure file, and I don't remember how I generated my own Makefile. :/

KeyboardStuff is in my D: drive
I'd suggest you to use relative paths if you modify your makefile by hand, or /cygdrive/d/... I don't remember Cygwin being able to refer to disks by their name, but I may be wrong.

Offline deductivemonkee

  • Posts: 572
  • Location: Canada BC
  • Professional Lurker
Re: TMK keyboard firmware
« Reply #1179 on: Sat, 23 January 2016, 14:58:40 »
i fixed the slashes
And? Any change?

my makefile was the one in the alps64 dir, thats what board its for.
Often, projects don't come with a makefile... because the makefile will be slightly different depending on which compiler/tools you use. But I don't see a configure file, and I don't remember how I generated my own Makefile. :/

KeyboardStuff is in my D: drive
I'd suggest you to use relative paths if you modify your makefile by hand, or /cygdrive/d/... I don't remember Cygwin being able to refer to disks by their name, but I may be wrong.

It recognizes keycode.h now.
Now it's just errors like 64 arguments needed, only 61 given.
Will post later.
« Last Edit: Sat, 23 January 2016, 17:42:25 by Deductivemonkee »
oh yeah I saw that crazy **** if that doesn't win I'm deleting my account

/ orthodox - 78g zealios / alps64 - mtsc / sentraq s-60x rgb - gat blues / let's split - 67g zealios / let's split - 67g zealios /

Offline Koren

  • Posts: 133
  • Location: France
Re: TMK keyboard firmware
« Reply #1180 on: Sat, 23 January 2016, 15:07:19 »
It recognizes keycode.h now.
Now it's just errors like 64 arguments needed, only 61 given.
Will post when done lunch.
Most probably missing commas in your keyboard layout definition (check the end of lines, especially)

Offline Kaibz

  • Posts: 48
  • Location: AFK but not too much
Re: TMK keyboard firmware
« Reply #1181 on: Sun, 24 January 2016, 07:29:50 »

I'm pretty sure that the firmware run "as fast as it can". But it performs a lot of things that you may not need. You can increase the pollrate either by optimizing the source code, or, more easily, by (carefully) removing features.

That being said, many switches need debounce, and I'm not sure the firmware will be the biggest hurdle to reach a 1000Hz polling rate.

Thank you Sir.

Does that mean that using hardware debouncing, instead of software, would/could make the polling rate "faster"?
Also is the actual microcontroler speed tied in some ways to the polling rate?
Sorry if these questions sound stupid but i just want to be sure.
Sharing the knowledge

Offline Koren

  • Posts: 133
  • Location: France
Re: TMK keyboard firmware
« Reply #1182 on: Sun, 24 January 2016, 07:59:56 »
Does that mean that using hardware debouncing, instead of software, would/could make the polling rate "faster"?
What I mean is that, if you want to have 1000Hz polling, you need to be able to distinguish

4.900 Key Down
5.000 Key Up
5.001 Key Down
5.002 Key Up

from

4.900 Key Down
5.000 Key Up
5.001 Bounce down
5.002 Bounce up

Hasu did some tests on, e.g. Cherry Blacks, and got this (granted, that was apparently the worst case):


Official MX documentation suggest a 5ms debounce, so you shouldn't be able to reach 1000Hz with cherries (at least, in theory... 5ms may be quite a lot, and you may prefer having 1000Hz and a couple of ghost presses)


I'm curious, though: how do you intend to do "hardware debounce"? Most debouncing solutions, electronics or software, induce a latency. I doubt you'll want adding to much latency when you aim for a really high polling rate if you're into gaming... A high polling rate keyboard should probably use very specific switches with reliable, non-bouncing hardware. I have no idea if Alps are great for this or not.


About debouncing and rate, you should look into the matrix.c file in your alp64 directory... The debouncing stuff is usually on a per-board basis, since not all keyboards need the same timings. By default, the debouncing is set to about 5ms, apparently, which will prevent you from going close to 1000Hz (assuming you *could* go close to 1000Hz).

Also is the actual microcontroler speed tied in some ways to the polling rate?
In some cases, yes...

The software will read the state of the keys, do something depending on the changes of thoses states, send a report to the computer, and start again. The longest it take to do the polling and the computations, the lower the rate of the reports. And slower microcontroller will take longer to do the polling and the computations afterwards.

But at the same time, with high-speed microcontrollers, the physical parts will become the ones limiting the polling rate.

Sorry if these questions sound stupid but i just want to be sure.
They're not stupid, I just hope I'm not wrong myself, and I'm not even sure whether I haven't missed a sleeping function somewhere in the TMK firmware (besides anything in matrix.c). There's interesting tweaks that can be done to the debouncing part if you want, too.

Offline flabbergast

  • Posts: 234
  • Location: UK
Re: TMK keyboard firmware
« Reply #1183 on: Sun, 24 January 2016, 12:14:29 »
I think AVRs at 16MHz run fast enough so that the main delays occur at debouncing (5ms default, configurable), and waiting for PC to initiate an USB transaction (so that the information about the pressed keys, aka "report" gets transmitted to the computer) - this is 1ms worst case I think.

I personally think that marketing departments of keyboard-making companies go for the "1000Hz - hype" just because this is the limit set by the USB HID protocol (a report can be transmitted every 1ms but not more often).

By the way, what does "1000Hz polling rate" actually mean? if there are no keypresses I'd wager that TMK (and every other custom firmware) polls even more often than 1000 times per second. But once a keypress occurs, it takes 5ms to debounce. If Cherry datasheet specifies 5ms debounce time, a hardware debounce solution would have to be built around this number anyway, so you wouldn't get any advantage over the software solution - a keypress would simply register with the firmware 5ms after the key was really pressed.

Marketing is pretty good these days... I still have to see one instance where an improvement of a few ms for registering keypresses makes any difference whatsoever.

Offline Koren

  • Posts: 133
  • Location: France
Re: TMK keyboard firmware
« Reply #1184 on: Sun, 24 January 2016, 14:52:49 »
I think AVRs at 16MHz run fast enough so that the main delays occur at debouncing (5ms default, configurable), and waiting for PC to initiate an USB transaction (so that the information about the pressed keys, aka "report" gets transmitted to the computer)
I think so, indeed. Although if you try to do complex things with the keypresses, I think you could be limited by the AVR speed. I've yet to do tests to backup this claim, though, it's just coming from some experiences with AVR microcontrollers used for other things than keyboards. It's never fast enough ^_^

By the way, what does "1000Hz polling rate" actually mean?
If you talk about what it SHOULD mean, I'd say it's "no more than 1ms lag induced by the device". I doubt that it's always the actual behavior of products displaying it, though... Marketing, as you say...

if there are no keypresses I'd wager that TMK (and every other custom firmware) polls even more often than 1000 times per second.
Probably, but not by much. First, you need to wait a couple dozen microseconds after selecting the row to be able to read the columns. So there's probably a third of millisecond waiting, and after that quite a lot of things to do to transform the bits into keypressed. If it's over 1000Hz, it's not by much.

But once a keypress occurs, it takes 5ms to debounce. If Cherry datasheet specifies 5ms debounce time, a hardware debounce solution would have to be built around this number anyway, so you wouldn't get any advantage over the software solution - a keypress would simply register with the firmware 5ms after the key was really pressed.
That's my understanding, indeed. So I think that any claim over 200Hz will be misleading.

Offline flabbergast

  • Posts: 234
  • Location: UK
Re: TMK keyboard firmware
« Reply #1185 on: Sun, 24 January 2016, 17:34:25 »
Probably, but not by much. First, you need to wait a couple dozen microseconds after selecting the row to be able to read the columns. So there's probably a third of millisecond waiting, and after that quite a lot of things to do to transform the bits into keypressed. If it's over 1000Hz, it's not by much.
I've run a quick grep over TMK sources: the settling wait is 30 microseconds max (I think this is a safe baseline for hasu), but a lot of keyboards have 1-3 microseconds.

Offline ctm

  • Posts: 424
  • Location: Seattle, WA
  • Hello, world!
Re: TMK keyboard firmware
« Reply #1186 on: Sun, 24 January 2016, 17:45:33 »
Is there any chance that we can get TMK on Ellipse's Model F keyboards?
TMK Alps64 w/ Matias Quiet Switches in KBP V60 case.
Infinity60 with SKCM Orange Switches w/ TMK.
CM Storm QRF w/ Frosty Flake controller, Cherry MX Blue Switches and TMK firmware.


Coming:
Ellipse Model F F62.

Offline Kaibz

  • Posts: 48
  • Location: AFK but not too much
Re: TMK keyboard firmware
« Reply #1187 on: Sun, 24 January 2016, 19:23:57 »
@Koren

Thanks again for your answers. I have a lot of things to learn in the debouncing department, i spent most of my day reading about it.
About hardware debouncing, i talked about it because this person is doing it on her project:

http://dawnmist.dreamwidth.org/2553.html

But she didn't tell me exactly how she implemented it, but she was still very helpful.


@flabbergast

You said "I still have to see one instance where an improvement of a few ms for registering keypresses makes any difference whatsoever" and honestly i'm pretty sure you are right, however generally gaming company do not advertize about keyboard polling rate, it's just that one day, i read this article:

http://tech.firstpost.com/news-analysis/gaming-keyboards-demystified-40081.html

This guy actually explains "technically" why a 1000hz polling rate makes a difference, and to be honest i would very much like to know what you think about what he says and if you think he has a point or not ?

Sharing the knowledge

Offline flabbergast

  • Posts: 234
  • Location: UK
Re: TMK keyboard firmware
« Reply #1188 on: Mon, 25 January 2016, 03:50:42 »
@flabbergast

You said "I still have to see one instance where an improvement of a few ms for registering keypresses makes any difference whatsoever" and honestly i'm pretty sure you are right, however generally gaming company do not advertize about keyboard polling rate, it's just that one day, i read this article:

http://tech.firstpost.com/news-analysis/gaming-keyboards-demystified-40081.html

This guy actually explains "technically" why a 1000hz polling rate makes a difference, and to be honest i would very much like to know what you think about what he says and if you think he has a point or not ?
This article explains things pretty well (although it is visibly biased towards mechs, just to mention one instance - the actuation distance on rubber domes is not necessarily that big as he writes - it is about 2mm on apple keyboards).

With that author's definition of 1000Hz polling rate, TMK performs well (as I wrote above). But the example with Super Meat Boy he gives is nonsense in my opinion. 2000 pixels per second? That's just shy of twice the width of my screen. Per second. For platformers like this you train to react "before" stuff actually happens. Now the average human reaction time is 250ms (from googling), so whether you "train to react" 251ms before an event or 255ms before an event doesn't make much of a difference. Any game where you play "against the computer" is tuned so that a normal person with a common keyboard can play it; then it's a matter of training.

I think there can be a point made for FPS - but again, I have yet to see a case where 1ms vs 5ms will make a difference.

Offline Kaibz

  • Posts: 48
  • Location: AFK but not too much
Re: TMK keyboard firmware
« Reply #1189 on: Mon, 25 January 2016, 06:26:43 »
Very nice flabbergast thanks for your observations !

Just to make sure i understand correctly, when mouse manufacturers talk about 1000hz polling rate mouse, is it the same "marketing talk" as keyboard for you ?

On a different subject, i do use NKRO on my TMK powered keyboard, is there a trick to make it enabled by default instead of having to enter the keys combination to enable it every time it's turned on?
Sharing the knowledge

Offline Koren

  • Posts: 133
  • Location: France
Re: TMK keyboard firmware
« Reply #1190 on: Mon, 25 January 2016, 08:39:45 »
About hardware debouncing, i talked about it because this person is doing it on her project:
I'd like to know what she's doing...

You said "I still have to see one instance where an improvement of a few ms for registering keypresses makes any difference whatsoever" and honestly i'm pretty sure you are right, however generally gaming company do not advertize about keyboard polling rate, it's just that one day, i read this article:
When I read "I've seen differences", I'd like to see a (double) blind test. There's plently of people saying they hear a big difference when you put marbles, travel clocks in the room. Placebo can be pretty huge.

And compared to what? A keyboard with a 5ms lag or one with a 15ms one? In the second case, it can be noticable (and sometimes bothering).

I agree with Flabbergast, I'm not convinced. I'd be curious to know whether SMB actually read the keyboard at 1000Hz itself, btw (or do I read 500Hz between the lines? Not sure, and I can't find developpers words on this).

I'm really really sensitive about input lag, especially on monitors (can't stand more than 20ms because I begin to notice the delay on very specific games like video golf), but yes, human brain can train itself to correct a couple ms lag pretty easily in a platforming game, even a fast one.

Also, there's usually more than 1ms difference of input lag between the upper part and the lower part of the screen, if 1ms was really a problem, you'd see other problems arise.


He has a point, though, in the fact that even if you need a debounce of 5ms, you could still have a 1ms lag for isolated keypressed (assuming the firmware optimize it this way, which is not the default behavior).

Offline flabbergast

  • Posts: 234
  • Location: UK
Re: TMK keyboard firmware
« Reply #1191 on: Mon, 25 January 2016, 13:19:47 »
Just to make sure i understand correctly, when mouse manufacturers talk about 1000hz polling rate mouse, is it the same "marketing talk" as keyboard for you ?

On a different subject, i do use NKRO on my TMK powered keyboard, is there a trick to make it enabled by default instead of having to enter the keys combination to enable it every time it's turned on?
Sorry, I didn't want to start another flamewar (although it is very civil, so perhaps a "candlewar" ;)
With mice there's one crucial difference - when you move the mouse, you're sampling a continuous curve, and so you want to sample it as densely as possible. With keypresses, it's "discrete" on/off, the question is only about the delay between actuation and PC registering it. Although also with mice I don't know when does the sampling become smooth enough so that a human can't tell the difference.

We're moving away from technical points, so I'd like to just concede some points: while there's no hard evidence that high polling rates improve (say) gaming performance or make any other practical difference, they are technically better. Other things being equal, I would go for a keyboard with a higher polling rate.
{I think the subjective feeling of having a better/more personally comfortable keyboard makes a big difference in gaming (or in general - people who feel better just perform better).}

With NKRO enable/boot magic key: the setting is automatically saved in EEPROM. So when you press the magic NKRO_enable key  during power-up, you are actually toggling the NKRO setting; and this is remembered by the MCU even if you re-plug the keyboard.
« Last Edit: Mon, 25 January 2016, 13:26:53 by flabbergast »

Offline Prelim

  • Posts: 649
  • Location: Portugal
Re: TMK keyboard firmware
« Reply #1192 on: Mon, 25 January 2016, 14:21:59 »
With NKRO enable/boot magic key: the setting is automatically saved in EEPROM. So when you press the magic NKRO_enable key  during power-up, you are actually toggling the NKRO setting; and this is remembered by the MCU even if you re-plug the keyboard.

Hi!

I've tried to press LShift+RShift+N and then plug again the keyboard cable, but I'm getting always 6NKRO only. If I press again the magic combination for NKRO, it turn nkro on but it doesn't save :( Am I doing something wrong?
2x GH60 revC - lubed Linjärs 65g / lubed H1s 65g with SPRIT 5mm acrylic plate | Dolch PAC - Cherry housing / Gateron sliders 65g and QMK clips | Raptor K1 G80-1890 stock 
Floating on Cherry/GMK caps - White on Black, Classic Beige, Dolch, Olivetti, Alcatel MMK, Hellgrau

Offline a-c

  • Posts: 196
  • Location: USA
Re: TMK keyboard firmware
« Reply #1193 on: Mon, 25 January 2016, 15:58:40 »
Bootmagic key is different. It is usually the spacebar.

spacebar + n and plug in USB

Offline Prelim

  • Posts: 649
  • Location: Portugal
Re: TMK keyboard firmware
« Reply #1194 on: Mon, 25 January 2016, 16:21:45 »
thanks for the help, but that's not working also.

The NKRO is saved when computer reboots, but once I unplug and plug keyboard again it reverts to 6KRO :/
2x GH60 revC - lubed Linjärs 65g / lubed H1s 65g with SPRIT 5mm acrylic plate | Dolch PAC - Cherry housing / Gateron sliders 65g and QMK clips | Raptor K1 G80-1890 stock 
Floating on Cherry/GMK caps - White on Black, Classic Beige, Dolch, Olivetti, Alcatel MMK, Hellgrau

Offline flabbergast

  • Posts: 234
  • Location: UK
Re: TMK keyboard firmware
« Reply #1195 on: Mon, 25 January 2016, 17:18:45 »
thanks for the help, but that's not working also.

The NKRO is saved when computer reboots, but once I unplug and plug keyboard again it reverts to 6KRO :/
Hm. My post was based on reading hasu's code, but now I found it also on the wiki: https://github.com/tmk/tmk_keyboard/wiki/FAQ#nkro-doesnt-work
The behaviour you describe is weird. What MCU are you on? Did you compile TMK yourself? I suppose BOOTMAGIC_ENABLE and NKRO_ENABLE are both 'yes' because otherwise you wouldn't be able to switch NKRO with 'spacebar+N' during power-up.

Offline Prelim

  • Posts: 649
  • Location: Portugal
Re: TMK keyboard firmware
« Reply #1196 on: Mon, 25 January 2016, 17:39:54 »
I'm using a GH60 rev.C and didn't compile myself, I'm using TMK Keymap Generator and flashing over TKG toolkit: www.enjoyclick.org/tkg/
2x GH60 revC - lubed Linjärs 65g / lubed H1s 65g with SPRIT 5mm acrylic plate | Dolch PAC - Cherry housing / Gateron sliders 65g and QMK clips | Raptor K1 G80-1890 stock 
Floating on Cherry/GMK caps - White on Black, Classic Beige, Dolch, Olivetti, Alcatel MMK, Hellgrau

Offline Hzza

  • Posts: 377
  • Location: Windsor, UK
Re: TMK keyboard firmware
« Reply #1197 on: Tue, 26 January 2016, 07:51:51 »
Oh, I set magic key to be left shift+right shift+right control (I kept triggering it when it was set to both shifts), try holding all three and then pressing N.

I've never needed NKRO so I don't have it on by default, if you want I can do you a version with it enabled on boot.
« Last Edit: Tue, 26 January 2016, 08:04:03 by Hzza »

Offline flabbergast

  • Posts: 234
  • Location: UK
Re: TMK keyboard firmware
« Reply #1198 on: Tue, 26 January 2016, 09:21:40 »
I can't really tell why the bootmagic won't work properly. There's a very small chance that Kai Ryu has made some change to TMK that prevents this, but it is not very likely. If Hzza would kindly provide a firmware that works for him, it would be great for testing... (I don't have a GH60 to test.)

Offline e_l_tang

  • Posts: 260
Re: TMK keyboard firmware
« Reply #1199 on: Sat, 30 January 2016, 02:24:30 »
Has anyone gotten TMK to work on an ARM processor yet?