Author Topic: TMK keyboard firmware  (Read 819752 times)

0 Members and 1 Guest are viewing this topic.

Offline QuiGonJinn

  • Posts: 16
Re: TMK keyboard firmware
« Reply #750 on: Sat, 11 July 2015, 09:02:19 »
I see, thank for clarifying everything. Probably buying an arduino micro is the fastest alternative for me right now.

Offline flabbergast

  • Posts: 234
  • Location: UK
Re: TMK keyboard firmware
« Reply #751 on: Sat, 11 July 2015, 09:20:51 »
I see, thank for clarifying everything. Probably buying an arduino micro is the fastest alternative for me right now.
Yep. Or a teensy.

Offline QuiGonJinn

  • Posts: 16
Re: TMK keyboard firmware
« Reply #752 on: Sat, 11 July 2015, 10:03:12 »
Yes, I would buy a teensy, which I am using for another custom keyboard I am working on, but the greek market seems drained of teensys  :)

Offline hasu

  • Thread Starter
  • Posts: 3471
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: TMK keyboard firmware
« Reply #753 on: Sat, 11 July 2015, 17:18:35 »
I am in the process of building a custom keyboard and I have an arduino clone with the atmega328p MCU lying around. I tried compiling firmware for it using the Makefile.vusb from the HHKB project. The matric.c file is including lufa.h which is then including lufa/Drivers/USB/Core/USBMode.h and then I get the error message "The currently selected device or architecture is not supported under the USB component of the library" and then a bunch of other errors. Is there a straightforward way to compile keyboard software for my MCU? Excuse me for my ignorance.

My HHKB controller project has no support for 328/168p series anymore.
I just fixed and added V-USB build process for ps2_usb and onekey project. You can see onekey if you are still interested.


As flabbergast said, USB AVR chip and LUFA is easier way.

Offline flabbergast

  • Posts: 234
  • Location: UK
Re: TMK keyboard firmware
« Reply #754 on: Sun, 12 July 2015, 01:52:43 »
My HHKB controller project has no support for 328/168p series anymore.
I just fixed and added V-USB build process for ps2_usb and onekey project. You can see onekey if you are still interested.
Thanks for the explanation! I didn't mean any disrespect when I said it's broken, sorry! I think TMK is a fine piece of software, thanks for maintaining it :thumb:

Offline Charger

  • Posts: 168
Re: TMK keyboard firmware
« Reply #755 on: Wed, 15 July 2015, 16:11:37 »
I was wondering if there is an easy way to add a layer indicator led into a layer? I have been wondering this for some time. I have used tmk on my main keyboard and numpad and I'm currently working on 3 other things that will be using tmk and wanted to add some leds to indicate the layer on one of them.

Offline hasu

  • Thread Starter
  • Posts: 3471
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: TMK keyboard firmware
« Reply #756 on: Wed, 15 July 2015, 18:22:00 »
Probably you can add your code in common/action_layer.c. All layer change actions should be occured in static void default_layer_state_set(uint32_t state). See this PR. https://github.com/tmk/tmk_keyboard/pull/198

Or also you can define action_function() that changes layer and handles indicator at the same time in your keymap file.

Offline IBNobody

  • Posts: 113
Re: TMK keyboard firmware
« Reply #757 on: Wed, 15 July 2015, 20:05:56 »
I'm looking for some suggestions on how to implement a backlight solution that uses PWMs to control 4 LED rows of 6 LEDs each.

All the example keyboards with backlights defined appear to only use a handful of teensy I/O for the backlighting. That leads me to believe they aren't driving them with a PWM but instead are just turning them on (probably through a transistor). I don't want to just leave them on because that would consume way too much current and potentially violate the USB current spec.

I saw that the Planck fork of TMK DID use hardware PWMs, but it looked like they were also driving all keyboard LEDs through a single transistor. I'd still violate the current spec, but only for a fraction of a second.

Are there any other reference examples with multiple PWMs? Could I just fake it by adding in a backlight toggle to the matrix_scan function? (How often does that function run? Is it run at a specific fixed frequency?)

Offline hasu

  • Thread Starter
  • Posts: 3471
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: TMK keyboard firmware
« Reply #758 on: Wed, 15 July 2015, 20:48:54 »
Are there any other reference examples with multiple PWMs? Could I just fake it by adding in a backlight toggle to the matrix_scan function? (How often does that function run? Is it run at a specific fixed frequency?)

I don't know much about PWM itself and how difficult to implement multiple PWMs, you can find many Arduino projects or something  to learn on the net.

matrix_scan() is called from while loop of main() actually, so not consistently periodic run.
I think you need to use timer interrupt if you want eaxact frequency or you are going to use software PWM.

Offline IBNobody

  • Posts: 113
Re: TMK keyboard firmware
« Reply #759 on: Wed, 15 July 2015, 21:13:32 »
I don't know much about PWM itself and how difficult to implement multiple PWMs, you can find many Arduino projects or something to learn on the net.

