Author Topic: TMK keyboard firmware  (Read 884583 times)

0 Members and 1 Guest are viewing this topic.

Offline p3lim

  • Posts: 106
  • Location: Norway
Re: TMK keyboard firmware
« Reply #1200 on: Sat, 30 January 2016, 07:24:28 »
Has anyone gotten TMK to work on an ARM processor yet?

TMK has support for Cortex-M, the infinity keyboard uses a Cortex-M4 MCU: https://github.com/tmk/tmk_keyboard/tree/master/keyboard/infinity

Offline pwnz

  • Posts: 8
  • Location: Germany
Re: TMK keyboard firmware
« Reply #1201 on: Thu, 04 February 2016, 07:49:53 »
Hi,

I'm having some trouble mapping my keys. I wired a custom 60%-keyboard that's absolutely standard German ISO. I mapped all the ISO keys to their US-ANSI counterpart and simply switched the Windows input language. This works perfectly fine except for the freakin' "double bracket" key that has no counterpart in US-ANSI. I just get two keys that give me backslashes since that's what they do if I switch my OS input language with any other keyboard.

It's the key right to the left shift btw. What do I put in the array there?

Thanks for your help. 

Code: [Select]
const uint8_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
    /* 0: default */
    KEYMAP(
        ESC, 1,   2,   3,   4,   5,   6,   7,   8,   9,   0,   MINS,EQL, BSPC, \
        TAB, Q,   W,   E,   R,   T,   Y,   U,   I,   O,   P,   LBRC,RBRC,ENT, \
        FN0, A,   S,   D,   F,   G,   H,   J,   K,   L,   SCLN,QUOT,BSLS,      \
        LSFT,BSLS,Z,   X,   C,   V,   B,   N,   M,   COMM,DOT, SLSH,RSFT,      \
        LCTL,LGUI,LALT,          SPC,                     RALT, RGUI,FN1, RCTL),
    /* 1: fn */
    KEYMAP(
        GRV, F1,  F2,  F3,  F4,  F5,  F6,  F7,  F8,  F9,  F10, F11, F12, TRNS, \
        TRNS,HOME,UP,  END, TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS, \
        TRNS,LEFT,DOWN,RGHT,DEL, TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,      \
        TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,      \
        TRNS,TRNS,TRNS,          TRNS,                     TRNS,TRNS,TRNS,TRNS),
};
const uint16_t PROGMEM fn_actions[] = {
    /* Poker Layout */
    [0] = ACTION_LAYER_MOMENTARY(1),  // to Fn overlay
    [1] = ACTION_LAYER_TOGGLE(1),     // toggle Fn overlay
};

Offline nephiel

  • Posts: 129
  • Location: Spain
Re: TMK keyboard firmware
« Reply #1202 on: Thu, 04 February 2016, 07:59:46 »
Try NUBS, it's what I have on my ISO there.

Edit: and NUHS for the other slash. Like this:

Code: [Select]
...
    KEYMAP(
        ESC, 1,   2,   3,   4,   5,   6,   7,   8,   9,   0,   MINS,EQL, BSPC, \
        TAB, Q,   W,   E,   R,   T,   Y,   U,   I,   O,   P,   LBRC,RBRC,ENT, \
        FN0, A,   S,   D,   F,   G,   H,   J,   K,   L,   SCLN,QUOT,NUHS,      \
        LSFT,NUBS,Z,   X,   C,   V,   B,   N,   M,   COMM,DOT, SLSH,RSFT,      \
        LCTL,LGUI,LALT,          SPC,                     RALT, RGUI,FN1, RCTL),
...
« Last Edit: Thu, 04 February 2016, 08:03:54 by nephiel »
Stop wasting space! Chop your spacebar into bits!
NPH60: a custom 60% w/TrackPoint & split spacebar

Offline Liocer

  • Posts: 122
  • Location: London, UK
Re: TMK keyboard firmware
« Reply #1203 on: Thu, 04 February 2016, 19:01:10 »
I've built flashed and worked with Jacks fork of TMK on my Planck without too much issue. but...

I've just got hold of a Sparkfun Pro Micro that I wanted to use as a HHKB controller, now I get most of what's going on but the Sparkfun doesn't have a connected PB0 as it's used to signal the yellow LED on the board.

I'm struggling to work out the PIN addressing in hhkb_avr.h https://github.com/tmk/tmk_keyboard/blob/master/keyboard/hhkb/hhkb_avr.h maybe I can change the ports but I just don't get it. I had a look at Smasher's writeup here: https://geekhack.org/index.php?topic=57008.0 but the code for the ATMEGA32U4 is quite different to his changes.

I really want to understand how this works so I could make further changes if needed, if anyone has a link to something I could read that would be awesome :).

If I can just remap PB0 to say PF7 I should be okay.

Offline hasu

  • Thread Starter
  • Posts: 3484
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: TMK keyboard firmware
« Reply #1204 on: Fri, 05 February 2016, 00:55:34 »
You can read this to know how it works, but I'm not sure this is sufficient to understand.
https://github.com/tmk/tmk_keyboard/blob/master/keyboard/hhkb/doc/HHKB.txt

And see theese charts.
https://github.com/tmk/tmk_keyboard/blob/master/keyboard/hhkb/doc/HHKB_img/HHKB_chart1.jpg
https://github.com/tmk/tmk_keyboard/blob/master/keyboard/hhkb/doc/HHKB_img/HHKB_chart2.jpg

EDIT: hmm, I'm not sure I could understand your question correctly :D You can post 'HHKB alt controller specific' quesion here: https://geekhack.org/index.php?topic=12047.0

