Author Topic: TMK keyboard firmware  (Read 488177 times)

0 Members and 1 Guest are viewing this topic.

Offline alaricljs

  • I be WOT'ing all day...
  • ** Moderator Emeritus
  • Posts: 3715
  • Location: NE US
Re: TMK keyboard firmware
« Reply #50 on: Thu, 11 July 2013, 07:44:18 »
This?

https://github.com/tmk/tmk_keyboard/blob/master/common/keycode.h
Code: [Select]
/* Keypad */
#define KC_P1 KC_KP_1
#define KC_P2 KC_KP_2
#define KC_P3 KC_KP_3
#define KC_P4 KC_KP_4
#define KC_P5 KC_KP_5
#define KC_P6 KC_KP_6
#define KC_P7 KC_KP_7
#define KC_P8 KC_KP_8
#define KC_P9 KC_KP_9
#define KC_P0 KC_KP_0
#define KC_PDOT KC_KP_DOT
#define KC_PCMM KC_KP_COMMA
#define KC_PSLS KC_KP_SLASH
#define KC_PAST KC_KP_ASTERISK
#define KC_PMNS KC_KP_MINUS
#define KC_PPLS KC_KP_PLUS
#define KC_PEQL KC_KP_EQUAL
#define KC_PENT KC_KP_ENTER
Filco w/ Imsto thick PBT
Ducky 1087XM PCB+Plate, w/ Matias "Quiet Click" spring-swapped w/ XM Greens

Offline damorgue

  • Posts: 1176
  • Location: Sweden
    • Personal portfolio
Re: TMK keyboard firmware
« Reply #51 on: Thu, 11 July 2013, 08:00:52 »

Offline hasu

  • Thread Starter
  • Posts: 2908
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: TMK keyboard firmware
« Reply #52 on: Thu, 11 July 2013, 08:17:24 »
I setup repository for my converter KiCad project.
https://github.com/tmk/keyboard_converter

« Last Edit: Thu, 11 July 2013, 08:18:59 by hasu »
TMK products:HHKB Alt  ⌨ConvertersAlps64FC660C AltFC980C Alt

Online Findecanor

  • Posts: 4204
  • Location: Stockholm, Sweden
  • On the outside looking in
Re: TMK keyboard firmware
« Reply #53 on: Thu, 11 July 2013, 21:16:42 »
A choice of mini-USB and micro-USB out. Nice!
Smoking is assault. I defend myself.
Daily driver: Phantom (Lubed Cherry MX Clear, Lasered Cherry PBT keycaps with Row A. Plastic "Frankencase". Custom firmware, Swedish layout)

Offline damorgue

  • Posts: 1176
  • Location: Sweden
    • Personal portfolio
Re: TMK keyboard firmware
« Reply #54 on: Fri, 12 July 2013, 09:59:45 »
I think I found another small bug
http://i.imgur.com/5lPPRFE.png
The default layout in 'keymap_iso.h' is not actually iso in the second layer. The first layer has the correct number of entries, but the second is a bit messed up. I first thought I had ghosting from a faulty diode. The same is true for' keymap_iso_150.h' by the way.

Edit: I get very dim leds until I change 'led.c' per a suggestion to:
Code: [Select]
void led_set(uint8_t usb_led)
{
    if (usb_led & (1<<USB_LED_CAPS_LOCK))
    {
        // Output high.
        DDRB |= (1<<6);
        DDRB |= (1<<6);
    }
    else
    {
        // Output low.
        DDRB &= ~(1<<6);
        DDRB &= ~(1<<6);
    }

    if (usb_led & (1<<USB_LED_SCROLL_LOCK))
    {
        // Output high.
        DDRB &= ~(1<<7);
        DDRB |= (1<<7);
    }
    else
    {
        // Output low.
        DDRB &= ~(1<<7);
        DDRB &= ~(1<<7);
    }
}
It doesn't make much sense to me, as there are a couple of duplicate lines there, but it works.
« Last Edit: Fri, 12 July 2013, 10:06:48 by damorgue »

Offline Wraul

  • Posts: 211
  • Location: Sweden
Re: TMK keyboard firmware
« Reply #55 on: Fri, 12 July 2013, 11:48:11 »
I think I found another small bug
http://i.imgur.com/5lPPRFE.png
The default layout in 'keymap_iso.h' is not actually iso in the second layer. The first layer has the correct number of entries, but the second is a bit messed up. I first thought I had ghosting from a faulty diode. The same is true for' keymap_iso_150.h' by the way.

Thank you for testing the ISO layout and finding these errors.
I have corrected the layout files and will send hasu a pull request soon.

Edit: I get very dim leds until I change 'led.c' per a suggestion to:

The leds are working perfectly fine here.

Just to check a few things.

You are using the latest version that looks like this?
Code: [Select]
void led_set(uint8_t usb_led)
{
    if (usb_led & (1<<USB_LED_CAPS_LOCK))
    {
        // Output high.
        DDRB |= (1<<6);
        PORTB |= (1<<6);
    }
    else
    {
        // Output low.
        DDRB &= ~(1<<6);
        PORTB &= ~(1<<6);
    }

    if (usb_led & (1<<USB_LED_SCROLL_LOCK))
    {
        // Output high.
        DDRB |= (1<<7);
        PORTB |= (1<<7);
    }
    else
    {
        // Output low.
        DDRB &= ~(1<<7);
        PORTB &= ~(1<<7);
    }
}

You have the LED_BRIGHTNESS in config.h set to a sufficiently large number? Max being 255.

You have soldered the leds in the correct direction?

Offline damorgue

  • Posts: 1176
  • Location: Sweden
    • Personal portfolio
Re: TMK keyboard firmware
« Reply #56 on: Fri, 12 July 2013, 12:11:53 »
You are using the latest version that looks like this?

Your code snippet works as well, so I must have been using an old led.c

Offline Wraul

  • Posts: 211
  • Location: Sweden
Re: TMK keyboard firmware
« Reply #57 on: Fri, 12 July 2013, 12:46:28 »
You are using the latest version that looks like this?

Your code snippet works as well, so I must have been using an old led.c