matrix_scan() is called from while loop of main() actually, so not consistently periodic run.
I think you need to use timer interrupt if you want eaxact frequency or you are going to use software PWM.

Ok. I'll try to dig into the Planck code (and the MCU datasheet) a little deeper and report back.

Though... I just had a thought. I probably only need 1 PWM. Having 4 PWMs and trying to drive all 4 LED banks separately (one bank on at a time) would mean that I'd be capped at a 25% duty cycle. I wonder how full-sized keyboards handle that current draw.

Offline a-c

  • Posts: 196
  • Location: USA
Re: TMK keyboard firmware
« Reply #760 on: Wed, 15 July 2015, 21:40:45 »
I don't know much about PWM itself and how difficult to implement multiple PWMs, you can find many Arduino projects or something to learn on the net.

matrix_scan() is called from while loop of main() actually, so not consistently periodic run.
I think you need to use timer interrupt if you want eaxact frequency or you are going to use software PWM.

Ok. I'll try to dig into the Planck code (and the MCU datasheet) a little deeper and report back.

Though... I just had a thought. I probably only need 1 PWM. Having 4 PWMs and trying to drive all 4 LED banks separately (one bank on at a time) would mean that I'd be capped at a 25% duty cycle. I wonder how full-sized keyboards handle that current draw.

The plank PCB isn't drawing more than 500ma. It has current limiting resistors on each LED. It draws about 3.5ma per LED (with white LED's). Total of about 168ma. Unless you want some incredibly bright output you can easily stay under 500ma.

Offline IBNobody

  • Posts: 113
Re: TMK keyboard firmware
« Reply #761 on: Wed, 15 July 2015, 22:11:55 »
The plank PCB isn't drawing more than 500ma. It has current limiting resistors on each LED. It draws about 3.5ma per LED (with white LED's). Total of about 168ma. Unless you want some incredibly bright output you can easily stay under 500ma.

Ahh. I wasn't sure how much current I should be drawing per LED (other than <= 20mA). When I get my LEDs in, I'll play around with my current limiting power supply and find the optimal brightness.

Offline Charger

  • Posts: 168
Re: TMK keyboard firmware
« Reply #762 on: Thu, 16 July 2015, 14:36:35 »
Probably you can add your code in common/action_layer.c. All layer change actions should be occured in static void default_layer_state_set(uint32_t state). See this PR. https://github.com/tmk/tmk_keyboard/pull/198

Or also you can define action_function() that changes layer and handles indicator at the same time in your keymap file.
ok so I think I got that working using his fork of tmk and building off that. Now I have another question I want to have a key that when tapped will toggle a layer but when pressed will do numlock and I'm wondering if that is possible. I seem to be able to get tap for key press and hold for momentary layer switching but couldn't see how to do what i wanted.

Offline hasu

  • Thread Starter
  • Posts: 3471
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: TMK keyboard firmware
« Reply #763 on: Thu, 16 July 2015, 19:53:01 »
It is probably possible but not supported by default. You can define your own action in action_function(), though how to define is not well documented(or at all) and you'll have to read and look into core code.

You can find various action definitions in core/common/action.c.
https://github.com/tmk/tmk_keyboard/blob/master/tmk_core/common/action.c

Offline Charger

  • Posts: 168
Re: TMK keyboard firmware
« Reply #764 on: Fri, 17 July 2015, 19:36:36 »
It is probably possible but not supported by default. You can define your own action in action_function(), though how to define is not well documented(or at all) and you'll have to read and look into core code.

You can find various action definitions in core/common/action.c.
https://github.com/tmk/tmk_keyboard/blob/master/tmk_core/common/action.c
any suggestions on what to change or look at in action.c? I have tried changing some of the code with little result I couldn't even break the ACTION_LAYER_TAP_KEY I have set up when commenting out or changing parts of the code that i thought may have been related lol.

Offline hasu

  • Thread Starter
  • Posts: 3471
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: TMK keyboard firmware
« Reply #765 on: Fri, 17 July 2015, 20:31:56 »
How did you change action.c? You can post here.
Did you try 'make clean' yet?

Offline Charger

  • Posts: 168
Re: TMK keyboard firmware
« Reply #766 on: Fri, 17 July 2015, 20:39:03 »
How did you change action.c? You can post here.
Did you try 'make clean' yet?
I use a batch file that does make clean and make -f makefile to compile it. As for what I edited was stuff under "case ACT_LAYER_TAP:" I was commenting things out and messing with stuff and recompiling and if I didn't notice any effect I would undo it so I don't really know what i changed but i thought I should have at least broken it if I was messing with the right things


Offline BlueNalgene

  • Posts: 739
  • Location: Oklahoma, USA
Re: TMK keyboard firmware
« Reply #767 on: Sat, 18 July 2015, 21:35:57 »
Working on my Model M (8P5C connector) and I ran into some problems.

I did a make based on the ps2_usb converter with the following settings.

Code: [Select]