To use PF4-7 can be problematic in some cases, I don't recommend it. If you want to use it check datasheet to disable JTAG, iirc JTD register is related.
« Last Edit: Fri, 05 February 2016, 01:01:28 by hasu »

Offline Liocer

  • Posts: 122
  • Location: London, UK
Re: TMK keyboard firmware
« Reply #1205 on: Fri, 05 February 2016, 07:53:13 »
You can read this to know how it works, but I'm not sure this is sufficient to understand.
https://github.com/tmk/tmk_keyboard/blob/master/keyboard/hhkb/doc/HHKB.txt

And see theese charts.
https://github.com/tmk/tmk_keyboard/blob/master/keyboard/hhkb/doc/HHKB_img/HHKB_chart1.jpg
https://github.com/tmk/tmk_keyboard/blob/master/keyboard/hhkb/doc/HHKB_img/HHKB_chart2.jpg

EDIT: hmm, I'm not sure I could understand your question correctly :D You can post 'HHKB alt controller specific' quesion here: https://geekhack.org/index.php?topic=12047.0

To use PF4-7 can be problematic in some cases, I don't recommend it. If you want to use it check datasheet to disable JTAG, iirc JTD register is related.

Thanks Hasu, I'm gradually working this out, it doesn't matter to me which pins I use as replacements I guess I could avoid the JTAG pins entirely without too much issue.

Offline ctm

  • Posts: 424
  • Location: Seattle, WA
  • Hello, world!
Re: TMK keyboard firmware
« Reply #1206 on: Fri, 05 February 2016, 07:56:07 »
Any chance of porting TMK to xwhatsit controller?
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 Liocer

  • Posts: 122
  • Location: London, UK
Re: TMK keyboard firmware
« Reply #1207 on: Fri, 05 February 2016, 17:33:25 »
Okay so I've made some progress but I'm not 100% there yet..

So I've not worked with a Atmega32u4 before so this is all new to me, I don't really have any C experience either so I'm just trying to get this right :).

I went through your old matrix.c code and added some comments for myself.

Code: [Select]
#define KEY_INIT()              do {    \
    DDRB  = 0xFF;                       \ # Set all pins on PORTB to be inputs - setting PD0 LOW on the Pro Mega turns on the LED
    PORTB = 0x00;                       \ # set all PORTB pins to 0 LOW
    DDRD  &= ~0x80;                     \ # set PD1 to be output (0)
    PORTD |= 0x80;                      \ # Set PD1 high (1)
    /* keyswitch board power on */      \
    DDRD  |=  (1<<4);                   \ # Set PD4 to Input (1)
    PORTD |=  (1<<4);                   \ # Pull PD4 HIGH (1)
    KEY_UNABLE();                       \
    KEY_PREV_OFF();                     \
} while (0)

I notice when you're scanning you do so here:

Code: [Select]
static inline void KEY_SELECT(uint8_t ROW, uint8_t COL)
{
    PORTB = (PORTB & 0xC0) | (((COL) & 0x07)<<3) | ((ROW) & 0x07); // notation here is confusing me C0 scans first 2? PB0 and PB1? and then into a 07 (First 3) for both COLS and ROWS
#ifdef HHKB_JP
    if ((ROW) & 0x08) PORTC = (PORTC & ~(1<<6|1<<7)) | (1<<6);
    else              PORTC = (PORTC & ~(1<<6|1<<7)) | (1<<7);
#endif
}

There's no way I can hook up all 7 pins to one port on this board without soldering directly to the Atmega which I'm not doing :P so I will have to adopt at least one additional scan like your additional JP scan above, or have I misunderstood..

This probably not very clear, basically I'm asking you to explain KEY_SELECT above or at least let me know what I've gotten wrong :).

Pins I have available are, is there any other pins I should avoid?

PD0 PD1 PD2 PD3 PD4 PD7
PB1 PB2 PB3 PB4 PB5 PB6
PE6
PC6
PF4 PF5 PF6 PF7 (reserved for JTAG)

Offline hasu

  • Thread Starter
  • Posts: 3484
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: TMK keyboard firmware
« Reply #1208 on: Fri, 05 February 2016, 19:34:51 »
Any chance of porting TMK to xwhatsit controller?

Me? no, I don't have the controller. Donate it to TMK :D
You just need to place scan logic in matrix.c from xwhatsit's code and write keymap for your keyboard, me think.

Offline a-c

  • Posts: 196
  • Location: USA
Re: TMK keyboard firmware
« Reply #1209 on: Fri, 05 February 2016, 19:37:47 »
The TX/RX LEDS are B0 and D5. You can remove the LED and resistor to have a convenient tiny pad to solder to.

Just aware that the bootloader flashes these when loading firmware, otherwise they work fine for digital io.

You can see how they are wired in the schematic. http://cdn.sparkfun.com/datasheets/Dev/Arduino/Boards/Pro_Micro_v13b.pdf

Offline hasu

  • Thread Starter
  • Posts: 3484
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: TMK keyboard firmware
« Reply #1210 on: Fri, 05 February 2016, 20:15:17 »
Okay so I've made some progress but I'm not 100% there yet..

So I've not worked with a Atmega32u4 before so this is all new to me, I don't really have any C experience either so I'm just trying to get this right :).

I went through your old matrix.c code and added some comments for myself.

I think you have to check how to operate AVR IO ports with tutorial or datasheet again. When DDR bits are set to 1 corresponding ports are configured as output, while input when DDR is 0.