Sweet. Glad you got it working :D

Offline TD22057

  • Posts: 172
  • Location: Southern California
Re: TMK keyboard firmware
« Reply #58 on: Fri, 12 July 2013, 16:37:07 »
So I'm trying to understand the debouncing algorithm that's in most of the matrix.c files (they all seem pretty similar).  It it's not too much trouble, could someone explain it in words?  The cherry switch spec says the debounce time is ~5ms.  It seems like most of the keyboards are doing something like this:
Code: [Select]
- for each row
   - energize row
   - wait 3-30 ms
   - read columns

Shouldn't the wait time built in to the loops mean that there isn't really a need for the debounce code?  I'm guessing it's necessary and I'm just missing something...

Offline TD22057

  • Posts: 172
  • Location: Southern California
Re: TMK keyboard firmware
« Reply #59 on: Fri, 12 July 2013, 17:19:12 »
OK - I think I understand debouncing a little better now (maybe).  It's the activation count that's important - not so much the total delay in sampling.  It seems like it might be more robust to keep a debounce count or a timer count for each key.  Has anyone experimented with that kind of approach?

Offline TD22057

  • Posts: 172
  • Location: Southern California
Re: TMK keyboard firmware
« Reply #60 on: Fri, 12 July 2013, 18:07:34 »
So I'm trying to understand the debouncing algorithm that's in most of the matrix.c files (they all seem pretty similar).  It it's not too much trouble, could someone explain it in words?  The cherry switch spec says the debounce time is ~5ms.  It seems like most of the keyboards are doing something like this:
Code: [Select]
- for each row
   - energize row
   - wait 3-30 ms
   - read columns

Shouldn't the wait time built in to the loops mean that there isn't really a need for the debounce code?  I'm guessing it's necessary and I'm just missing something...

I realize now I misread that code - the delay in the reading loops are micro-seconds, not milli-seconds...

Offline hasu

  • Thread Starter
  • Posts: 2908
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: TMK keyboard firmware
« Reply #61 on: Fri, 12 July 2013, 18:15:19 »
There was a discuss about debouncing a while back. Maybe uselful for you.
http://geekhack.org/index.php?topic=42385.0

My deboucing code is very simple and premitive,  but it works :) I didn't care about debouncing method much, though, you will be able to find very elegant interesting algorithms and strategies on the net.
TMK products:HHKB Alt  ⌨ConvertersAlps64FC660C AltFC980C Alt

Offline TD22057

  • Posts: 172
  • Location: Southern California
Re: TMK keyboard firmware
« Reply #62 on: Fri, 12 July 2013, 18:45:57 »
There was a discuss about debouncing a while back. Maybe uselful for you.
http://geekhack.org/index.php?topic=42385.0

My deboucing code is very simple and premitive,  but it works :) I didn't care about debouncing method much, though, you will be able to find very elegant interesting algorithms and strategies on the net.

Thanks - I realize I'm probably changing something that isn't broken.  Hard to resist the urge to tinker...

Offline Charger

  • Posts: 166
Re: TMK keyboard firmware
« Reply #63 on: Sat, 13 July 2013, 01:28:50 »
Hmmmm I am so lost trying to figure out how to configure this. There wouldn't happen to be a detailed walk thought on how to set this up anywhere would there?.

Anyways I guess the main thing I am trying to figure out is how to configure the matrix and and pin out for a teensy 2. I assume that I can use the common files to make a new keyboard setup or one of the other keyboards that are on there but i don't know how to change the number of rows and columns. This may take me longer then making the keyboard at this rate lol

Offline domoaligato

  • * Exquisite Elder
  • Posts: 1660
  • Location: USA
  • All your base are belong to us!
    • All your base are belong to us!
Re: TMK keyboard firmware
« Reply #64 on: Sat, 13 July 2013, 02:39:33 »
Hmmmm I am so lost trying to figure out how to configure this. There wouldn't happen to be a detailed walk thought on how to set this up anywhere would there?.

Anyways I guess the main thing I am trying to figure out is how to configure the matrix and and pin out for a teensy 2. I assume that I can use the common files to make a new keyboard setup or one of the other keyboards that are on there but i don't know how to change the number of rows and columns. This may take me longer then making the keyboard at this rate lol


the following is assuming your using the gh60 folder as a base to edit.
edit config.h for this area...
/* key matrix size */
#define MATRIX_ROWS 5
#define MATRIX_COLS 14


look at the matrix.c in the gh60 folder. it was the most straightforward one for me to look at.
assign your pins to the row/cols
one of the functions automatically determines the amount of keys are in your matrix based on the assignment.

then edit the keymap.c
you will see this...