MCU = at90usb1286
F_CPU = 16000000
ARCH = AVR8
MOUSEKEY_ENABLE = yes # Mouse keys(+4700)
EXTRAKEY_ENABLE = yes # Audio control and System control(+450)
CONSOLE_ENABLE = yes # Console for debug(+400)
COMMAND_ENABLE = yes    # Commands for debug and configuration
NKRO_ENABLE = yes # USB Nkey Rollover - not yet supported in LUFA

PS2_USE_INT = yes # uses external interrupt for falling edge of PS/2 clock pin


include $(TOP_DIR)/protocol.mk
include $(TOP_DIR)/protocol/pjrc.mk
include $(TOP_DIR)/common.mk
include $(TOP_DIR)/rules.mk


I omitted a bunch of the other stuff in the makefile, since I assume this is the relevant stuff.  Clock is set for D1, Data D0.  The hex makes, and I load it on my Teensy++.  When I power up, the 3 lock lights come on, then shut off after ~1s.  No keys are sent, and the lock lights don't change on the associated button press.  Where has it gone wrong?

The kicker: Soarer's XT/AT/PS2/Terminal 1.10 hex file for the Teensy++ works.  Not a hardware or wiring issue.

Offline hasu

  • Thread Starter
  • Posts: 3471
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: TMK keyboard firmware
« Reply #768 on: Sat, 18 July 2015, 22:05:09 »
Are you sure your M speaks Code Set 2? My PS/2 converter supports only CS2 while his supports all CS1, 2 and 3.

If your keyboard is terminal type it speaks CS3. You can use my terminal converter instead of PS/2.

Offline BlueNalgene

  • Posts: 739
  • Location: Oklahoma, USA
Re: TMK keyboard firmware
« Reply #769 on: Sat, 18 July 2015, 22:26:35 »
Are you sure your M speaks Code Set 2? My PS/2 converter supports only CS2 while his supports all CS1, 2 and 3.

If your keyboard is terminal type it speaks CS3. You can use my terminal converter instead of PS/2.

Oh, interesting point.  I don't have the original cable, so I can't check that way.  Next time I'm at that unit, I'll try the terminal version.

Offline henz

  • * Exquisite Elder
  • Posts: 1284
  • What?
Re: TMK keyboard firmware
« Reply #770 on: Fri, 24 July 2015, 15:18:41 »
Does TMK support KMAC happy? Will the normal TMK kmac work with the happy?

Offline IBNobody

  • Posts: 113
Re: TMK keyboard firmware
« Reply #771 on: Sat, 25 July 2015, 00:22:47 »
Ahh. I wasn't sure how much current I should be drawing per LED (other than <= 20mA). When I get my LEDs in, I'll play around with my current limiting power supply and find the optimal brightness.

So... Update...

I switched to using one PWM and was able to get 16 levels of brightness. Each LED pulls 6-7mA. I switch all LEDs through an NPN. I'm using ACTION_BACKLIGHT_TOGGLE, ACTION_BACKLIGHT_INCREASE, and ACTION_BACKLIGHT_DECREASE to control my states.

Everything works, but when I put my computer to sleep, the LEDs flicker on/off if I leave the backlight on.

I currently have the LED breathing option disabled.

Any idea why I'm seeing this behavior?

Offline TastaturenAuslese

  • Formerly temence
  • Posts: 231
  • Location: North Vancouver, Canada
  • life marrow suckerer
Re: TMK keyboard firmware
« Reply #772 on: Mon, 27 July 2015, 03:39:43 »
So I just finished defining a keymap for a new Planck that I'm getting in the mail. The previous owner already has the tmk firmware burned into the controller, and as such, I don't have any files besides the keymap I just wrote.

Can someone help me with what my next step should be? How do I make the makefile hex? I think this is the only step I don't understand. After I make the hex file, I can probably figure out how to load it unto the keyboard myself using the teensy loader. All help appreciated :D
Home: Kishsaver - IBM 6019284/F62 | Work: HHKB Professional 2 Silenced | Temporary Retirement:
More
IBM '89 1391401 Merrill Lynch Financial Edition


They are a functional and practical indulgence.

Offline jorgenslee

  • Posts: 369
  • Location: Philippines
Re: TMK keyboard firmware
« Reply #773 on: Mon, 27 July 2015, 03:53:48 »
Hi hasu, is it possible to use TMK as a firmware for a arcade stick game controller?

Offline Zustiur

  • Posts: 235
Re: TMK keyboard firmware
« Reply #774 on: Tue, 28 July 2015, 09:54:54 »
I'm getting this error when I try to compile the tmk firmware:
Quote
D:\Programming\Shared Projects\tmk_keyboard\keyboard\ZusDox>make -f makefile
The system cannot find the path specified.
The system cannot find the path specified.
ECHO is off.
-------- begin --------
avr-gcc (WinAVR 20100110) 4.3.3
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

-f was unexpected at this time.
make: *** [sizebefore] Error 255

Any clues as to what '-f was unexpected at this time' means? And why I'm getting "make: *** [sizebefore] Error 255"

