TMK keyboard firmware collection

[Vizir]

I still need to apply the changes in the other directories, right? the ones in common.mk and common/keyboard.c and common/led.h?

edit: nvm. yes, had to apply the changes. working great now!

[idollar]

The prove follows
(I am typing with the model m keyboard WITH CAPSLOCK ON)

I also have a model f to try but I need to find the time to put together a new external case like the one you can see in my pictures. It is a different connector.

[idollar]

edit: nvm. yes, had to apply the changes. working great now!

Nice to hear. Let us know in a couple of weeks if it works fine. I will be testing my model m in parallel.

[idollar]

Hello Hasu,

I have connected a model m 122 and a model f 122 to your terminal_usb controller and it works nicely. This includes my modification to add support to LEDs

I am trying to use macros with this converter but the FNx seems to be ignored. I guess that I am doing something wrong, but just in case, I wanted to ask.

Thanks in advance

i$

[idollar]

Hi,

FYI - Hasu did not like my (working) code. His comment was:

I think problem is poor LED API. With better API users will be able to write code to control their LEDs without touching core code. I'll rethink about that some later. Thank you.

This means that my pull request was not merged with the code.

i$

[blackkat]

I have an interesting problem with a custom built hand-wired board powered by a teensy and tmk_keyboard. The keyboard is wired as a 17 column 5 row matrix.

All of the keys work correctly except for the caps lock key. When I press the caps lock key, I get the key-code for caps lock (row 2, col 2) and the key-codes for all of the keys in column 7 at the same time (5,T,G,V).

If I do not touch the caps lock key after the keyboard has been plugged in, the 5TGV keys work correctly. However, once the caps lock key has been pressed, pressing the caps lock or any of the 5TGV keys causes key-codes for 5TGV to be emitted at the same time.

I am wondering if this kind of failure is a sign of a short, or if it is a sign of something wrong with my configuration of the code.

[Muirium]

Classic short circuit symptoms. Test for continuity! Especially with the case installed and tightened. Sounds like one of those annoying Heisenbugs, whose existence depends on whether you're looking for it.

[blackkat]

Thanks a lot for the advice Muirium! I was not sure where to start with this problem, and welcome your seasoned experience

[Halvar]

It could also be a miconfiguration in the code I think. Check that you correctly defined all row pins on the teensy as output and column pins as input respectively.

[blackkat]

Thanks for the advice Halvar!

[blackkat]

Well, the story gets weirder. After checking for shorts, and bugs (Found none of the former, and one of the latter) the prroblem still persists. On a whim, I tried changing the key that was mapped to the caps lock position from CAPS to LCTL...and the problem with the repeating column "5TGV" dissappeared.

[blackkat]

Did anyone out there hear a scream about 5 minutes ago from the direction of Canada? If so it was me finally figuring out what the hell the problem was with my custom build. It was a software bug after all, and I know why the caps lock key was making the issue show up. Completely my fault

TL;DR ... if you're starting from a base keyboard within tmk_keyboard (gh60 in my case), make sure that that base firmware does not use one of the pins you have configured as a column as an LED indicator!

So here is what was happening:
Whenever the caps function was triggered, all of the keys in the column that was also defined as the CAPS LED indicator were all set as HIGH.
If the caps function was not triggered, pressing a key in the column that was also defined as the CAPS LED indicator would trigger a HIGH on that pin, triggering the CAPS LED, and also triggering all of the keys in the column.

Thanks for the help everyone!

(Typed on the KB that I built)

[BaronFer]

Great job hasu, thank you

I´m working on my own custom keyboard, but i don´t know how to use your firmware to use a Spanish ISO layout like this:


I must say my C Knowledge is not as good as i want at this time, so i´ve studied the code but haven´t figured how its works.
After reading all previous post i´m still locking for a way to do it.Is it possible to do it? Myabe using custom keycodes?

I´m making the code using the gh60 code like it´s explained in this other post here

Spoiler:

http://deskthority.net/workshop-f7/how- ... t7177.html

Also i want to know if its possible to use the makefile.pjrc to have NKRO since lufa has no support for it.

Thanks, and again, great job with the firmware.

[hasu]

ISO is not problem except that key code names are US-centric. Probably you can just use ';' instead of 'Ñ', for example.
And NKRO is supported by both PJRC and LUFA usb stacks, but I recommend LUFA because I don't use PJRC stack anymore.

[angerthosenear]

Firstly, thank you hasu for all your work on this project.