Code: [Select]
DDR PORT Pin state           
-----------------------------
1   0    Output Low         
1   1    Output Hi           
0   0    Input               
0   1    Input with pull-up

I can't explain AVR basics any more here, because it is off topic for subscribers of this thread.


Quote
There's no way I can hook up all 7 pins to one port on this board without soldering directly to the Atmega which I'm not doing :P so I will have to adopt at least one additional scan like your additional JP scan above, or have I misunderstood..
It is no problem, you can use simple C bit operation. I'm not sure what you mean by 'additional scan' but if you use HHKB pro/pro2 you don't need to read(scan) keys on additional rows.

Quote
This probably not very clear, basically I'm asking you to explain KEY_SELECT above or at least let me know what I've gotten wrong :).
KEY_SELECT selects a key on switch matrix to read its state(pressed/released) with given row and col arguments. In my configuration, you can select a row with PB0-2 and col with PB3-5, those pins control HC4051 and LS145.
https://github.com/tmk/tmk_keyboard/blob/master/keyboard/hhkb/doc/HHKB.txt#L41-L47

FYI, PB6,7 are retained without change here.
https://github.com/tmk/tmk_keyboard/blob/master/keyboard/hhkb/hhkb_avr.h#L82

EDIT: hmm, it is common idiom on C. You can take time to learn C more it will be very fruitive investment in the end.
Quote
    PORTB = (PORTB & 0xC0) | (((COL) & 0x07)<<3) | ((ROW) & 0x07); // notation here is confusing me C0 scans first 2? PB0 and PB1? and then into a 07 (First 3) for both COLS and ROWS

'(PORTB & 0xC0)` is used to keep bit7 and 6 from change during this operation. Again, C basics is off topic here though.
« Last Edit: Fri, 05 February 2016, 20:25:09 by hasu »

Offline Liocer

  • Posts: 122
  • Location: London, UK
Re: TMK keyboard firmware
« Reply #1211 on: Sat, 06 February 2016, 01:31:30 »
Once again thank you hasu I will stop poisoning your thread now

Offline e_l_tang

  • Posts: 260
Re: TMK keyboard firmware
« Reply #1212 on: Sun, 07 February 2016, 04:11:32 »
Hi everyone, I am fairly new to the world of mechanical keyboards and also to that of programming. I have a few miscellaneous questions:
  • I would think that in order to set the Magic key combination to be both Shift keys pressed together, it would have to be defined as "(keyboard_report->mods == (MOD_BIT(KC_LSHIFT) & MOD_BIT(KC_RSHIFT)))". However, it is defined differently as "(keyboard_report->mods == (MOD_BIT(KC_LSHIFT) | MOD_BIT(KC_RSHIFT)))". Why doesn't pressing either Shift key activate Magic?
  • What is the conditional statement that represents that no modifiers are being held? To clarify, I'm looking for something like "(keyboard_report->mods == (MOD_BIT(FALSE)))" or "(keyboard_report->mods != (MOD_BIT(TRUE)))".
  • Why does the macro at https://gist.github.com/Eric-L-T/09fd1423106119c65aa3 not work?

Any help is appreciated!
« Last Edit: Sun, 07 February 2016, 18:13:10 by Eric-T »

Offline Koren

  • Posts: 133
  • Location: France