I get the feeling it has something to do with winavr or windows rather than my code... I got the exact same error when I tried make -f makefile in the hhkb directory. I also googled a lot but came up with no helpful solutions.

I'll try a fresh install of WinAVR on a different machine tomorrow, but if anyone knows what's going on there I'd really appreciate the help!

Offline VinnyCordeiro

  • Posts: 432
Re: TMK keyboard firmware
« Reply #775 on: Tue, 28 July 2015, 10:07:31 »
I'm getting this error when I try to compile the tmk firmware:
Quote
D:\Programming\Shared Projects\tmk_keyboard\keyboard\ZusDox>make -f makefile
The system cannot find the path specified.
The system cannot find the path specified.
ECHO is off.
-------- begin --------
avr-gcc (WinAVR 20100110) 4.3.3
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

-f was unexpected at this time.
make: *** [sizebefore] Error 255

Any clues as to what '-f was unexpected at this time' means? And why I'm getting "make: *** [sizebefore] Error 255"

I get the feeling it has something to do with winavr or windows rather than my code... I got the exact same error when I tried make -f makefile in the hhkb directory. I also googled a lot but came up with no helpful solutions.

I'll try a fresh install of WinAVR on a different machine tomorrow, but if anyone knows what's going on there I'd really appreciate the help!
If you run make in the same directory where the makefile is, the -f parameter is unnecessary, make always assumes that a run without parameter indicates that the makefile is in the current directory.

As for the Error 255, it means that make couldn't find a command for a particular rule. By your quote I assume you are running on Windows. I suggest you to install Cygwin, it makes easier to install GNU programs on Windows.

Offline BlueNalgene

  • Posts: 739
  • Location: Oklahoma, USA
Re: TMK keyboard firmware
« Reply #776 on: Tue, 28 July 2015, 13:18:51 »
Are you sure your M speaks Code Set 2? My PS/2 converter supports only CS2 while his supports all CS1, 2 and 3.

If your keyboard is terminal type it speaks CS3. You can use my terminal converter instead of PS/2.

I almost forgot to report back.  The terminal converter wasn't playing along with my Model M either.  I really doubt that it uses CS3 or even CS1 though.  The original cable was SDL to PS2.  I tried both USART and interrupt wiring/code to no avail on both converters.

I'm not asking for a change in the code.  I just wanted to post a negative result in case someone else experiences a similar issue.  I'm just going to use Soarer's for this keyboard since I don't need anything too fancy and customized. 

-------

Unrelated question.  Why do you recommend USART in your code?  I don't entirely understand why that would be more robust than interrupt. 


Offline hasu

  • Thread Starter
  • Posts: 3471
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: TMK keyboard firmware
« Reply #777 on: Tue, 28 July 2015, 19:25:58 »
I think Soarer's converter displays which code set is using and other useful infos on debug console(hid_listen?), if you are interested. I guess code set 1 is used only for XT keyboard.


---
Now that I don't think my PS/2 implementations(Interrupt/Busywait/USART) have much difference pratically in robustness but at that time my other two impl. was a bit iffy and I thought USART one could perform better. USART can handle most of signal process in hardware, not firmware and virtually never intterrupted by other events so it never miss PS/2 signal.(I think but I'm not 100% sure about AVR architecture)

But now I'd recommend 'Intterrupt' one due to its portability and readability. I think current 'Interrupt' and even 'Busywait' can perform enough and virtually don't miss the signal.

Offline Zustiur

  • Posts: 235
Re: TMK keyboard firmware
« Reply #778 on: Tue, 28 July 2015, 23:27:17 »
As for the Error 255, it means that make couldn't find a command for a particular rule. By your quote I assume you are running on Windows. I suggest you to install Cygwin, it makes easier to install GNU programs on Windows.
Thank you. It worked like a charm! I now have half a working keyboard. Time to solder up the other half!

Offline VinnyCordeiro

  • Posts: 432
Re: TMK keyboard firmware
« Reply #779 on: Tue, 28 July 2015, 23:31:28 »
As for the Error 255, it means that make couldn't find a command for a particular rule. By your quote I assume you are running on Windows. I suggest you to install Cygwin, it makes easier to install GNU programs on Windows.
Thank you. It worked like a charm! I now have half a working keyboard. Time to solder up the other half!
:thumb:

Offline njbair

  • Posts: 2825
  • Location: Cleveland, Ohio
  • I love the Powerglove. It's so bad.
    • nickbair.net
Re: TMK keyboard firmware
« Reply #780 on: Fri, 31 July 2015, 00:21:59 »
I didn't see this in the docs, but is there a way to change the timing threshold for tapping?

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 a-c

  • Posts: 196
  • Location: USA
Re: TMK keyboard firmware
« Reply #781 on: Fri, 31 July 2015, 03:22:59 »
I didn't see this in the docs, but is there a way to change the timing threshold for tapping?

Look in common/action_tapping.h

Code: [Select]
/* period of tapping(ms) */
#ifndef TAPPING_TERM
#define TAPPING_TERM    200
#endif