I am planning to build a Planck ( http://planckkeyboard.com/ ).

I'm new to the whole custom keyboard thing. Is there any plans to have TMK also work for ARM-based systems? I have a Teensy 3.1 that I would like to put in my next keyboard. And with the upcoming Teensy-LC, there seems to be a growing number of ARM based controllers.

Do you have any suggestions to making a keyboard controller using the Teensy 3.1? Everything I have come across is for Amtel/AVR systems.

Any pointers would be greatly appreciated. Thanks in advance.

Edit: I'm assuming more of the issue would lie with LUFA not being for ARM Cortex-M4?

[hasu]

Yep, TMK already supports Massdrop Infinity(Freescale K20) and PS2-USB converter with NXP LPC11U35. They are based on mbed HAL and USB library, if you are familiar with mbed sdk and mbed supports your controller it is not difficult to port.
At this time mbed based codes are not full feature but really work well, for example NKRO and mouse are not supported yet.

Teensy3.1 has Freescale MCU very simlar to Inifinity and it will be easy to port TMK. I don't have plan to get Teensy and add support to it myself. If you want to do that I'll help.

[angerthosenear]

Yep, TMK already supports Massdrop Infinity(Freescale K20) and PS2-USB converter with NXP LPC11U35. They are based on mbed HAL and USB library, if you are familiar with mbed sdk and mbed supports your controller it is not difficult to port.
At this time mbed based codes are not full feature but really work well, for example NKRO and mouse are not supported yet.

Teensy3.1 has Freescale MCU very simlar to Inifinity and it will be easy to port TMK. I don't have plan to get Teensy and add support to it myself. If you want to do that I'll help.

Oh! Awesome.

I'm completely new to everything, so I'm not familiar with the mbed sdk or anything like that. I've been fiddling around with the keypad examples in Arudino. They work... but obviously not suitable.

I would greatly appreciate any help to get it working on the Teensy 3.1. Sent ya a PM.

[Volkovich_]

First of all, thanks Hasu for your great work.

I just got my first mechanical keyboard, an spanish Dell AT102W and I would love to convert it from PS/2 to USB using a PJRC teensy and your firmware, like paranoid did here.



The only thing that keeps me from modding my keyboard is if I can create a layout file containing all the spanish keys (the Ñ looks like a bit tricky, as well as the "<") like the BaronFer one



I've been reading a bit here in deskthority but I'm unable to find another spanish that has done that before succesfully, so I'm a bit lost here. Any help/advice for an absolute begginer will be highly appreciated

Just to clarify, the only thing I'm asking help for, is the key mappings (my C knowledge is quite bad) but with the wiring/soldering/flashing I think I will manage.

Thanks!

[idollar]

the layout is interpreted by the Operating System.
You do not need to do anything but to configure the OS to believe that the keyboard has Spanish layout.

eg: The controller will produce the ";" equivalent, the OS will transform this into an "ñ"

[Volkovich_]

the layout is interpreted by the Operating System.
You do not need to do anything but to configure the OS to believe that the keyboard has Spanish layout.

eg: The controller will produce the ";" equivalent, the OS will transform this into an "ñ"

So, let's see if I understood you correctly. I put the teensy on my KB, I do the wiring and the flashing of the software, as described in the README in GitHub, without editing any files, and then setting my layout in my OS will do the trick? So, No need to specify that the keyboard has an ISO layout or anything?

And by the way, my current PS/2 to USB cheap converter can't reproduce the key next to the "z", in my case the "<" symbol. And when playing, if I am pressing for example "w", and if I tap any other key, "w" gets released, thus having to press it again. Is that solved with this firmware?

And sorry to look like the young boy who asks the most obvious questions.

Thanks

[idollar]

So, let's see if I understood you correctly. I put the teensy on my KB, I do the wiring and the flashing of the software, as described in the README in GitHub, without editing any files, and then setting my layout in my OS will do the trick? So, No need to specify that the keyboard has an ISO layout or anything?

That's my understanding. As you are adding a converter after the already existent controller, you do not have to specify the layout. The converter will not listen to the matrix directly, instead it will "translate" the output from the original controller to HID.

And by the way, my current PS/2 to USB cheap converter can't reproduce the key next to the "z", in my case the "<" symbol.And when playing, if I am pressing for example "w", and if I tap any other key, "w" gets released, thus having to press it again. Is that solved with this firmware?

I do not know the answer. I can try with my converter if you need an answer ...

And sorry to look like the young boy who asks the most obvious questions.
Thanks

These are not obvious questions. You probably have to read the code (I read only part of it) to get the answers

[Halvar]

With this, hasu's TMK firmware, you'll still have to configure the software to convert PS/2 to USB and compile it before you can flash it. No need to configure anything about ISO or spanish layout though. You need to install an AVR tooolchain like WinAVR on your computer to compile the code and get a .hex file that you can flash to the Teensy.

If you're not comfortable with C and just want a Teensy firmware that works for converting PS/2 to USB, you might be better off with Soarer's converter (I hope hasu is ok with me saying that in this thread): http://deskthority.net/workshop-f7/xt-a ... t2510.html This software comes precompiled and can be configured if you want with a configuration file that you send to the keyboard when everything else is done and the basic converter works. For an AT-102 you won't need any configuration file at all, it will just work, but if you want you can swap keys or define macros or additional layers (e.g. for Media keys) if you want to.

You can do pretty much all of that with hasu's firmware, too, and there are some very nice predefined functions/macros in it, too, but if you want to change more than the predefined things, the way to do it will always be to change the source code, compile a new firmware, reset the Teensy and re-program it.

[idollar]

With this, hasu's TMK firmware, you'll still have to configure the software to convert PS/2 to USB and compile it before you can flash it. No need to configure anything about ISO or spanish layout though. You need to install an AVR tooolchain like WinAVR on your computer to compile the code and get a .hex file that you can flash to the Teensy.

If you're not comfortable with C and just want a Teensy firmware that works for converting PS/2 to USB, you might be better off with Soarer's converter (I hope hasu is ok with me saying that in this thread): http://deskthority.net/workshop-f7/xt-a ... t2510.html This software come precompiled and can be configured if you want with a configuration file that you send to the keyboard when everything is done. For an AT-102 you won't need any configuration file at all, it will just work, but if you want you can swap keys or define macros or additional layers (e.g. for Media keys) if you want to.

You can do pretty much all of that with hasu's firmware, too, and there are some very nice predefined functions/macros in it, too, but if you want to change more than the most obvious things, the way to do it will always be to change the source code, compile a new firmware, reset the Teensy and re-program it.

Hi Halvar,

All what you are saying is correct but you forgot to mention that Soarer never released the code and is not longer reachable ... (this post is part of the marketing )

[Halvar]

Very true. On the other hand, there is great documentation and there are many people who have a lot of experience with it... (I got it )

[idollar]

Very true. On the other hand, there is great documentation and there are many people who have a lot of experience with it... (I got it )

Stop one could also say that MS Win_ows and A_ple are used by many people and have documentation (it is not great) ... which does not mean that they are good. Didn't we have this conversation before ?

(This is the follow up of my commercial above )

[Halvar]

Didn't we have this conversation before ?

I'm afraid so ...

[hasu]

The only thing that keeps me from modding my keyboard is if I can create a layout file containing all the spanish keys (the Ñ looks like a bit tricky, as well as the "<") like the BaronFer one

Default keymap is supposed to support ISO keyboard as well as JIS but I tested only with ANSI US keyboard. It probably has some mistakes.

First, you have to check what scan codes your dell ps/2 keyboard sends when pressing those keys. With PJRC hid_listen tool you will be able to see scan codes, just press LShift+RShift+D to enable debug print.

Sencod, check what keycodes other Spanish USB keyboard make on your OS. Use proper tools like aquakeytest, AHK(windows) or xev, showkeys(linux).

Post your result. I'll be able to fix the problem.

[Ray]

Ah, I didn't see this one and did ask some questions in matt3o's thread about your firmware:

Well, I did delve quite into this firmware, but still don't grasp the big theme of it. Maybe it is because I try to avoid looking into USB-stack or other protocols.

If I want to check once after connecting if numlock is set on the computer - and if it isn't, sent a numlock press - where should I do that?

On another note, I want a command to be executed on every keypress except on modifiers (if I could exclude more keys, that's fine too). Where is a nice place to do this? I tried in action.c where it says /* Key and Mods */ after the if(mods) I tried an else, but this gets executed on any keypress still...

I also have a hard time to jump to the bootloader with the Magic Keycombo. It works fine directly after I flash the teensy, but if I unplug it and reconnect it, it won't for some reason. Other Magic Keycombos still work, but it won't jump to the bootloader - I have to open the keyboard and finger the reset-button...

And I found an inconsistency in your doc: It says the ACTION_FUNCTION[_TAP] take two arguments, when they only take one.

[hasu]

You can see LED indicator status with uint8_t host_keyboard_leds(void); of host.h.

All key events can be caught there except for tapping keys. You can discriminate keys from modifiers with inspecting action struct action_t of action_code.h. Normal keys are actions where (action.key.kind == ACT_LMODS && action.key.mods == 0) in fact, while modifiers are actions where (action.key.kind == ACT_LMODS && action.key.code == 0).
https://github.com/tmk/tmk_keyboard/blo ... .h#L30-L31


Bootloader jump should work, check BOOTLOADER_SIZE in Makefile and see this discussion.
https://github.com/tmk/tmk_keyboard/issues/179

And I found an inconsistency in your doc: It says the ACTION_FUNCTION[_TAP] take two arguments, when they only take one.

Nice catch! I'll fix it later. Thanks.
https://github.com/tmk/tmk_keyboard/issues/210

[Ray]

Thanks hasu!

my first question was meant differently: where can I place code, that gets executed after everything is set up, but before regular keypress-polling starts?
is the main() in lufa.c the main that should interest me if I use a modified gh60 firmware? If so, here after the inits and before the while(1) should be where I should start trying I guess. I'll see later.

second question should be answered, thank you for that. I will test it later and confirm.

regarding bootloader: I have "OPT_DEFS += -DBOOTLOADER_SIZE=512" in my Makefile, I even added "#define BOOTLOADER_SIZE 512" to config.h when I tried to fix it myself, but that didn't help.
Maybe I should go check if I indeed have that bootloader version...
EDIT: since I use teensy-loader-cli, it has to be HalfKay as the bootloader, hasn't it? In that case 512 would be correct...
Another EDIT: okay, that isn't necessarily true, I will just randomly try 512, 1k, 2k and 4k later
I did only change the MAGIC key and in command.c I changed KC_PAUSE to KC_BSPC, but that shouldn't break it.