#define KEYMAP( \
    K00, K01, K02, K03, K04, K05, K06, K07, K08, K09, K0A, K0B, K0C, K0D, \
    K10, K11, K12, K13, K14, K15, K16, K17, K18, K19, K1A, K1B, K1C, K1D, \
    K20, K21, K22, K23, K24, K25, K26, K27, K28, K29, K2A, K2B, K2C, K2D, \
    K30, K31, K32, K33, K34, K35, K36, K37, K38, K39, K3A, K3B, K3C, K3D, \
    K40, K41, K42,           K45,                     K4A, K4B, K4C, K4D  \
) { \
    { KC_##K00, KC_##K01, KC_##K02, KC_##K03, KC_##K04, KC_##K05, KC_##K06, KC_##K07, KC_##K08, KC_##K09, KC_##K0A, KC_##K0B, KC_##K0C, KC_##K0D }, \
    { KC_##K10, KC_##K11, KC_##K12, KC_##K13, KC_##K14, KC_##K15, KC_##K16, KC_##K17, KC_##K18, KC_##K19, KC_##K1A, KC_##K1B, KC_##K1C, KC_##K1D }, \
    { KC_##K20, KC_##K21, KC_##K22, KC_##K23, KC_##K24, KC_##K25, KC_##K26, KC_##K27, KC_##K28, KC_##K29, KC_##K2A, KC_##K2B, KC_##K2C, KC_##K2D }, \
    { KC_##K30, KC_##K31, KC_##K32, KC_##K33, KC_##K34, KC_##K35, KC_##K36, KC_##K37, KC_##K38, KC_##K39, KC_##K3A, KC_##K3B, KC_##K3C, KC_##K3D }, \
    { KC_##K40, KC_##K41, KC_##K42, KC_NO,    KC_NO,    KC_##K45, KC_NO,    KC_NO,    KC_NO,    KC_NO,    KC_##K4A, KC_##K4B, KC_##K4C, KC_##K4D }  \
}

add the keymap definition's to this area.

then

edit keymap_plain.h to match your key mappings/layout.

and do not forget to change the pinout assignment in led.c to either your pins for your led's if you have them....

void led_set(uint8_t usb_led)
{
    if (usb_led & (1<<USB_LED_CAPS_LOCK)) {
        // output low
        DDRB |= (1<<2);
        PORTB &= ~(1<<2);
    } else {
        // Hi-Z
        DDRB &= ~(1<<2);
        PORTB &= ~(1<<2);
    }
}
« Last Edit: Sat, 13 July 2013, 02:41:11 by domoaligato »

Offline yeeeargh

  • Posts: 15
Re: TMK keyboard firmware
« Reply #65 on: Sat, 13 July 2013, 05:04:16 »
you might take a look at this thread over on deskthority where someone goes through the same process. there might be some answers for problems you might walk into:
http://deskthority.net/workshop-f7/filco-minila-swap-alt-and-win-key-teensy-my-best-bet-t5751-90.html

Offline TD22057

  • Posts: 172
  • Location: Southern California
Re: TMK keyboard firmware
« Reply #66 on: Sat, 13 July 2013, 09:41:19 »
I'm working on a small TeensyPin class that encapsulates the direction, port, and pin registers for each pin.  The idea would be that you can then define your rows and columns like this:

Code: [Select]
static TeensyPin rows[MATRIX_ROWS] = {
   TPIN(F,0), TPIN(F,1), TPIN(F,4), TPIN(F,5),
   TPIN(F,6), TPIN(F,7),
};

static TeensyPin cols[MATRIX_COLS] = {
   TPIN(B,0), TPIN(B,1), TPIN(B,2), TPIN(B,3),
   TPIN(B,7), TPIN(D,2), TPIN(D,3), TPIN(C,6),
};

and that's all the code changes that would be required in matrix.c for a basic teensy layout (obviously you still have to customize led.c and keymap.c for your layout).  I'm hoping to have something working in the next week or so at which point you're welcome to look at it.  It won't be the most efficient way to do things but I think it will be a lot easier to read.  I don't think absolute efficiency matters that much and I have a better chance of understanding the code when I look at it next year and have forgotten everything I've learned about bit manipulation.

Offline bueller

  • MX baller
  • * Esteemed Elder
  • Posts: 3769
  • Location: Perth, Australia
  • Church of the Ergo Clear
Re: TMK keyboard firmware
« Reply #67 on: Sat, 13 July 2013, 13:41:50 »
I'm working on a small TeensyPin class that encapsulates the direction, port, and pin registers for each pin.  The idea would be that you can then define your rows and columns like this:

Code: [Select]
static TeensyPin rows[MATRIX_ROWS] = {
   TPIN(F,0), TPIN(F,1), TPIN(F,4), TPIN(F,5),
   TPIN(F,6), TPIN(F,7),
};

static TeensyPin cols[MATRIX_COLS] = {
   TPIN(B,0), TPIN(B,1), TPIN(B,2), TPIN(B,3),
   TPIN(B,7), TPIN(D,2), TPIN(D,3), TPIN(C,6),
};

and that's all the code changes that would be required in matrix.c for a basic teensy layout (obviously you still have to customize led.c and keymap.c for your layout).  I'm hoping to have something working in the next week or so at which point you're welcome to look at it.  It won't be the most efficient way to do things but I think it will be a lot easier to read.  I don't think absolute efficiency matters that much and I have a better chance of understanding the code when I look at it next year and have forgotten everything I've learned about bit manipulation.


Definitely check in and let us know when you're done, anything to make life easier for people on their first run!
It's a good width!  If it's half-width it's too narrow, and full-width is too wide. 

[WTT] bueller's trade thread - CLACKS WANTED

Offline TD22057

  • Posts: 172
  • Location: Southern California
Re: TMK keyboard firmware
« Reply #68 on: Sun, 14 July 2013, 23:32:04 »
So I have my C++ TeensyPin class working (see prev post) and I'd like to see how much it slows things down.  I'm using the gh60 directory as a test bed (my teensy is on a bread board so I don't have an actual keyboard to try anything with).  Using arrays of variables to store the ports vs raw bit manipulation of the registers is much easier to read, but it's definitely slower.

hasu - what's the best way to generate timing information?  I added code in matrix_scan() that calls timer_read32() every 500'th call and prints the difference.  Is that timer call returning a millisecond counter?  Is there a better way to find the overall keyboard scan rate? 

If it is a millisecond timer and my math is right (both BIG assumptions at this point), it looks like the normal gh60 code is calls matrix_scan() at ~3290 Hz and my modified version using arrays of column and row variables calls matrix_scan() at ~1710 Hz.  Both of those seem really fast but maybe that's normal...

EDIT: After some simple optimizations (-O3, unselect a single pin instead of all of them), the scan rate is up to 2200 Hz.
« Last Edit: Mon, 15 July 2013, 22:23:45 by TD22057 »

Offline agodinhost

  • Posts: 767
  • Location: Brazil, RJ
  • Soylent green is people ...
    • Dr Ian O Xaman
Re: TMK keyboard firmware
« Reply #69 on: Mon, 15 July 2013, 08:01:29 »
So I have my C++ TeensyPin class working (see prev post) and I'd like to see how much it slows things down.  I'm using the gh60 directory as a test bed (my teensy is on a bread board so I don't have an actual keyboard to try anything with).  Using arrays of variables to store the ports vs raw bit manipulation of the registers is much easier to read, but it's definitely slower.
Could you share your code man?
I'm still working on my PCB and I couldn't touch any code yet ...
Building one square I2C keyboard with those 1200 switches (thanks JDCarpe)
GH60 |GH60-Alps |GH60-BT |GHPad/GHPad Alps |GH60-Case |Alps TKL |EL Wire |OS Controller, Round 2 |My Custom Keyboard |WTT/WTB

Offline alaricljs

  • I be WOT'ing all day...
  • ** Moderator Emeritus
  • Posts: 3715
  • Location: NE US
Re: TMK keyboard firmware
« Reply #70 on: Mon, 15 July 2013, 08:58:26 »
They may be both really fast on their own, but yours leaves less headroom for adding other features that eat CPU time.
Filco w/ Imsto thick PBT
Ducky 1087XM PCB+Plate, w/ Matias "Quiet Click" spring-swapped w/ XM Greens

Offline hasu

  • Thread Starter
  • Posts: 2908
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: TMK keyboard firmware
« Reply #71 on: Mon, 15 July 2013, 09:11:05 »
So I have my C++ TeensyPin class working (see prev post) and I'd like to see how much it slows things down.  I'm using the gh60 directory as a test bed (my teensy is on a bread board so I don't have an actual keyboard to try anything with).  Using arrays of variables to store the ports vs raw bit manipulation of the registers is much easier to read, but it's definitely slower.

hasu - what's the best way to generate timing information?  I added code in matrix_scan() that calls timer_read32() every 500'th call and prints the difference.  Is that timer call returning a millisecond counter?  Is there a better way to find the overall keyboard scan rate? 

If it is a millisecond timer and my math is right (both BIG assumptions at this point), it looks like the normal gh60 code is calls matrix_scan() at ~3290 Hz and my modified version using arrays of column and row variables calls matrix_scan() at ~1710 Hz.  Both of those seem really fast but maybe that's normal...

Right. timer_read32() returns 32bit value in milli second. If you need finer granularity you can use other spare timer.

I think your code is fast enough to scan matrix and do debouncing.

TMK products:HHKB Alt  ⌨ConvertersAlps64FC660C AltFC980C Alt

Offline TD22057

  • Posts: 172
  • Location: Southern California
Re: TMK keyboard firmware
« Reply #72 on: Mon, 15 July 2013, 10:19:32 »
They may be both really fast on their own, but yours leaves less headroom for adding other features that eat CPU time.

Agreed - that's why I'm testing.  There is still some chance I can optimize my code to get better speed but it's never going to be as efficient as direct register manipulation.  So of course I'm not suggesting that everyone should switch to using my pin class - but for people who aren't programmers or who don't want to learn teensy bit manipulations, the pin class + hasu's firmware can make it a lot simpler for someone to build their own firmware.

Right. timer_read32() returns 32bit value in milli second. If you need finer granularity you can use other spare timer.

I think your code is fast enough to scan matrix and do debouncing.

Thanks for all your help.  From what I can find, most commercial keyboards are scanning at 100-200 Hz and I think Ben said the ergodox was running at 150 Hz so 1000 Hz seems like plenty even with debouncing.  I might try the same measurement w/ the ergodox code just to make sure I'm comparing the same quantities...

Offline bueller

  • MX baller
  • * Esteemed Elder
  • Posts: 3769
  • Location: Perth, Australia
  • Church of the Ergo Clear
Re: TMK keyboard firmware
« Reply #73 on: Mon, 15 July 2013, 10:35:37 »
I'm hoping someone more knowledgeable might be able to help. I've purchased the micro-controller below with the ATMEGA32U4 on board, can anyone advise whether I'll be able to use it with the TMK firmware? It supports the Arduino IDE if that's helps at all, hopefully I won't have any problems using it with Atmel's software.

Not really sure how I'd go about identifying what each pin would be called when modifying hasu's code as well, anyone got any ideas?

EDIT: Actually I think I've figured the pins out, I should have been lookng at the actual board and not the text next to it in the image. From what I can tell all the pins on the Teensy are available on my board (ie B0-B7 etc.)

« Last Edit: Mon, 15 July 2013, 11:11:02 by bueller »
It's a good width!  If it's half-width it's too narrow, and full-width is too wide. 

[WTT] bueller's trade thread - CLACKS WANTED

Offline alaricljs

  • I be WOT'ing all day...
  • ** Moderator Emeritus
  • Posts: 3715
  • Location: NE US
Re: TMK keyboard firmware
« Reply #74 on: Mon, 15 July 2013, 11:31:59 »
This is functionally identical to a teensy, just with a different PCB and a different packaging for the chip.

So you are correct that you use the pin IDs silk-screened to the PCB.
Filco w/ Imsto thick PBT
Ducky 1087XM PCB+Plate, w/ Matias "Quiet Click" spring-swapped w/ XM Greens

Offline bueller

  • MX baller
  • * Esteemed Elder
  • Posts: 3769
  • Location: Perth, Australia
  • Church of the Ergo Clear
Re: TMK keyboard firmware
« Reply #75 on: Mon, 15 July 2013, 12:00:08 »
Cheers! I'm eyeing off another board that's identical except for having headers for the usb port, might pick a 5 pack of those up for future builds and then wire up a proper USB connector.
It's a good width!  If it's half-width it's too narrow, and full-width is too wide. 

[WTT] bueller's trade thread - CLACKS WANTED

Offline agodinhost

  • Posts: 767
  • Location: Brazil, RJ
  • Soylent green is people ...
    • Dr Ian O Xaman
Re: TMK keyboard firmware
« Reply #76 on: Mon, 15 July 2013, 12:11:13 »
Cheers! I'm eyeing off another board that's identical except for having headers for the usb port, might pick a 5 pack of those up for future builds and then wire up a proper USB connector.
There are at least 4 I know of, all atmega32u4 based:
- The Official Arduino Micro
- The Freeduino on ebay
- The Unofficial Leonardo Pro Micro (it uses the Arduino Mini footprint) on ebay
- The old EWS Breakout Board on ebay too.
Building one square I2C keyboard with those 1200 switches (thanks JDCarpe)
GH60 |GH60-Alps |GH60-BT |GHPad/GHPad Alps |GH60-Case |Alps TKL |EL Wire |OS Controller, Round 2 |My Custom Keyboard |WTT/WTB

Offline domoaligato

  • * Exquisite Elder
  • Posts: 1660
  • Location: USA
  • All your base are belong to us!
    • All your base are belong to us!
Re: TMK keyboard firmware
« Reply #77 on: Mon, 15 July 2013, 13:13:30 »
link to the adafruit one.
http://www.adafruit.com/products/296

edit: and it is a different boot loader as well. you have to flash it with avrdude

http://ladyada.net/products/atmega32u4breakout/
« Last Edit: Mon, 15 July 2013, 13:16:18 by domoaligato »

Offline hasu

  • Thread Starter
  • Posts: 2908
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: TMK keyboard firmware
« Reply #78 on: Mon, 15 July 2013, 19:30:01 »
I'm hoping someone more knowledgeable might be able to help. I've purchased the micro-controller below with the ATMEGA32U4 on board, can anyone advise whether I'll be able to use it with the TMK firmware? It supports the Arduino IDE if that's helps at all, hopefully I won't have any problems using it with Atmel's software.

It will works with the firmware without problem. But you should note that Leonardo has LEDs on PD0 and PD1 while Teensy has PD6, these may has some affections on matrix scan. You had better avoid using those pin to sense matrix(using as input), however,  I think you can use them for driving matrix line(as output).
And one thing to be warned, Leonardo bootloader is very tricky to work with... to be honest, it sucks from my experience.

TMK has no Arduino support so you cannot use it from Arduino IDE.


Deskthority has thread about alternatives to Teensy.
http://deskthority.net/workshop-f7/teensy-2-0-alternatives-atmega32u4-t4253.html
« Last Edit: Mon, 15 July 2013, 19:31:43 by hasu »
TMK products:HHKB Alt  ⌨ConvertersAlps64FC660C AltFC980C Alt

Offline bueller

  • MX baller
  • * Esteemed Elder
  • Posts: 3769
  • Location: Perth, Australia
  • Church of the Ergo Clear
Re: TMK keyboard firmware
« Reply #79 on: Mon, 15 July 2013, 20:11:49 »
Cheers! I'm eyeing off another board that's identical except for having headers for the usb port, might pick a 5 pack of those up for future builds and then wire up a proper USB connector.
There are at least 4 I know of, all atmega32u4 based:
- The Official Arduino Micro
- The Freeduino on ebay
- The Unofficial Leonardo Pro Micro (it uses the Arduino Mini footprint) on ebay
- The old EWS Breakout Board on ebay too.

Here is the one I'm looking at, seems to be really customisable considering the price.

I'm hoping someone more knowledgeable might be able to help. I've purchased the micro-controller below with the ATMEGA32U4 on board, can anyone advise whether I'll be able to use it with the TMK firmware? It supports the Arduino IDE if that's helps at all, hopefully I won't have any problems using it with Atmel's software.

It will works with the firmware without problem. But you should note that Leonardo has LEDs on PD0 and PD1 while Teensy has PD6, these may has some affections on matrix scan. You had better avoid using those pin to sense matrix(using as input), however,  I think you can use them for driving matrix line(as output).
And one thing to be warned, Leonardo bootloader is very tricky to work with... to be honest, it sucks from my experience.

TMK has no Arduino support so you cannot use it from Arduino IDE.


Deskthority has thread about alternatives to Teensy.
http://deskthority.net/workshop-f7/teensy-2-0-alternatives-atmega32u4-t4253.html

Cheers for your help and all your hard work on the firmware! So if I'm understanding correctly I should be able to get rid of the Leonardo bootloader and write a more compatible one to the ATMEGA23U4?

It's a good width!  If it's half-width it's too narrow, and full-width is too wide. 

[WTT] bueller's trade thread - CLACKS WANTED

Offline agodinhost

  • Posts: 767
  • Location: Brazil, RJ
  • Soylent green is people ...
    • Dr Ian O Xaman
Re: TMK keyboard firmware
« Reply #80 on: Mon, 15 July 2013, 20:31:31 »
Here is the one I'm looking at, seems to be really customisable considering the price.
It seems to be one EWS breakout board, the footprint of this board is  kinda weird - double pin rows and the pos of the pins are not "arduino compatible". This board is kinda old, you can get cheaper versions on ebay, just do a search using "atmega32u4".
I don't know this one, have you tried ebay? There are a lot of China made arduinos there per a decent price.
« Last Edit: Mon, 15 July 2013, 20:33:52 by agodinhost »
Building one square I2C keyboard with those 1200 switches (thanks JDCarpe)
GH60 |GH60-Alps |GH60-BT |GHPad/GHPad Alps |GH60-Case |Alps TKL |EL Wire |OS Controller, Round 2 |My Custom Keyboard |WTT/WTB

Offline TD22057

  • Posts: 172
  • Location: Southern California
Re: TMK keyboard firmware
« Reply #81 on: Mon, 15 July 2013, 21:36:49 »
Could you share your code man?
I'm still working on my PCB and I couldn't touch any code yet ...

I've submitted a first cut at a sample simplified teensy firmware (based on gh60) at my fork of hasu's firmware.

The files of interest are the matrix.cpp and TeensyPin.hpp files.    The main idea is to make something that allows people to edit the row and column pin assignments in matrix.cpp and not touch anything else in that file (obviously you still have to edit keymap.c, maybe led.c, and the Makefile).   In the original file, you would need to add your pin assignments and set/clear the correct bits in init_cols(), read_cols(), unselect_rows() and select_row(). 

This is still in the prototype stage so there may still be problems with it.  Feel free to suggest improvements or name changes...

Offline agodinhost

  • Posts: 767
  • Location: Brazil, RJ
  • Soylent green is people ...
    • Dr Ian O Xaman
Re: TMK keyboard firmware
« Reply #82 on: Mon, 15 July 2013, 22:25:32 »
I've submitted a first cut at a sample simplified teensy firmware (based on gh60) at my fork of hasu's firmware.

The files of interest are the matrix.cpp and TeensyPin.hpp files.    The main idea is to make something that allows people to edit the row and column pin assignments in matrix.cpp and not touch anything else in that file (obviously you still have to edit keymap.c, maybe led.c, and the Makefile).   In the original file, you would need to add your pin assignments and set/clear the correct bits in init_cols(), read_cols(), unselect_rows() and select_row(). 

This is still in the prototype stage so there may still be problems with it.  Feel free to suggest improvements or name changes...
My 5 cents:

Your matrix_scan function does not settle any device address - so it is assuming that you do have only one I2C device. In my scenario I'll have 3: the 2 keyboard parts and one keypad - all using different addresses and configurations. I didn't saw any "setCurrentDeviceAddress" kind of function too.
The device address seems to be at the TeensyPin row/col arrays ...

Would not be better to use the two arrays (rowPins, colPins) as some sort of parameters ? It would help the "multiple devices" support and it would keep the responsibility/scope of your matrix class more clear (your matrix class is not responsible per the configuration data - it only uses it right?).

I think that the first and unique responsibility of your matrix class is to provide access to the keyboard matrix AND to make this access easier.

I need to put my hands in some piece of code - this is the kind of thing that is better to be done than said.

GOSH, so much stuff to do!!!
I need a day with 36 hours!!!
AHHHHHHHHHHHHHHHHHHHHHHhhhhh
My wife is calling me to bed ...
cya
« Last Edit: Mon, 15 July 2013, 22:31:16 by agodinhost »
Building one square I2C keyboard with those 1200 switches (thanks JDCarpe)
GH60 |GH60-Alps |GH60-BT |GHPad/GHPad Alps |GH60-Case |Alps TKL |EL Wire |OS Controller, Round 2 |My Custom Keyboard |WTT/WTB

Offline TD22057

  • Posts: 172
  • Location: Southern California
Re: TMK keyboard firmware
« Reply #83 on: Mon, 15 July 2013, 23:25:45 »
I think you've misunderstood what my first commit is for - there is no matrix class, no I2C, and no multi-device encapsulation.  I'm 1) learning how hasu's firmware works, and 2) trying to provide a way for people who aren't programmers to easily write the matrix scanning function.  I'm going to add I2C support and encapsulate each device as much as possible but that's going to take longer (and I'll probably start a new thread to stop pseudo-hijacking this one...).

Offline bueller

  • MX baller
  • * Esteemed Elder
  • Posts: 3769
  • Location: Perth, Australia
  • Church of the Ergo Clear
Re: TMK keyboard firmware
« Reply #84 on: Tue, 16 July 2013, 00:10:28 »

GOSH, so much stuff to do!!!
I need a day with 36 hours!!!
AHHHHHHHHHHHHHHHHHHHHHHhhhhh
My wife is calling me to bed ...
cya

This is me pretty much every night. Gets to midnight and I'm like "I'll just finish this up writing this class", next thing I know it's 4am. Hate the fact that I write my best code while everyone else is sleeping!
It's a good width!  If it's half-width it's too narrow, and full-width is too wide. 

[WTT] bueller's trade thread - CLACKS WANTED

Offline hasu

  • Thread Starter
  • Posts: 2908
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: TMK keyboard firmware
« Reply #85 on: Tue, 16 July 2013, 01:35:10 »
Cheers for your help and all your hard work on the firmware! So if I'm understanding correctly I should be able to get rid of the Leonardo bootloader and write a more compatible one to the ATMEGA23U4?

Right. You can replace bootloader with ISP programmer hardware like AVRISP mkII. You can pick LUFA DFU or CDC bootloader for this pupose. But if you don't want to pay for AVRISP mkII it is important to get a board with good bootloader.

IMO,
- Teensy Loader is the easiest way for first timer. Good document/tutorial with picures is useful.
- Atmel stock bootloader is OK. No problem.
- LUFA bootloader is good. I've never had a problem with LUFA DFU bootloader.
- Leonardo bootloader is not what you want.

If you already have Teensy, Atmel stock or LUFA bootloader you dont need to replace it. Just use it. But I'm completely sure you're frustrated with Leonardo bootloader. If you use it just once you may be OK, though, You cannot bear with it for several times.

LUFA is actually only one option if you need to replace bootloader. Atmel stock bootloader and PJRC Teensy bootloader is closed sourcen and no binaries available.


Following is memo of the bootloaders.
                                                                                                 
### LUFA DFU/HID/CDC bootloader
Open source bootloaders offered by LUFA.
         
Size: 4KB
Tool: dfu-programmer(DFU), Atmel FLIP(DFU), avrdude(HID,CDC), hid_bootloader(HID)
         
- http://fourwalledcubicle.com/blog/2013/03/the-new-lufa-bootloader/
- https://github.com/abcminiuser/lufa/tree/master/Bootloaders
         
         
         
### Atmel DFU bootloader
This is a stock bootloader from Atmel and factory default for AVR USB chips.
         
0. No source and binary available.
1. FLIP - Atmel prorietary GUI/CUI tool
2. dfu-programmer - Open source tool
         
Size: 4KB
Tool: FLIP, dfu-programmer
         
- http://www.atmel.com/Images/doc7618.pdf
         
         
         
### PJRC Teensy bootloader - halfKay
Extreme user friendly bootloader. You can get this loader Only by buying Teensy from PJRC.
         
0. No specific driver is needed using HID standard class.
1. Nice GUI tool. CUI command is also available.
2. Amazingly small foot print it occupies only 512 Bytes.
3. Can't handle EEPROM.
4. Closed source. Not avaiable source and binary.
         
Size: 512B
Tool: PJRC TeensyLoader(open source)
         
- http://www.pjrc.com/teensy/loader.html
- http://www.pjrc.com/teensy/halfkay_protocol.html
         
         
         
### Arduino Leonardo - caterina
Bootloader accompany with Arduino Leonardo. Not useful without Arduino IDE.
         
0. Open source. Derived from LUFA CDC bootloader.
1. Work with Arduino IDE.
2. Needs some extra procedure to program.
         
Size: 4KB
Tool: Arduino IDE, avrdude
         
- https://github.com/arduino/Arduino/tree/master/hardware/arduino/bootloaders/caterina
TMK products:HHKB Alt  ⌨ConvertersAlps64FC660C AltFC980C Alt

Offline bueller

  • MX baller
  • * Esteemed Elder
  • Posts: 3769
  • Location: Perth, Australia
  • Church of the Ergo Clear
Re: TMK keyboard firmware
« Reply #86 on: Tue, 16 July 2013, 02:36:18 »
Cheers for your help and all your hard work on the firmware! So if I'm understanding correctly I should be able to get rid of the Leonardo bootloader and write a more compatible one to the ATMEGA23U4?

Right. You can replace bootloader with ISP programmer hardware like AVRISP mkII. You can pick LUFA DFU or CDC bootloader for this pupose. But if you don't want to pay for AVRISP mkII it is important to get a board with good bootloader.

IMO,
- Teensy Loader is the easiest way for first timer. Good document/tutorial with picures is useful.
- Atmel stock bootloader is OK. No problem.
- LUFA bootloader is good. I've never had a problem with LUFA DFU bootloader.
- Leonardo bootloader is not what you want.

If you already have Teensy, Atmel stock or LUFA bootloader you dont need to replace it. Just use it. But I'm completely sure you're frustrated with Leonardo bootloader. If you use it just once you may be OK, though, You cannot bear with it for several times.

LUFA is actually only one option if you need to replace bootloader. Atmel stock bootloader and PJRC Teensy bootloader is closed sourcen and no binaries available.


Following is memo of the bootloaders.
                                                                                                 
### LUFA DFU/HID/CDC bootloader
Open source bootloaders offered by LUFA.
         
Size: 4KB
Tool: dfu-programmer(DFU), Atmel FLIP(DFU), avrdude(HID,CDC), hid_bootloader(HID)
         
- http://fourwalledcubicle.com/blog/2013/03/the-new-lufa-bootloader/
- https://github.com/abcminiuser/lufa/tree/master/Bootloaders
         
         
         
### Atmel DFU bootloader
This is a stock bootloader from Atmel and factory default for AVR USB chips.
         
0. No source and binary available.
1. FLIP - Atmel prorietary GUI/CUI tool
2. dfu-programmer - Open source tool
         
Size: 4KB
Tool: FLIP, dfu-programmer
         
- http://www.atmel.com/Images/doc7618.pdf
         
         
         
### PJRC Teensy bootloader - halfKay
Extreme user friendly bootloader. You can get this loader Only by buying Teensy from PJRC.
         
0. No specific driver is needed using HID standard class.
1. Nice GUI tool. CUI command is also available.
2. Amazingly small foot print it occupies only 512 Bytes.
3. Can't handle EEPROM.
4. Closed source. Not avaiable source and binary.
         
Size: 512B
Tool: PJRC TeensyLoader(open source)
         
- http://www.pjrc.com/teensy/loader.html
- http://www.pjrc.com/teensy/halfkay_protocol.html
         
         
         
### Arduino Leonardo - caterina
Bootloader accompany with Arduino Leonardo. Not useful without Arduino IDE.
         
0. Open source. Derived from LUFA CDC bootloader.
1. Work with Arduino IDE.
2. Needs some extra procedure to program.
         
Size: 4KB
Tool: Arduino IDE, avrdude
         
- https://github.com/arduino/Arduino/tree/master/hardware/arduino/bootloaders/caterina

Thank you SO much for that hasu, I'm sure that took ages to type! I'm pretty interested in mucking around with micro-controllers so I might just pick up an ISP programmer to change the bootloader on this but I'll make sure I get models without the Arduino bootloader in future. Cheers!
It's a good width!  If it's half-width it's too narrow, and full-width is too wide. 

[WTT] bueller's trade thread - CLACKS WANTED

Offline agodinhost

  • Posts: 767
  • Location: Brazil, RJ
  • Soylent green is people ...
    • Dr Ian O Xaman
Re: TMK keyboard firmware
« Reply #87 on: Tue, 16 July 2013, 06:54:38 »
I think you've misunderstood what my first commit is for - there is no matrix class, no I2C, and no multi-device encapsulation.  I'm 1) learning how hasu's firmware works, and 2) trying to provide a way for people who aren't programmers to easily write the matrix scanning function.  I'm going to add I2C support and encapsulate each device as much as possible but that's going to take longer (and I'll probably start a new thread to stop pseudo-hijacking this one...).
Sorry, I should have read more of your code before posting my comments.
So, can we start another thread? This topic is going to grow up soon and we are hijacking this one already!
 :)
Building one square I2C keyboard with those 1200 switches (thanks JDCarpe)
GH60 |GH60-Alps |GH60-BT |GHPad/GHPad Alps |GH60-Case |Alps TKL |EL Wire |OS Controller, Round 2 |My Custom Keyboard |WTT/WTB

Offline agodinhost

  • Posts: 767
  • Location: Brazil, RJ
  • Soylent green is people ...
    • Dr Ian O Xaman
Re: TMK keyboard firmware
« Reply #88 on: Tue, 16 July 2013, 07:09:06 »
...
### PJRC Teensy bootloader - halfKay
...
2. Amazingly small foot print it occupies only 512 Bytes.
...
512 Bytes only???
I bet it's done in assembly!
Sadly it's not open source ...
Building one square I2C keyboard with those 1200 switches (thanks JDCarpe)
GH60 |GH60-Alps |GH60-BT |GHPad/GHPad Alps |GH60-Case |Alps TKL |EL Wire |OS Controller, Round 2 |My Custom Keyboard |WTT/WTB

Offline alaricljs

  • I be WOT'ing all day...
  • ** Moderator Emeritus
  • Posts: 3715
  • Location: NE US
Re: TMK keyboard firmware
« Reply #89 on: Tue, 16 July 2013, 08:46:10 »
Thank you SO much for that hasu, I'm sure that took ages to type! I'm pretty interested in mucking around with micro-controllers so I might just pick up an ISP programmer to change the bootloader on this but I'll make sure I get models without the Arduino bootloader in future. Cheers!

If you want to DIY you can put together an ISP using a Teensy and some wires.  Amusingly enough the easiest ISP software to stick on it is an arduino sketch.  I've used my teensy to program several MCUs this way. 

http://dorkbotpdx.org/wiki/teensy_2_0_as_avr_isp_programmer
Filco w/ Imsto thick PBT
Ducky 1087XM PCB+Plate, w/ Matias "Quiet Click" spring-swapped w/ XM Greens

Offline hasu

  • Thread Starter
  • Posts: 2908
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: TMK keyboard firmware
« Reply #90 on: Mon, 22 July 2013, 18:25:46 »
For some reason, T(VOLU) refuses to register in macros. Is that because the media control keys are different and defined in a different way than the letters?

This commit fixed this issue. Now media control and power keys are supported in macro.
Try latest version.

https://github.com/tmk/tmk_keyboard/commit/5b425731c5b662d107ba0f970a7ae7c7fe97d01b
TMK products:HHKB Alt  ⌨ConvertersAlps64FC660C AltFC980C Alt

Offline damorgue

  • Posts: 1176
  • Location: Sweden
    • Personal portfolio
Re: TMK keyboard firmware
« Reply #91 on: Mon, 22 July 2013, 18:30:13 »
For some reason, T(VOLU) refuses to register in macros. Is that because the media control keys are different and defined in a different way than the letters?

This commit fixed this issue. Now media control and power keys are supported in macro.
Try latest version.

https://github.com/tmk/tmk_keyboard/commit/5b425731c5b662d107ba0f970a7ae7c7fe97d01b


Neato. Currently AFK (away from my phantom at least), but I trust it works. Thanks

Offline Charger

  • Posts: 166
Re: TMK keyboard firmware
« Reply #92 on: Mon, 22 July 2013, 20:32:38 »
Hmmm I wonder if there is a way to turn on an led based on what layer I'm on as it seems like it would be a nice thing that have the number row show the layer number

Offline TD22057

  • Posts: 172
  • Location: Southern California
Re: TMK keyboard firmware
« Reply #93 on: Tue, 23 July 2013, 13:29:25 »
Hmmm I wonder if there is a way to turn on an led based on what layer I'm on as it seems like it would be a nice thing that have the number row show the layer number

I think the right approach is to define a function action that sets the LED and then modifies the layer.  See examples here: HHKB keymap.c.  You'll have to hunt around to figure out what the layer change macros do now and repeat those calls in your function after setting the LED.

Something I would like to be able to do is flash an LED in a pattern of some kind.  This could be used to indicate the layer (3 flashes = layer 3), to communicate information like if you adjust the debounce settings via macro, or maybe to indicate a macro recording mode.  It could be done with some simple led/wait/led/wait type code but the keyboard wouldn't work while that was happening.  It could also be done in the matrix scan function by checking the timer value and after a certain elapsed time, toggle the LED state. 

I might work on a small class to encapsulate some functionality like this.  Anyone know of a better way to handle elapsed time actions?  Is there a timer callback somewhere that would work for this?

Offline TD22057

  • Posts: 172
  • Location: Southern California
Re: TMK keyboard firmware
« Reply #94 on: Tue, 23 July 2013, 14:24:05 »
Found this timer code for the teensy which supports interrupts which might be used to flash the LED.  Not sure how that overlaps with hasu's timer module (no interrupts). 

http://www.pjrc.com/teensy/td_libs_TimerOne.html


Offline hasu

  • Thread Starter
  • Posts: 2908
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: TMK keyboard firmware
« Reply #95 on: Tue, 23 July 2013, 20:53:35 »
Callback  for timer interrupt or evnets like layer change and etc ? Interesting.

I use Timer0 as counter at milli second resolution in common/timer.h. You might be able to add timer callback to this.  Or you can also use other spare timer for callback.

And you may want to use hardware PWM to control LED better. I used PWM for sleep breathing LED in common/sleep_led.c.
TMK products:HHKB Alt  ⌨ConvertersAlps64FC660C AltFC980C Alt

Offline tjweir

  • * Exquisite Elder
  • Posts: 1039
  • Location: Toronto
Re: TMK keyboard firmware
« Reply #96 on: Wed, 24 July 2013, 10:46:52 »
I've used TMK to program my HID_liberation board and now I'd like to use it on my MX MINI.

Has anyone tried this yet?  I see a KMAC project, shall I start with that?

Thanks!

Offline domoaligato

  • * Exquisite Elder
  • Posts: 1660
  • Location: USA
  • All your base are belong to us!
    • All your base are belong to us!
Re: TMK keyboard firmware
« Reply #97 on: Thu, 25 July 2013, 14:36:16 »
when compiling the gh60 hex for the actual gh60 to flash with atmel flip...
I use the Makefile for lufa right?

Offline hasu

  • Thread Starter
  • Posts: 2908
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: TMK keyboard firmware
« Reply #98 on: Thu, 25 July 2013, 19:53:26 »
when compiling the gh60 hex for the actual gh60 to flash with atmel flip...
I use the Makefile for lufa right?

Both lufa and pjrc stack works well for gh60, though I recommend lufa from now on. I won't update pjrc stack code for new features.

Compiling process doesn't depend on what flash method you use.

Use Makefile.lufa.
TMK products:HHKB Alt  ⌨ConvertersAlps64FC660C AltFC980C Alt

Offline domoaligato

  • * Exquisite Elder
  • Posts: 1660
  • Location: USA
  • All your base are belong to us!
    • All your base are belong to us!
Re: TMK keyboard firmware
« Reply #99 on: Thu, 25 July 2013, 20:14:55 »
when compiling the gh60 hex for the actual gh60 to flash with atmel flip...
I use the Makefile for lufa right?

Both lufa and pjrc stack works well for gh60, though I recommend lufa from now on. I won't update pjrc stack code for new features.

Compiling process doesn't depend on what flash method you use.

Use Makefile.lufa.


Thanks!

I have tested it with lufa now and it works great compiling the latest version with winavr.
I am typing this on it now using your firmware and it works perfectly.

I am working on a c# gui to work as a layout editor for your firmware on windows for the gh60.

I will start small with basic poker functionality but later wish to implement the mousekeys and macro functions into the layout editor.
more to come soon.