/* tap count needed for toggling a feature */
#ifndef TAPPING_TOGGLE
#define TAPPING_TOGGLE  5
#endif

Offline njbair

  • Posts: 2825
  • Location: Cleveland, Ohio
  • I love the Powerglove. It's so bad.
    • nickbair.net
Re: TMK keyboard firmware
« Reply #782 on: Sat, 01 August 2015, 10:27:08 »
I didn't see this in the docs, but is there a way to change the timing threshold for tapping?

Look in common/action_tapping.h

Code: [Select]
/* period of tapping(ms) */
#ifndef TAPPING_TERM
#define TAPPING_TERM    200
#endif

/* tap count needed for toggling a feature */
#ifndef TAPPING_TOGGLE
#define TAPPING_TOGGLE  5
#endif

Wow, thanks. So I did some testing on this because I wasn't sure exactly how things worked.

Let's say I've got the spacebar set up with ACTION_LAYER_TAP_KEY(4, KC_SPC), and I leave TAPPING_TERM at its default 200ms. So as a modifier it enables Layer 4, and as a normal key it sends the scancode for Space.

I had expected that pressing it would enable Layer 4 immediately--so that if I held down the spacebar, then 100 milliseconds later pressed the Layer 4 key for F1 (number row 1 key, in my case), it would recognize it as a function action and not a normal keypress. But after some testing, it looks like the spacebar doesn't actually trigger Layer 4 until the 200ms period has occurred. So if I want to press F1, I have to hold down the spacebar for TAPPING_TERM before pressing the 1 key. So instead of sending the scancode for F1, the keyboard sends the scancodes for 1[space].

This creates a minor issue sometimes if I go too fast while trying to enter SpaceFn key combinations. But as I thought through this, I realized that this is really the only way to do it, because when we type our fingers don't always wait for the previous key to deactuate before actuating the next key (this is the whole premise behind NKRO).

With that said, 200ms seems like a pretty decent balance between the two. I'd like to do some testing to see if a slightly shorter TAPPING_TERM would work better for me, but with the need to recompile/reflash every time I'll really have to set aside some time to do that.

It would be really nice if you could set a key combination to increase/decrease the TAPPING_TERM on the fly. Something like ACTION_TAPPING_TERM_INC(x) and ACTION_TAPPING_TERM_DEC(x). While you're at it you can also have ACTION_TAPPING_TERM_SET(x), so if you know you prefer one speed for gaming and a different speed for office work, you can set key combinations to switch between them. Like Fn+G for Gaming Mode, Fn+W for Work Mode.

You would have to change TAPPING_TERM from a constant to a variable, and I'm not super familiar with embedded C code and the related memory constraints so I don't know how feasible this is. But it's something I'd be willing to work on if hasu approves.

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 QuiGonJinn

  • Posts: 16
Re: TMK keyboard firmware
« Reply #783 on: Sat, 01 August 2015, 14:22:34 »
I have a question, not directly related to programming the microcontroller, but I need your experience. Is there a chance that the atmega32u4(of arduino micro) on my newly made keyboard ,gets overheated so it stops working?

After finishing the build today (and flashing of a gh60 code modification), it worked for 4 hours straight, and then it stopped working. I was getting some kernel messages about the device not accepting address(76 and 78 etc) and continuous connects and disconnects of the device. After leaving the keyboard in front of a fan to cool, and now using it with a fan on it, it's working fine. Mind, the temperature in my room was at 35°C a couple of hours ago. The mictocontroller is glued with hot silicon glue on the plastic case, but in my understanding, it is supposed to help conduct the heat to the case except for keeping it steady.

Offline njbair

  • Posts: 2825
  • Location: Cleveland, Ohio
  • I love the Powerglove. It's so bad.
    • nickbair.net
Re: TMK keyboard firmware
« Reply #784 on: Sat, 01 August 2015, 15:47:02 »
I have a question, not directly related to programming the microcontroller, but I need your experience. Is there a chance that the atmega32u4(of arduino micro) on my newly made keyboard ,gets overheated so it stops working?

After finishing the build today (and flashing of a gh60 code modification), it worked for 4 hours straight, and then it stopped working. I was getting some kernel messages about the device not accepting address(76 and 78 etc) and continuous connects and disconnects of the device. After leaving the keyboard in front of a fan to cool, and now using it with a fan on it, it's working fine. Mind, the temperature in my room was at 35°C a couple of hours ago. The mictocontroller is glued with hot silicon glue on the plastic case, but in my understanding, it is supposed to help conduct the heat to the case except for keeping it steady.

Was this previously working without issue before you reflashed it?

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 QuiGonJinn

  • Posts: 16
Re: TMK keyboard firmware
« Reply #785 on: Sat, 01 August 2015, 17:29:54 »
I have a question, not directly related to programming the microcontroller, but I need your experience. Is there a chance that the atmega32u4(of arduino micro) on my newly made keyboard ,gets overheated so it stops working?