Re: TMK keyboard firmware
« Reply #1213 on: Sun, 07 February 2016, 18:16:44 »
From memory (can't check the source now), so take this with a huge grain of salt before someone can confirm this...


I would think that in order to set the Magic key combination to be both Shift keys pressed together, it would have to be defined as "(keyboard_report->mods == (MOD_BIT(KC_LSHIFT) & MOD_BIT(KC_RSHIFT)))". However, it is defined differently as "(keyboard_report->mods == (MOD_BIT(KC_LSHIFT) | MOD_BIT(KC_RSHIFT)))". Why doesn't pressing either Shift key activate Magic?
Pretty sure mods is a set of bits corresponding to the state of modifiers, and MOD_BIT(KC...) corresponds to the single bit associated with the modifier.

E.g. :

left_shift is 0b00000001
right_shift is 0b00000010

To get both, you need a report that say 0b00000011

Which is 0b00000001 | 0b00000010

0b00000001 & 0b00000010 would be 0, so NO modifier...

  • What is the conditional statement that represents that no modifiers are being held? To clarify, I'm looking for something like "(keyboard_report->mods == (MOD_BIT(FALSE)))"
Probably simply == 0, for the same reason as above.



Not sure what you want to do exactly with your last question... Could you elaborate a bit?

Offline e_l_tang

  • Posts: 260
Re: TMK keyboard firmware
« Reply #1214 on: Sun, 07 February 2016, 18:47:34 »
Thank you for enlightening me. My first two questions just seem dumb now.

The macro in my third question was supposed to register a semicolon when tapped and a colon when double tapped, but it registered a semicolon no matter what.
« Last Edit: Sun, 07 February 2016, 18:49:16 by Eric-T »

Offline Koren

  • Posts: 133
  • Location: France
Re: TMK keyboard firmware
« Reply #1215 on: Sun, 07 February 2016, 19:14:51 »
The macro in my third question was supposed to register a semicolon when tapped and a colon when double tapped, but it registered a semicolon no matter what.
I see...

How exactly do you intend to recognize a single tap?

Because you need somethink like:

Key Down
(small time)
Key Up
(enough time to be sure there won't be a second tap)

The last part can be tricky, since you can't act either on a keydown or on a keyup... And you don't want to wait to the next key down either. I don't remember an event like a timer occuring some time after a key release (although I'm sure it could be done without too much hassle... you'd have to flush it before a different keypress, though).


I'd suggest you an alternative, though, that may suits you depending on what you're after, and could be easier to implement:
- on keydown, register a colon
- on keydown after a tap on the same key, register a backspace then a semicolon

This way, the key will work normally as a colon, but tap + press or double tap will replace the colon with a semicolon.

You won't be able to use it in a game that expect a semicolon, but if you want to use it to type text or code, I think it's a valid solution that avoids creating a timer event and dealing with the related issues...

Offline e_l_tang

  • Posts: 260
Re: TMK keyboard firmware
« Reply #1216 on: Sun, 07 February 2016, 20:24:57 »
This seems a little too complex for me to wrap my head around, so I'll drop this idea for now and revisit it later. Thanks for all your help.

Offline pwnz

  • Posts: 8
  • Location: Germany
Re: TMK keyboard firmware
« Reply #1217 on: Mon, 08 February 2016, 01:41:08 »
Thanks man, this worked!

Try NUBS, it's what I have on my ISO there.

Edit: and NUHS for the other slash. Like this:

Code: [Select]
...
    KEYMAP(
        ESC, 1,   2,   3,   4,   5,   6,   7,   8,   9,   0,   MINS,EQL, BSPC, \
        TAB, Q,   W,   E,   R,   T,   Y,   U,   I,   O,   P,   LBRC,RBRC,ENT, \
        FN0, A,   S,   D,   F,   G,   H,   J,   K,   L,   SCLN,QUOT,NUHS,      \
        LSFT,NUBS,Z,   X,   C,   V,   B,   N,   M,   COMM,DOT, SLSH,RSFT,      \
        LCTL,LGUI,LALT,          SPC,                     RALT, RGUI,FN1, RCTL),
...

Offline Liocer

  • Posts: 122
  • Location: London, UK
Re: TMK keyboard firmware
« Reply #1218 on: Mon, 08 February 2016, 03:05:14 »
The TX/RX LEDS are B0 and D5. You can remove the LED and resistor to have a convenient tiny pad to solder to.

Just aware that the bootloader flashes these when loading firmware, otherwise they work fine for digital io.

You can see how they are wired in the schematic. http://cdn.sparkfun.com/datasheets/Dev/Arduino/Boards/Pro_Micro_v13b.pdf

Thanks A-c, I got it working this weekend, desoldered the resistor from PB0 so I didn't have to change the scanning code, my soldering is better then my ;). I moved PB7 and PD4 to PD0 and PD1 respectively and all seemed to work fine. Typing on my modded hhkb now :D.

Offline dricher

  • Posts: 2
Re: TMK keyboard firmware
« Reply #1219 on: Wed, 10 February 2016, 21:47:26 »
Hey guys,

I have tried to figure it out on my own but I just can't! I have recently build myself a right handed gamepad for work. Everything works even backlights!

My problem is that backlights are WAY to strong. I could probably light the moon with it! I just can't seem to figure out how to ajust the brightness. I have tried to use the backlight_increase or backlight_decrease event backlight_step but nothing works.

My LEDs are connected to PB5, PB6 and PD7 (they are all PWM ports).

Thanks!

Offline skullydazed

  • * Vendor
  • Posts: 307
  • Location: Bay Area, CA
  • Had to turn PM's off. Email info@clueboard.co!
    • Clueboard
Re: TMK keyboard firmware
« Reply #1220 on: Wed, 10 February 2016, 22:39:48 »
Hey guys,

I have tried to figure it out on my own but I just can't! I have recently build myself a right handed gamepad for work. Everything works even backlights!

My problem is that backlights are WAY to strong. I could probably light the moon with it! I just can't seem to figure out how to ajust the brightness. I have tried to use the backlight_increase or backlight_decrease event backlight_step but nothing works.

My LEDs are connected to PB5, PB6 and PD7 (they are all PWM ports).

Thanks!

Have you setup your init_backlight_pin() and backlight_set() functions? If not take a look at what I put together for my backlit keypad here:

https://github.com/skullydazed/tmk_keyboard/blob/master/keyboard/cluepad/backlight.c

You can poke around the other files in that directory to see how I got it all integrated.

Offline e_l_tang

  • Posts: 260
Re: TMK keyboard firmware
« Reply #1221 on: Wed, 10 February 2016, 23:38:20 »
I have another question. What is the condition that checks whether or not a single bit of the modifier report is true? For example, how would I detect if left Shift being pressed while ignoring the states of all the other modifiers?

Edit: Alternatively, is there a way that I can link two keys together so that they act as one key?

Edit 2: I solved this problem with variables.

Edit 3: Still, does anyone know the answer to my first question? I would rather not use separate variables.
« Last Edit: Fri, 12 February 2016, 12:26:25 by Eric-T »

Offline obones

  • Posts: 7
  • Location: France
Re: TMK keyboard firmware
« Reply #1222 on: Thu, 11 February 2016, 10:18:34 »
In my setup, I have a function key that toggles NumLock and goes to a given layer.
I have assigned it FN1 and given these definitions:

Code: [Select]
   
[1] = ACTION_MACRO(NUM_LOCK),     // macro to press NumLock key then FN2
[2] = ACTION_LAYER_TOGGLE(2),     // to Numlock overlay

I have also written the following code:

Code: [Select]
const macro_t *action_get_macro(keyrecord_t *record, uint8_t id, uint8_t opt)
{
    switch (id) {
        case NUM_LOCK:
            return (record->event.pressed ?
                    MACRO( I(50), D(NUMLOCK), U(NUMLOCK), D(FN2), END ) :
                    MACRO( U(FN2), END ));
    }
    return MACRO_NONE;
}

However, I'm facing two issues:

1. When plugging the keyboard, there might be an initial state for NumLock from another plugged keyboard. How do I react to this?
2. While toggling the numlock status works, Switching to layer 2 does not seem to work with the macro. Is there another way to do it?

Regards

Offline e_l_tang

  • Posts: 260
Re: TMK keyboard firmware
« Reply #1223 on: Thu, 11 February 2016, 12:32:18 »
I am very new to programming myself, so pardon me if some of this code doesn't work.

To solve your first issue, try throwing this in your keymap file. I'm assuming that you want you keyboard to turn Num Lock off when you plug it in.
Code: [Select]
void * matrix_init_user(void) {
  if (host_keyboard_leds() & (1<<USB_LED_NUM_LOCK)) {
    register_code(KC_NLCK);
    unregister code(KC_NLCK);
  }
};

To solve your second issue, you need a macro each of the two layers you are switching between.
Code: [Select]
case NUM_LOCK_ON:
  if (record->event.pressed) {
    layer_on(2);
    register_code(KC_NLCK);
    unregister_code(KC_NLCK);
  }
break;
case NUM_LOCK_OFF:
  if (record->event.pressed) {
    register_code(KC_NLCK);
    unregister_code(KC_NLCK);
    layer_off(2);
  }
break;
« Last Edit: Thu, 11 February 2016, 13:42:32 by Eric-T »

Offline obones

  • Posts: 7
  • Location: France
Re: TMK keyboard firmware
« Reply #1224 on: Fri, 12 February 2016, 10:13:29 »
To solve your first issue, try throwing this in your keymap file. I'm assuming that you want you keyboard to turn Num Lock off when you plug it in.
Code: [Select]
void * matrix_init_user(void) {
  if (host_keyboard_leds() & (1<<USB_LED_NUM_LOCK)) {
    register_code(KC_NLCK);
    unregister code(KC_NLCK);
  }
};

I could not find any trace of matrix_init_user in TMK's source code, but I already had a matrix_init function in my matrix.c file.
However, the code above would not work because host_keyboard_leds is always returning 0 in that context as matrix_init is called by keyboard_init before the driver variable is set.
This is why I created the following pull request: https://github.com/tmk/tmk_keyboard/pull/307
It adds keyboard_startup/matrix_startup that are called when the driver variable is set.
But thanks for the pointers, it got me started.


To solve your second issue, you need a macro each of the two layers you are switching between.
Code: [Select]
case NUM_LOCK_ON:
  if (record->event.pressed) {
    layer_on(2);
    register_code(KC_NLCK);
    unregister_code(KC_NLCK);
  }
break;
case NUM_LOCK_OFF:
  if (record->event.pressed) {
    register_code(KC_NLCK);
    unregister_code(KC_NLCK);
    layer_off(2);
  }
break;

Ah yes, of course. I wasn't sure I could press keys from within a function but that's possible and will be much more reliable.
So in the end, I don't have any macro left, just two more branches in my function handling code.

Thanks for your help.

Offline e_l_tang

  • Posts: 260
Re: TMK keyboard firmware
« Reply #1225 on: Fri, 12 February 2016, 12:22:43 »
I got matrix_init_user from QMK, a branch of TMK. You can try to find it in QMK's repository at https://github.com/jackhumbert/qmk_firmware/.

What other user-defined functions do you have? I simply put all my custom stuff in action_get_macro.

Offline e_l_tang

  • Posts: 260
Re: TMK keyboard firmware
« Reply #1226 on: Fri, 12 February 2016, 15:44:38 »
So I am assuming that there is no way to check if a single bit in a modifier report is true?
« Last Edit: Fri, 12 February 2016, 15:56:00 by Eric-T »

Offline dricher

  • Posts: 2
Re: TMK keyboard firmware
« Reply #1227 on: Fri, 12 February 2016, 18:38:32 »
Hey guys,

I have tried to figure it out on my own but I just can't! I have recently build myself a right handed gamepad for work. Everything works even backlights!

My problem is that backlights are WAY to strong. I could probably light the moon with it! I just can't seem to figure out how to ajust the brightness. I have tried to use the backlight_increase or backlight_decrease event backlight_step but nothing works.

My LEDs are connected to PB5, PB6 and PD7 (they are all PWM ports).

Thanks!

Have you setup your init_backlight_pin() and backlight_set() functions? If not take a look at what I put together for my backlit keypad here:

https://github.com/skullydazed/tmk_keyboard/blob/master/keyboard/cluepad/backlight.c

You can poke around the other files in that directory to see how I got it all integrated.

Thanks a lot! that helped but when I add everything for PB5, PB6 and PD7, only PD7 works. If I remove everything regarding PD7, only PB6 works..... This is driving me nuts! here is my backlight.c

Code: [Select]
#include <avr/io.h>
#include "backlight.h"
#include "led.h"
#include "print.h"

int pwm_level;

void backlight_init_ports() {
    DDRD |= (1<<7);
    DDRB |= (1<<6) | (1<<5);
   
    // Initialize the timer
    TC4H = 0x03;
    //OCR4C = 0xFF;
    OCR4B = 0xFF;
    OCR4D = 0xFF;
    TCCR4A = 0b00100001;
    TCCR4B = 0b00000001;
    TCCR4C = 0b00001001;
    TCCR4D = 0b00000001;
    //TCCR4E = 0b00000100;
}

void backlight_set(uint8_t level)
{
    // Set as output.
    //DDRB |= (1<<6) | (1<<5);
    //DDRD |= (1<<7);
   
    // Determine the PWM level
    switch (level)
    {
        case 0:
            // 25%
            pwm_level = 0x40;
            break;
        case 1:
            // 66%
            pwm_level = 0x7F;
            break;
        case 2:
            // 66%
            pwm_level = 0xBF;
            break;
        case 3:
            // 100%
            pwm_level = 0xFF;
            break;
        case 4:
            // 0%
            pwm_level = 0x00;
            break;
        default:
            xprintf("Unknown level: %d\n", level);
    }
   
    // Write the PWM level to the timer
    TC4H = pwm_level >> 8;
    OCR4A = 0xFF & pwm_level;
    OCR4D = 0xFF & pwm_level;
    OCR4B = 0xFF & pwm_level;
    //OCR4C = 0xFF & pwm_level;

   
   
    //(level & BACKLIGHT_REAR) ? backlight_enable_rear() : backlight_disable_rear();

}
« Last Edit: Fri, 12 February 2016, 20:55:09 by dricher »

Offline hasu

  • Thread Starter
  • Posts: 3484
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: TMK keyboard firmware
« Reply #1228 on: Fri, 12 February 2016, 19:39:42 »
So I am assuming that there is no way to check if a single bit in a modifier report is true?
keyboard_report.mod has state of eight modifiers in 8bits, you can use it for your purpose.

its format looks look like this.
https://github.com/tmk/tmk_keyboard/blob/master/tmk_core/common/report.h#L118

you can check if left shift is depressed like this.

if (mods & (1<<1) ) { yes, depressed }

Offline e_l_tang

  • Posts: 260
Re: TMK keyboard firmware
« Reply #1229 on: Fri, 12 February 2016, 22:00:17 »
Thank you, hasu. Unfortunately, my new keymap file cannot compile; I am getting an error message saying that "mods" is undefined. Can you point me to the correct header file I need to include?
« Last Edit: Fri, 12 February 2016, 22:18:00 by Eric-T »

Offline hasu

  • Thread Starter
  • Posts: 3484
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: TMK keyboard firmware
« Reply #1230 on: Fri, 12 February 2016, 22:41:42 »
use keyboard_report.mods, which defined in action_util.h.

Offline e_l_tang

  • Posts: 260
Re: TMK keyboard firmware
« Reply #1231 on: Fri, 12 February 2016, 22:53:13 »
I already have that header file included in my keymap. Do you have any idea why things are not working?
« Last Edit: Fri, 12 February 2016, 22:57:24 by Eric-T »

Offline hasu

  • Thread Starter
  • Posts: 3484
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: TMK keyboard firmware
« Reply #1232 on: Fri, 12 February 2016, 22:56:45 »
perhaps qmk problem ?
are you sure using tmk?

Offline e_l_tang

  • Posts: 260
Re: TMK keyboard firmware
« Reply #1233 on: Fri, 12 February 2016, 23:00:41 »
I am indeed using QMK, but shouldn't these low-level things be the same?

Here is the header file in question.
Code: [Select]
/*
Copyright 2013 Jun Wako <wakojun@gmail.com>

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 2 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program.  If not, see <http://www.gnu.org/licenses/>.
*/
#ifndef ACTION_UTIL_H
#define ACTION_UTIL_H

#include <stdint.h>
#include "report.h"

#ifdef __cplusplus
extern "C" {
#endif

extern report_keyboard_t *keyboard_report;

void send_keyboard_report(void);

/* key */
void add_key(uint8_t key);
void del_key(uint8_t key);
void clear_keys(void);

/* modifier */
uint8_t get_mods(void);
void add_mods(uint8_t mods);
void del_mods(uint8_t mods);
void set_mods(uint8_t mods);
void clear_mods(void);

/* weak modifier */
uint8_t get_weak_mods(void);
void add_weak_mods(uint8_t mods);
void del_weak_mods(uint8_t mods);
void set_weak_mods(uint8_t mods);
void clear_weak_mods(void);

/* oneshot modifier */
void set_oneshot_mods(uint8_t mods);
void clear_oneshot_mods(void);
void oneshot_toggle(void);
void oneshot_enable(void);
void oneshot_disable(void);

/* inspect */
uint8_t has_anykey(void);
uint8_t has_anymod(void);
uint8_t get_first_key(void);

#ifdef __cplusplus
}
#endif

#endif
« Last Edit: Fri, 12 February 2016, 23:07:58 by Eric-T »

Offline hasu

  • Thread Starter
  • Posts: 3484
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: TMK keyboard firmware
« Reply #1234 on: Fri, 12 February 2016, 23:11:52 »
ah, . vs -> ?

Offline e_l_tang

  • Posts: 260
Re: TMK keyboard firmware
« Reply #1235 on: Fri, 12 February 2016, 23:17:50 »
What exactly should I be editing?

Edit: I misunderstood some of your previous comments. I edited my keymap file and everything is working perfectly now. Thank you so much for all your help.
« Last Edit: Fri, 12 February 2016, 23:28:46 by Eric-T »

Offline mveinot

  • Posts: 2
  • Location: Nova Scotia, Canada
Re: TMK keyboard firmware
« Reply #1236 on: Tue, 16 February 2016, 13:07:25 »
Greetings everyone. I'm a long time user of boards such as the Arduino, and recently ESP8266-based hardware. So hacking on this type of thing is not new to me. I'm a software developer and I use an IBM Model-M regularly on a 2012 Mac Mini (OS X 10.11).

I stumbled upon this project and had a spare Teensy 2.0 lying around from a previous project and thought it looked interesting and might offer some enhanced capabilities. I managed to wire up the teensy, compile and upload the code with no major issues and for the most part it's working perfectly.

My issue (which is an issue I've had with every PS/2->USB converter I've tried so far) is that if I perform a soft reboot of the Mac, upon starting again, keyboard input is ignored until I unplug the USB adapter and plug it back in. Is anyone here familiar with this issue. I'm not opposed to making changes to the code and testing it. Can anyone offer any insight on where I could look to attempt to resolve this issue? Or is there a more fundamental hardware issue at fault here?

Offline njbair

  • Posts: 2825
  • Location: Cleveland, Ohio
  • I love the Powerglove. It's so bad.
    • nickbair.net
Re: TMK keyboard firmware
« Reply #1237 on: Tue, 16 February 2016, 16:04:01 »
What's the officially recommended way to use tmk_core?

For instance, I have a bunch of devices running TMK: a Pegasus Hoof, multiple alps64 boards, a Planck (QMK but still), two Infinity boards, and a pair of USB-to-USB converters. I like to maintain my own TMK fork with all my custom layouts. Currently these are scattered across multiple forks, which is not ideal. I want to consolidate my personal stuff into a single subdirectory, and include TMK Core and the QMK fork as Git submodules in a separate top-level directory, like so:

Code: [Select]

.
|-- devices
|   |-- alps64
|   |-- infinity
|   |-- pegasus_hoof
|   |-- planck
|   `-- usb_usb_converter
`-- submodules
    |-- qmk
    `-- tmk_core


Alternatively, I could add another layer of organization to the devices folder:

Code: [Select]

.
|-- devices
|   |-- controller
|   |   `-- pegasus_hoof
|   |-- converter
|   |   `-- usb_usb
|   `-- keyboard
|       |-- alps64
|       |-- infinity
|       `-- planck
`-- submodules
    |-- qmk
    `-- tmk_core


hasu, I'm particularly curious to hear your thoughts on this idea, and whether or not you think there's a better way to do this. Others are also free to offer their input, of course. Thanks.

Alpine Winter GB | My Personal TMK Firmware Repo
IBM Rubber Band "Floss" Mod | Click Modding Alps 101 | Flame-Polishing Cherry MX Stems
Review: hasu's USB to USB converter
My boards:
More
AEKII 60% | Alps64 HHKB | Ducky Shine 3, MX Blues | IBM Model M #1391401, Nov. 1990 | IBM SSK #1391472, Nov. 1987, screw modded, rubber-band modded | Noppoo EC108-Pro, 45g | Infinity 60% v2 Hacker, Matias Quiet Pros | Infinity 60% v2 Standard, MX Browns | Cherry G80-1800LPCEU-2, MX Blacks | Cherry G80-1813 (Dolch), MX Blues | Unicomp M-122, ANSI-modded | Unicomp M-122 (Unsaver mod in progress) | 2x Unitek K-258, White Alps | Apple boards (IIGS, AEKII) | Varmilo VA87MR, Gateron Blacks | Filco Zero TKL, Fukka White Alps | Planck, Gateron Browns | Monarch, click-modded Cream Alps

Offline hasu

  • Thread Starter
  • Posts: 3484
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: TMK keyboard firmware
« Reply #1238 on: Tue, 16 February 2016, 18:17:05 »
Greetings everyone. I'm a long time user of boards such as the Arduino, and recently ESP8266-based hardware. So hacking on this type of thing is not new to me. I'm a software developer and I use an IBM Model-M regularly on a 2012 Mac Mini (OS X 10.11).

I stumbled upon this project and had a spare Teensy 2.0 lying around from a previous project and thought it looked interesting and might offer some enhanced capabilities. I managed to wire up the teensy, compile and upload the code with no major issues and for the most part it's working perfectly.

My issue (which is an issue I've had with every PS/2->USB converter I've tried so far) is that if I perform a soft reboot of the Mac, upon starting again, keyboard input is ignored until I unplug the USB adapter and plug it back in. Is anyone here familiar with this issue. I'm not opposed to making changes to the code and testing it. Can anyone offer any insight on where I could look to attempt to resolve this issue? Or is there a more fundamental hardware issue at fault here?

Capture packets using tool like wireshark both on fault device and working device and compare the logs?

Offline hasu

  • Thread Starter
  • Posts: 3484
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: TMK keyboard firmware
« Reply #1239 on: Tue, 16 February 2016, 19:32:40 »
What's the officially recommended way to use tmk_core?

For instance, I have a bunch of devices running TMK: a Pegasus Hoof, multiple alps64 boards, a Planck (QMK but still), two Infinity boards, and a pair of USB-to-USB converters. I like to maintain my own TMK fork with all my custom layouts. Currently these are scattered across multiple forks, which is not ideal. I want to consolidate my personal stuff into a single subdirectory, and include TMK Core and the QMK fork as Git submodules in a separate top-level directory, like so:

Code: [Select]

.
|-- devices
|   |-- alps64
|   |-- infinity
|   |-- pegasus_hoof
|   |-- planck
|   `-- usb_usb_converter
`-- submodules
    |-- qmk
    `-- tmk_core


Alternatively, I could add another layer of organization to the devices folder:

Code: [Select]

.
|-- devices
|   |-- controller
|   |   `-- pegasus_hoof
|   |-- converter
|   |   `-- usb_usb
|   `-- keyboard
|       |-- alps64
|       |-- infinity
|       `-- planck
`-- submodules
    |-- qmk
    `-- tmk_core


hasu, I'm particularly curious to hear your thoughts on this idea, and whether or not you think there's a better way to do this. Others are also free to offer their input, of course. Thanks.

No official recommendation for project file organization :D It completely depends on project owner's preference. Both file trees looks decent to me,

You can manage all projects(keyboard/converter/controller) in a git repo or can have a repo per project. Also you can clone, submodule or subtree tmk_core depending on your preference.

Offline e_l_tang

  • Posts: 260
Re: TMK keyboard firmware
« Reply #1240 on: Sat, 20 February 2016, 22:25:20 »
Is there a way to program the keyboard to return to layer 0 and turn off Caps Lock after, say, one minute of inactivity?
« Last Edit: Sun, 21 February 2016, 00:38:55 by Eric-T »

Offline Koren

  • Posts: 133
  • Location: France
Re: TMK keyboard firmware
« Reply #1241 on: Sun, 21 February 2016, 01:51:57 »
Is there a way to program the keyboard to return to layer 0 and turn off Caps Lock after, say, one minute of inactivity?
Yes (provided you're not to strict on the exact value of "one minute")

Here is how I would do it:
- open keyboard.c
- look for keyboard_task
- create a static integer variable, initialized at zero
- increment the variable somewhere, e.g. before the matrix_scan() call
- reset it to zero in the if (matrix_change) { ...
- at the end of the function, for example (after MATRIX_LOOP_END), check whether the variable reached a given value (e.g. 50000) and if so, do what you want after inactivity.

I'd strongly suggest the test at the end of the function just call a user function, something like void* inactivity_user(void), that you define for example in your keymap files rather than directly in the keyboard.c that should only contains user-independant code.

The value (50000) should also be defined by the user. You may be forced to use trial and error to know the value that will correspond to one minute, though (it's 60 times the scan rate when nothing happens)

Offline e_l_tang

  • Posts: 260
Re: TMK keyboard firmware
« Reply #1242 on: Sun, 21 February 2016, 12:54:30 »
Is there any way I could do this in my keymap file? I don't want my changes to be overwritten when I pull an update.

I think QMK might allow me to do this because the default ErgoDox keymap, which can be found at https://github.com/jackhumbert/qmk_firmware/blob/master/keyboard/ergodox_ez/keymaps/default/keymap.c, has a loop at the end to control the LEDs. I think I might be able to make a similar loop that does what I want.
« Last Edit: Sun, 21 February 2016, 13:04:26 by Eric-T »

Offline flabbergast

  • Posts: 234
  • Location: UK
Re: TMK keyboard firmware
« Reply #1243 on: Sun, 21 February 2016, 14:07:46 »
Normally you'd "fork" TMK (i.e. create another git branch) and maintain it. You can periodically 'merge' the master branch if you want to pull in the new code. Things won't get overwritten; git is pretty good at auto-merging but if the conflicts are too severe you'll need to decide manually by editing the files.

Offline e_l_tang

  • Posts: 260
Re: TMK keyboard firmware
« Reply #1244 on: Sun, 21 February 2016, 14:50:36 »
I have a cloned the QMK repository into a folder instead of forking it. Will pulling updates to the folder be any different?

Either way, I would still prefer to only change my keymap file. Do you have any ideas?

Offline flabbergast

  • Posts: 234
  • Location: UK
Re: TMK keyboard firmware
« Reply #1245 on: Sun, 21 February 2016, 15:02:54 »
Sorry, I don't think this can be done with the "normal" TMK by just editing the 'keyboard' files, at least not without some relatively ugly hacks. I mean that there are functions there which are called very often in matrix.c (e.g. matrix_scan) within which you can do a similar hook to what Koren described (basically a counter in that function, and you can also test there whether anything's been pressed).

Ad forking: cloning is fine; you now have your own repository which pulls the remote master branch into your local master branch. You can locally create your own branch ('git checkout -b myownsuperbranch') where you can commit, etc... and when you want to pull upstream changes, do 'git checkout master; git pull; git checkout myownsuperbranch; git merge master').
Just google 'git branching', there are a bunch of tutorials out there at various levels :)

Offline e_l_tang

  • Posts: 260
Re: TMK keyboard firmware
« Reply #1246 on: Sun, 21 February 2016, 15:07:55 »
I am not using TMK, but rather a fork of it called QMK. The name of the loop in the default keymap of the ErgoDox suggests that it's synchronized with the matrix scanning. Are you sure I can't appropriate that loop for my own purposes?

Thanks, I didn't know that.

Offline flabbergast

  • Posts: 234
  • Location: UK
Re: TMK keyboard firmware
« Reply #1247 on: Sun, 21 February 2016, 15:42:21 »
Yep, just had a look at QMK. It does have periodically called functions - you can use matrix_scan_user on ergodox_ez.

Offline e_l_tang

  • Posts: 260
Re: TMK keyboard firmware
« Reply #1248 on: Sun, 21 February 2016, 16:02:47 »
I actually tried to use matrix_scan_user first, but I failed. The instructions that Koren gave me gave me a good idea of what I was doing wrong, but they seem to rely a lot on the other stuff in keyboard.c. How would I use matrix_scan_user instead?

Edit: Apparently there is no way for it to detect keypresses because nothing is being fed to it.
« Last Edit: Sun, 21 February 2016, 21:40:43 by Eric-T »

Offline e_l_tang

  • Posts: 260
Re: TMK keyboard firmware
« Reply #1249 on: Sun, 21 February 2016, 21:43:22 »
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?
« Last Edit: Sun, 21 February 2016, 23:12:59 by Eric-T »