After finishing the build today (and flashing of a gh60 code modification), it worked for 4 hours straight, and then it stopped working. I was getting some kernel messages about the device not accepting address(76 and 78 etc) and continuous connects and disconnects of the device. After leaving the keyboard in front of a fan to cool, and now using it with a fan on it, it's working fine. Mind, the temperature in my room was at 35°C a couple of hours ago. The mictocontroller is glued with hot silicon glue on the plastic case, but in my understanding, it is supposed to help conduct the heat to the case except for keeping it steady.

Was this previously working without issue before you reflashed it?

I did not reflash the firmware. It just stopped responding and worked again without me touching anything. It has now been working again for 3 hours without any issues.

Offline njbair

  • Posts: 2825
  • Location: Cleveland, Ohio
  • I love the Powerglove. It's so bad.
    • nickbair.net
Re: TMK keyboard firmware
« Reply #786 on: Sat, 01 August 2015, 19:48:37 »
I have a question, not directly related to programming the microcontroller, but I need your experience. Is there a chance that the atmega32u4(of arduino micro) on my newly made keyboard ,gets overheated so it stops working?

After finishing the build today (and flashing of a gh60 code modification), it worked for 4 hours straight, and then it stopped working. I was getting some kernel messages about the device not accepting address(76 and 78 etc) and continuous connects and disconnects of the device. After leaving the keyboard in front of a fan to cool, and now using it with a fan on it, it's working fine. Mind, the temperature in my room was at 35°C a couple of hours ago. The mictocontroller is glued with hot silicon glue on the plastic case, but in my understanding, it is supposed to help conduct the heat to the case except for keeping it steady.

Was this previously working without issue before you reflashed it?

I did not reflash the firmware. It just stopped responding and worked again without me touching anything. It has now been working again for 3 hours without any issues.

Okay, sorry, I misunderstood. So you just finished building a new keyboard running on an Arduino Micro, which you've hot-glued to the case? If you've got the chip covered in hot glue that's your issue. Plastic doesn't conduct heat away. You should have that chip uncovered and facing out. Feel free to hot-glue the chip the other way, that shouldn't be an issue. But keep that chip facing the open air (whatever little there may be inside your keyboard.

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: 3471
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: TMK keyboard firmware
« Reply #787 on: Sat, 01 August 2015, 20:32:07 »
Let's say I've got the spacebar set up with ACTION_LAYER_TAP_KEY(4, KC_SPC), and I leave TAPPING_TERM at its default 200ms. So as a modifier it enables Layer 4, and as a normal key it sends the scancode for Space.

I had expected that pressing it would enable Layer 4 immediately--so that if I held down the spacebar, then 100 milliseconds later pressed the Layer 4 key for F1 (number row 1 key, in my case), it would recognize it as a function action and not a normal keypress. But after some testing, it looks like the spacebar doesn't actually trigger Layer 4 until the 200ms period has occurred.

Yes, it is exactly how TMK tapping key works and limitation or compromise of TMK tapping key.
To get F1 you have to [1] hold space for TAPPING_TERM(but note that you can press 1 key anytime after pressing space) or [2] press and release 1 key before releasing space.


Quote
So if I want to press F1, I have to hold down the spacebar for TAPPING_TERM before pressing the 1 key. So instead of sending the scancode for F1, the keyboard sends the scancodes for 1[space].

 You don't have to wait 200ms *before* pressing 1 key, you can press 1 key anytime after holding down space, as said above,  just have to hold down space for 200ms([1]) or release 1 key before releasing space([2]).

You cannot get a complete modifier behaviour(and key behaviour) with tapping key, it is all of trade off or compromise. If you have better modifier behaviour you will have to accept more limitation on key behaviour. TMK tapping key is just one of dual roll key implementations and other can have a bit different behaviour and limitation. You have to accept some limitation anyway when you use tapping(dual role) key.


Quote
This creates a minor issue sometimes if I go too fast while trying to enter SpaceFn key combinations. But as I thought through this, I realized that this is really the only way to do it, because when we type our fingers don't always wait for the previous key to deactuate before actuating the next key (this is the whole premise behind NKRO).

EDIT: yes, you are right. the limitation of TMK is needed for better typing experience especially when typing fast.




Changing TAPPING_TERM parameter on the fly without compile would be useful when you find your value by trial and error. But I think at most several compile processes are needed to decide your proper value.
For gaming purpose you may want to change layer and use ACTION_LAYER_MOMENTARY() instead of ACTION_LAYER_TAP_KEY(). Even using small value doesn't resolve the tapping limitation essentially for gaming in particular.

I may implement these actions in next refactroing of keymap module but not sure.
« Last Edit: Sat, 01 August 2015, 20:42:01 by hasu »

Offline hasu

  • Thread Starter
  • Posts: 3471
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: TMK keyboard firmware
« Reply #788 on: Sat, 01 August 2015, 20:44:34 »
You can post pics of your work and error messages as is to get more help from the community.

I have a question, not directly related to programming the microcontroller, but I need your experience. Is there a chance that the atmega32u4(of arduino micro) on my newly made keyboard ,gets overheated so it stops working?

After finishing the build today (and flashing of a gh60 code modification), it worked for 4 hours straight, and then it stopped working. I was getting some kernel messages about the device not accepting address(76 and 78 etc) and continuous connects and disconnects of the device. After leaving the keyboard in front of a fan to cool, and now using it with a fan on it, it's working fine. Mind, the temperature in my room was at 35°C a couple of hours ago. The mictocontroller is glued with hot silicon glue on the plastic case, but in my understanding, it is supposed to help conduct the heat to the case except for keeping it steady.


Offline njbair

  • Posts: 2825
  • Location: Cleveland, Ohio
  • I love the Powerglove. It's so bad.
    • nickbair.net
Re: TMK keyboard firmware
« Reply #789 on: Sat, 01 August 2015, 21:13:25 »
Changing TAPPING_TERM parameter on the fly without compile would be useful when you find your value by trial and error. But I think at most several compile processes are needed to decide your proper value.

The real pain with reflashing firmwares is that you need another keyboard to do it, because once you put the board in bootloader mode, you can't type the shell commands. I don't keep a spare keyboard here at home. I work around this by SSH'ing from my laptop, so not a huge deal but still kind of a pain.

For gaming purpose you may want to change layer and use ACTION_LAYER_MOMENTARY() instead of ACTION_LAYER_TAP_KEY(). Even using small value doesn't resolve the tapping limitation essentially for gaming in particular.

So basically just make a gamer layer. This is actually a really good idea. Thanks!

I may implement these actions in next refactroing of keymap module but not sure.

Not a high priority, for sure. But it would be kind of a neat feature. I'm assuming it's not possible to store the new TAPPING_TERM permanently, since AFAIK there is no flash memory on the chip.

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 a-c

  • Posts: 196
  • Location: USA
Re: TMK keyboard firmware
« Reply #790 on: Sat, 01 August 2015, 23:34:56 »
It has EEPROM. That is where the virtual DIP switch settings are stored.

Offline flabbergast

  • Posts: 234
  • Location: UK
Re: TMK keyboard firmware
« Reply #791 on: Sun, 02 August 2015, 00:00:37 »
The real pain with reflashing firmwares is that you need another keyboard to do it, because once you put the board in bootloader mode, you can't type the shell commands. I don't keep a spare keyboard here at home. I work around this by SSH'ing from my laptop, so not a huge deal but still kind of a pain.

Yes, it is not very convenient, but depending on how reliably and fast you can enter the bootloader mode, in linux or os x's terminal you can do
Code: [Select]
sleep 10; <flashing command> which will wait for 10 seconds and then execute the flashing command without any keyboard assistance.

Offline QuiGonJinn

  • Posts: 16
Re: TMK keyboard firmware
« Reply #792 on: Sun, 02 August 2015, 03:16:58 »
I have a question, not directly related to programming the microcontroller, but I need your experience. Is there a chance that the atmega32u4(of arduino micro) on my newly made keyboard ,gets overheated so it stops working?

After finishing the build today (and flashing of a gh60 code modification), it worked for 4 hours straight, and then it stopped working. I was getting some kernel messages about the device not accepting address(76 and 78 etc) and continuous connects and disconnects of the device. After leaving the keyboard in front of a fan to cool, and now using it with a fan on it, it's working fine. Mind, the temperature in my room was at 35°C a couple of hours ago. The mictocontroller is glued with hot silicon glue on the plastic case, but in my understanding, it is supposed to help conduct the heat to the case except for keeping it steady.

Was this previously working without issue before you reflashed it?

I did not reflash the firmware. It just stopped responding and worked again without me touching anything. It has now been working again for 3 hours without any issues.

Okay, sorry, I misunderstood. So you just finished building a new keyboard running on an Arduino Micro, which you've hot-glued to the case? If you've got the chip covered in hot glue that's your issue. Plastic doesn't conduct heat away. You should have that chip uncovered and facing out. Feel free to hot-glue the chip the other way, that shouldn't be an issue. But keep that chip facing the open air (whatever little there may be inside your keyboard.

The chip may be making contact with the hot glue, it is hard for me to verify unless i take the whole keyboard apart right now, Still, while the hot glue is in contact with the case, by touch I don't feel irregular heat at the spot. I recompiled and flashed the firmware now, if issues come up again, I'll probably try replacing the glue.

Offline henz

  • * Exquisite Elder
  • Posts: 1284
  • What?
Re: TMK keyboard firmware
« Reply #793 on: Sun, 02 August 2015, 13:56:32 »
Just added KMAC happy support, made a pull request, and i need someone to test if it still works properly for the tkl models.

Offline njbair

  • Posts: 2825
  • Location: Cleveland, Ohio
  • I love the Powerglove. It's so bad.
    • nickbair.net
Re: TMK keyboard firmware
« Reply #794 on: Sun, 02 August 2015, 19:52:41 »
I have a question, not directly related to programming the microcontroller, but I need your experience. Is there a chance that the atmega32u4(of arduino micro) on my newly made keyboard ,gets overheated so it stops working?

After finishing the build today (and flashing of a gh60 code modification), it worked for 4 hours straight, and then it stopped working. I was getting some kernel messages about the device not accepting address(76 and 78 etc) and continuous connects and disconnects of the device. After leaving the keyboard in front of a fan to cool, and now using it with a fan on it, it's working fine. Mind, the temperature in my room was at 35°C a couple of hours ago. The mictocontroller is glued with hot silicon glue on the plastic case, but in my understanding, it is supposed to help conduct the heat to the case except for keeping it steady.

Was this previously working without issue before you reflashed it?

I did not reflash the firmware. It just stopped responding and worked again without me touching anything. It has now been working again for 3 hours without any issues.

Okay, sorry, I misunderstood. So you just finished building a new keyboard running on an Arduino Micro, which you've hot-glued to the case? If you've got the chip covered in hot glue that's your issue. Plastic doesn't conduct heat away. You should have that chip uncovered and facing out. Feel free to hot-glue the chip the other way, that shouldn't be an issue. But keep that chip facing the open air (whatever little there may be inside your keyboard.

The chip may be making contact with the hot glue, it is hard for me to verify unless i take the whole keyboard apart right now, Still, while the hot glue is in contact with the case, by touch I don't feel irregular heat at the spot. I recompiled and flashed the firmware now, if issues come up again, I'll probably try replacing the glue.

FYI you won't feel a hot spot on the case exterior because plastic is a poor heat conductor.

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: 3471
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: TMK keyboard firmware
« Reply #795 on: Sun, 02 August 2015, 22:21:22 »
Great job!
This is his pull request.
https://github.com/tmk/tmk_keyboard/pull/237

KMAC happy and TKL users, try his/her branch and report back.
https://github.com/ageaenes/tmk_keyboard/tree/kmac_happy_support



BTW, I'll later create a wiki page and organize links to project using TMK by others. I'm doing refactoring of my codes and I basically won't merge projects contributed by others to my repository anymore. I'd want project owners to maintain their project on their own repository now. Of course, pull requests to core library part are welcomed as they were.
https://github.com/tmk/tmk_keyboard/issues/173


Just added KMAC happy support, made a pull request, and i need someone to test if it still works properly for the tkl models.

Offline henz

  • * Exquisite Elder
  • Posts: 1284
  • What?
Re: TMK keyboard firmware
« Reply #796 on: Mon, 03 August 2015, 00:34:21 »
Thanks for the support.


BTW, I'll later create a wiki page and organize links to project using TMK by others. I'm doing refactoring of my codes and I basically won't merge projects contributed by others to my repository anymore. I'd want project owners to maintain their project on their own repository now. Of course, pull requests to core library part are welcomed as they were.
https://github.com/tmk/tmk_keyboard/issues/173


Just added KMAC happy support, made a pull request, and i need someone to test if it still works properly for the tkl models.

Do you think that  this is a good idea? I know its hard to maintain everything yourself, but creating a bunch of subprojects with different owners will kill some layouts, like for instance if a owner decides to go afk.




My opinion:
I like the idea to have everything as it is now, instead making contributors to your project, giving frequent contributors, whos opinions you trust write acess.

Keeping everything as it is+ contributors will increase the sense of community that everyone can chip in.


Offline quantumfractal

  • Posts: 5
Re: TMK keyboard firmware
« Reply #797 on: Mon, 03 August 2015, 09:34:26 »
Hey there! I recently built my own 60% keyboard. Your code works excellently, even though I managed to screw up config stuff a few times :p. I have one issue and it's a strange one. My comma key does not work. I've checked to ensure the switch works electrically. And the config seems to be correct in my c files. When I debug the matrix there's nothing showing up. Any ideas why this one key wouldn't be working?

Thanks again!

Offline henz

  • * Exquisite Elder
  • Posts: 1284
  • What?
Re: TMK keyboard firmware
« Reply #798 on: Mon, 03 August 2015, 09:56:20 »
Hey there! I recently built my own 60% keyboard. Your code works excellently, even though I managed to screw up config stuff a few times :p. I have one issue and it's a strange one. My comma key does not work. I've checked to ensure the switch works electrically. And the config seems to be correct in my c files. When I debug the matrix there's nothing showing up. Any ideas why this one key wouldn't be working?

Thanks again!

Did you handwire it or is it your own pcb. please post all information you think might be of help like pictures of the wires/pcb(top and bottom) link to code etc.

Offline quantumfractal

  • Posts: 5
Re: TMK keyboard firmware
« Reply #799 on: Mon, 03 August 2015, 13:31:45 »
Sorry! I'm at work right now and thought I'd post it at a reasonable time. But yes it's handwired. The pins are setup correctly because everything except that key is working. I'm using a Teensy 2.0. As far as firmware, I'm using the SpaceFN layout and I've checked the matrix and keybind macro in keymap_common.h. I'll post it when I get home, thank you very much for your help!