How to build your very own keyboard firmware

[Ray]

Oh yes, these things happen unfortunately...

And thanks to ReleaseCandidate for correcting me . Always happy to learn.

[Aenuriel]

Hello guys,

I did the modifications in all files, but I don’t understand how to create the .hex file with the makefile. I don’t know too how to use WinAVR.

Can someone explain it to me or build the .hex file for me?

Thanks for your answers.

[tentator]

it's a matter of reading all the documentation and/or this thread.. but schematically what you will need to do is: install winavr, download tmk, run "make all" after this works start to configure for your project..

[tentator]

guys: anybody experience with "debounce"?
I mean what value are you using and on what does it depend?
I found so far that 5, the default in tmk, is very bad for my mx browns and a 15x5 matrix so far.. I had to use 1.. 0 renders the keyboard unresponsive and anything bigger than 2 makes it slughish (works only if you type slowly, otherwise you lose some keys because the debounce wrongly kicks in...)..

let me know your experiences with that (and which matrix and switches you use)

tent:wq

[tentator]

up?

also have another question (maybe for @hasu directly?): is it possible to convert with tmk two ps2 devices with one teensy to the same usb port? I mean, if I want to build a controller for an unicomp with trackpoint that comes out with two ps2 connectors, do I have any chance to get both ps2 to get converted with a teensy and tmk?
If I use USART as outgoing protocol I was hoping I can use two ports like standard D5 and D2 for one device, say the ps2 keyboard, and other two ports like D1 and D3 for another, say the ps2 mouse.. maybe?

tent:wq

[flabbergast]

Debounce: 'N' means more-less 'N ms wait for switches to settle, starting from the point where a change is detected'. The default value (5) has worked for me (mostly with Reds, actually never Browns). To me it looks like there's something fishy electrically with your setup (i.e. the firmware is dealing with some stuff which shouldn't be there). Try hid_listen and enable debug?

PS/2: It is possible, but very likely it will require adapting the TMK code. (I don't know how much exactly, it's not quite up my alley.)

[tentator]

I'm not seing anything strange with debug.. but maybe you can give me some hint about what I should check?
so far I can only see that with debounce 5 the keyboard works only if I really type slowly otherwise many presses get caught by the debounce algorithm.. I find this 5 setting really too much.. with 1 it's ok.. so how can it be that for you 5 is ok? the switch sholdn't matter in the time the debouncing is looked for, right?

about ps2 I'm fine with modifying the tmk code but not sure if there is some technical limitation before I dig into that (maybe ps2 protocol does support more devices in parallel? )

[flabbergast]

Debounce: the code relating to this is not actually in tmk_core, but in matrix.c for individual keyboards, see e.g. here for the GH60 defaults. So maybe check your matrix.c ?

PS/2: AFAIK PS/2 does not support more devices on the same lines, but I'm not 100% sure about this. If it's so, you'd need to connect the two PS/2 things to different pins (i.e. a pair of pins for the first device, another pair of pins for the second).

[tentator]

debounce: from what I read in the code the algorithm is simply something that will avoid to read the keyboard matrix again unless DEBOUNCE ms have passed, most probably because you would otherwise get too soon key repetitions (anyway for some strange reason with DEBOUNCE=0 this is not the case).. but also if you type quite fast it should anyways not be possible to press two keys withing 5ms, isn't it??

ps2: the problem is also if I use 2+2 separate pins I understood that interrupt based PS2 MUST use PD5 and PD2, USART MUST? (please confirm ) use PD2 and PD5.. should give a try with plain polling..... which I do not really like but still if it works...

[flabbergast]

debounce: the point of doing this is that when you press the switch, electrically speaking it's not an immediate transition from 0 to 1 (or conversely), but it may take a little while until the state settles. (see e.g. here). Cherry MX switches are officially rated for 5ms (meaning that 5ms after a press or a release happens, the state is guaranteed to be settled).
The way hasu's algo works I think is that when a matrix change is detected, he starts a 5ms 'timeout', during which he still checks the matrix every 1ms - and if another change on the same row is detected within the 'timeout', he starts the 5ms 'debounce timeout again'.
Generally speaking it's pretty hard to actually type so fast that this algo would interfere with typing (>200 keypresses per second?).
But it may be that this procedure *does* interfere, if - for some reason - he's detecting way too many changes on some row. The 'reason' could be that there's some electrical problem generating noise, or that 'read_cols' is reading some pin which it shouldn't.

Maybe I'm going about this in a too complicated way. One thing you could try is to change your read_cols to actually only read one particular column (to try to isolate which pin may be problematic). If the trouble keeps happening with each of them, them I'm totally off track.

PS/2: USART based - atmegas have only 1 UART, so you can't use UART for both PS/2 devices. Interrupt based - hasu's implementation requires the CLOCK line to be on a pin with external interrupt, meaning one of PD0, PD1, PD2, PD3 (on atmega32u4. if you look at the chip pinout, these pins have INT0 .. INT3 in the description). Polling would work as well, but... yea.

EDIT: I've read up a bit. USART *requires* the pins hasu uses, Clock on PD5, Data on PD2.

[tentator]

Debounce: I agree that it seems that could be some noise or so then.. but it actually also does not explain why if I use DEBOUNCE=1 it works just fine.... not a single issue.... just if I press more than, say 5 or 6 keys at once I get a debounce message in the debug.... but I'll try to test it one column per time and see indeed...

PS/2: ok, this means the easiest would be to use two pins with two interrupts (like PD0+PD1 [also used by Soarer] and then PD2+PD3) this would also make it pro micro compatible, not only teensy 2.0. And I'll forget the USART but won't be going into polling..

[hbar]

Hi guys,

Recently I converted my first custom keyboard (thread: workshop-f7/hbar-alpha-an-ergonomic-key ... 10982.html ) from Suka's code to tmk, which was a fairly easy transition. Now that I can program some keys to send compose-character sequences, the layout is finally ready for everyday use (which is indeed why the board is sitting on the desk at work now). The only thing still missing is the trackpoint. Putting the pieces together for the Fn code was relatively easy (even though I didn't really have a good example to start with), but I'm stuck with the PS/2 mouse. Worse, I'd need it to work like Suka's code did: when mouse motion is detected, three keys change function and become the mouse buttons, then revert to regular keys after a certain timeout.

So: is this possible with tmk, and how do I set it up? Are there examples out there that I could use?

BTW, I modified the GH60 code, as suggested here, so the USB environment is LUFA.

Thanks,

ħ

[tentator]

wow impressive 3d prints there I've just read the thread. Well done!
I didn't spot exactly where you want to put the trackpoint tough.. anyway I'd suggest you to wire the trackpoint to D5 and D2 like explained by hasu for using it on a teensy 2.0 with his tmk firmware and enabling the USART mode in the makefile.
What trackpoint are you using btw?

tent:wq

PS: you should remove a closed parenthesis on the link to your project page otherwise others get a 404 when clicking on it

[hbar]

Thanks tentator, but there is no 3D printing involved there... just lasered stainless and acrylic. I also fixed the link (put in a space otherwise not needed), thanks for pointing that out.

The trackpoint (from a Thinkpad keyboard I got off ebay for 1 or 2 €) is the green PCB on the bottom of the right-hand unit, plus the HSS drill bit sticking out between four keys (which had one corner each very slightly filed down to make space).

I'll try the USART mode then when I have the time.

ħ

[hbar]

The PS/2 trackpoint is working now, maybe it needs some sensitivity tweaking, not sure though.

(Side note: I had to convince the Windows computer I have to use regularly that the mouse device is actually a mouse I intend to use. Since I added the PS/2 part after using the keyboard without PS/2 on this computer, Windows was convinced that the new mouse device wasn't there for any good reason. Re-installing the driver within "Device Manager" solved the issue in an instant.)

Now the only thing missing is the automatic switch to a particular layer whenever mouse movement is detected, and back after a timeout without mouse movement. It's the only thing that worked in Suka's code and doesn't yet in tmk. Maybe it's there, I just don't see it.

Can anyone help me with this? Maybe you've done it before?

ħ

[Ray]

That functionality is not built into TMK. But it is not too much code to add. My implementation on that is a bit hacky I guess. Maybe I'll get my fork up to date, so you can use it.

[hbar]

That would be great, Ray, I'll have a look if you post the URL.

[Ray]

https://github.com/3ner/tmk_keyboard.git
It activates a mousebutton-layer on movement of the trackpoint if that lasts a little bit longer than a brief tap. It deactivates it with time or press of a non-mousebutton non-modifier key.
Still, sometimes I want the time to be longer, sometimes I want it to deactivate the layer faster. I really paste a lot from the clipboard with middle mouse button (linux), when I would want to hit "i", and get "k" when I want a leftclick.

You'll find it used in keyboard/3ner/
If you run into any problems please let me know.

[tentator]

I really like your solution you are using there Ray!
and do you have pictures how this nice 40% keyboard looks like?? seems cute..

[Ray]

workshop-f7/my-custom-ergonomic-suka-st ... ml#p229180 and the whole thread.
There will be a new version probably sometime after I can try the Ergo Pro that is on tour.

[tentator]

Wow nice!!
What are you using there as top of the pointing stick?
I'm using just a nail so far...

But so far you two guys' idea is to reuse keyboard switches as mouse buttons and not have dedicated ones at all?

[Ray]

I was actually looking for a nail in my dad's messy little workshop and these pins were the second thing I found and decided it looks cool. It isn't very nice to the tip of the finger though.

And yes, I don't have dedicated mouse buttons, just my regular switches. And this sucks quite bad with linear switches.

If this makes you think I don't like my selfmade keyboard - you are kinda right. I do actually use it less than my notebook keyboard/mousepad because of many things that are too uncomfortable to get used to. I like the tenting, the stagger on columns instead of rows and some use of additional thumbkeys, it just doesn't outweigh the linear (MX-black) keys, the missing touchpad, the column-padding that I messed up (I got regular margin on the plate, but the curve makes it more narrow), etc.
I really want to do a new one, but try the Ergo Pro first.

[fillchiam]

Hey everyone, I'm new here so I'm not entirely sure this is the right place, but...

I'm trying to compile TMK with ChibiOS+kinetis for my Teensy LC, and I get this error when running make in the tmk_keyboard-master/keyboard/teensy_lc_onekey directory:

Code: Select all

Linking build/ch.elf
/usr/lib/gcc/arm-none-eabi/4.9.3/../../../arm-none-eabi/bin/ld: build/ch.elf section `.isr' will not fit in region `flash0'
/usr/lib/gcc/arm-none-eabi/4.9.3/../../../arm-none-eabi/bin/ld: region `flash0' overflowed by 64 bytes
collect2: error: ld returned 1 exit status
../../tmk_core/tool/chibios/chibios/os/common/ports/ARMCMx/compilers/GCC/rules.mk:238: recipe for target 'build/ch.elf' failed
make: *** [build/ch.elf] Error 1

I'm using gcc-arm-none-eabi 15:4.9.3+svn227297-1 under Ubuntu 15.10. Anyone know what's wrong, or how I can fix this?

Full output of make is as follows:

Code: Select all

william@Malkav:~/Downloads/tmk_keyboard-master/keyboard/teensy_lc_onekey$ make
Compiler Options
arm-none-eabi-gcc -c -mcpu=cortex-m0plus -O2 -ggdb -fomit-frame-pointer -falign-functions=16 -std=gnu99 -DPROTOCOL_CHIBIOS -ffunction-sections -fdata-sections -fno-common -flto -include config.h -Wall -Wextra -Wundef -Wstrict-prototypes -Wno-missing-field-initializers -Wa,-alms=build/lst/ -DCORTEX_USE_FPU=FALSE -DBOOTMAGIC_ENABLE -DMOUSEKEY_ENABLE -DMOUSE_ENABLE -DEXTRAKEY_ENABLE -DCONSOLE_ENABLE -DCOMMAND_ENABLE -DNKRO_ENABLE -DSLEEP_LED_ENABLE -DNO_SUSPEND_POWER_DOWN -DVERSION=unknown -DTHUMB_PRESENT -mno-thumb-interwork -DTHUMB_NO_INTERWORKING -MD -MP -MF .dep/build.d -I. -I../../tmk_core/tool/chibios/chibios/os/common/ports/ARMCMx/compilers/GCC -I../../tmk_core/tool/chibios/chibios/os/common/ports/ARMCMx/devices/KL2x -I../../tmk_core/tool/chibios/chibios/os/ext/CMSIS/include -I../../tmk_core/tool/chibios/chibios/os/ext/CMSIS/KINETIS -I../../tmk_core/tool/chibios/chibios/os/rt/include -I../../tmk_core/tool/chibios/chibios/os/rt/ports/ARMCMx -I../../tmk_core/tool/chibios/chibios/os/rt/ports/ARMCMx/compilers/GCC -I../../tmk_core/tool/chibios/chibios/os/hal/osal/rt -I../../tmk_core/tool/chibios/chibios/os/hal/include -I../../tmk_core/tool/chibios/chibios/os/hal/ports/common/ARMCMx -I../../tmk_core/tool/chibios/chibios/os/hal/ports/KINETIS/KL2x -I../../tmk_core/tool/chibios/chibios/os/hal/ports/KINETIS/LLD -I../../tmk_core/tool/chibios/chibios/os/hal/boards/PJRC_TEENSY_LC -I../../tmk_core/tool/chibios/chibios/os/hal/lib/streams -I../../tmk_core/tool/chibios/chibios/os/various -I../../tmk_core -I../../tmk_core/common -I../../tmk_core/protocol/chibios -I../../tmk_core/protocol -I. main.c -o main.o

Compiling crt0_v6m.s
Compiling chcoreasm_v6m.s
Compiling crt1.c
Compiling vectors.c
Compiling chsys.c
Compiling chdebug.c
Compiling chvt.c
Compiling chschd.c
Compiling chthreads.c
Compiling chdynamic.c
Compiling chregistry.c
Compiling chsem.c
Compiling chmtx.c
Compiling chcond.c
Compiling chevents.c
Compiling chmsg.c
Compiling chmboxes.c
Compiling chqueues.c
Compiling chmemcore.c
Compiling chheap.c
Compiling chmempools.c
Compiling chcore.c
Compiling chcore_v6m.c
Compiling osal.c
Compiling hal.c
Compiling st.c
Compiling hal_buffers.c
Compiling hal_queues.c
Compiling hal_mmcsd.c
Compiling pal.c
Compiling usb.c
Compiling nvic.c
Compiling hal_lld.c
Compiling pal_lld.c
Compiling serial_lld.c
Compiling i2c_lld.c
Compiling ext_lld.c
Compiling adc_lld.c
Compiling gpt_lld.c
Compiling pwm_lld.c
Compiling st_lld.c
Compiling usb_lld.c
Compiling board.c
Compiling chprintf.c
Compiling usb_main.c
Compiling main.c
Compiling keymap_plain.c
Compiling matrix.c
Compiling led.c
Compiling host.c
Compiling keyboard.c
Compiling action.c
../../tmk_core/common/action.c: In function 'debug_event':
../../tmk_core/common/action.c:546:29: warning: unused parameter 'event' [-Wunused-parameter]
 void debug_event(keyevent_t event)
                             ^
Compiling action_tapping.c
Compiling action_macro.c
Compiling action_layer.c
Compiling action_util.c
Compiling keymap.c
Compiling print.c
Compiling debug.c
Compiling util.c
Compiling suspend.c
Compiling printf.c
Compiling timer.c
Compiling bootloader.c
Compiling bootmagic.c
Compiling eeconfig.c
Compiling mousekey.c
Compiling command.c
Compiling sleep_led.c
Linking build/ch.elf
/usr/lib/gcc/arm-none-eabi/4.9.3/../../../arm-none-eabi/bin/ld: build/ch.elf section `.isr' will not fit in region `flash0'
/usr/lib/gcc/arm-none-eabi/4.9.3/../../../arm-none-eabi/bin/ld: region `flash0' overflowed by 64 bytes
collect2: error: ld returned 1 exit status
../../tmk_core/tool/chibios/chibios/os/common/ports/ARMCMx/compilers/GCC/rules.mk:238: recipe for target 'build/ch.elf' failed
make: *** [build/ch.elf] Error 1

[flabbergast]

Could you please specify also which chibios are you using? (I.e. which commit from which branch from whom)?
{It works for me, so trying to find out what's the difference. The compiler won't matter, the isr sections should have fixed size, 0xc0, which should be exactly the same size as the flash0 section.}

[fillchiam]

flabbergast: I'm using your branch, which is linked from the TMK GitHub:
https://github.com/flabbergast/ChibiOS/tree/kinetis

[fillchiam]

The branch is kinetis. And I used the latest commit, f30aea7761b5273b7ec768455fe4c2462e964b59, from 24 days ago. I downloaded the zip.

[phosphorglow]

@tentator :

I have a theory...

Disable PS/2 mouse support in the makefile, and set the debounce back to 5.

Try typing on it, and see if you still get missed keys. I'm willing to bet you won't.

I believe the issue has something to do with the way the polling rate works in combination with the PS/2 mouse code, but that's getting beyond my current understanding. What MCU are you using, by the way...?

[flabbergast]

@fillchiam: Thanks. At least I'm not getting the same error but only on linux. Mac is still fine. It's a chibios problem (I mean i'm getting the same error for chibios demos, no TMK). Will investigate.

[flabbergast]

@fillchiam: Pushed another commit (to chibios/kinetis), increasing the flash0 section size. It should work now. I do not understand where does the error come from - the _vectors section is reported to have the correct size 0xC0, but the linker thinks it's 0x100. No idea why.

[fillchiam]

@flabbergast: Thanks a lot! Sadly, it gives the exact same error, for some reason. Overflowed by 64 bytes.

Code: Select all

william@Malkav:~/Downloads/tmk_keyboard-master/keyboard/teensy_lc_onekey$ make
Compiler Options
arm-none-eabi-gcc -c -mcpu=cortex-m0plus -O2 -ggdb -fomit-frame-pointer -falign-functions=16 -std=gnu99 -DPROTOCOL_CHIBIOS -ffunction-sections -fdata-sections -fno-common -flto -include config.h -Wall -Wextra -Wundef -Wstrict-prototypes -Wno-missing-field-initializers -Wa,-alms=build/lst/ -DCORTEX_USE_FPU=FALSE -DBOOTMAGIC_ENABLE -DMOUSEKEY_ENABLE -DMOUSE_ENABLE -DEXTRAKEY_ENABLE -DCONSOLE_ENABLE -DCOMMAND_ENABLE -DNKRO_ENABLE -DSLEEP_LED_ENABLE -DNO_SUSPEND_POWER_DOWN -DVERSION=unknown -DTHUMB_PRESENT -mno-thumb-interwork -DTHUMB_NO_INTERWORKING -MD -MP -MF .dep/build.d -I. -I../../tmk_core/tool/chibios/chibios/os/common/ports/ARMCMx/compilers/GCC -I../../tmk_core/tool/chibios/chibios/os/common/ports/ARMCMx/devices/KL2x -I../../tmk_core/tool/chibios/chibios/os/ext/CMSIS/include -I../../tmk_core/tool/chibios/chibios/os/ext/CMSIS/KINETIS -I../../tmk_core/tool/chibios/chibios/os/rt/include -I../../tmk_core/tool/chibios/chibios/os/rt/ports/ARMCMx -I../../tmk_core/tool/chibios/chibios/os/rt/ports/ARMCMx/compilers/GCC -I../../tmk_core/tool/chibios/chibios/os/hal/osal/rt -I../../tmk_core/tool/chibios/chibios/os/hal/include -I../../tmk_core/tool/chibios/chibios/os/hal/ports/common/ARMCMx -I../../tmk_core/tool/chibios/chibios/os/hal/ports/KINETIS/KL2x -I../../tmk_core/tool/chibios/chibios/os/hal/ports/KINETIS/LLD -I../../tmk_core/tool/chibios/chibios/os/hal/boards/PJRC_TEENSY_LC -I../../tmk_core/tool/chibios/chibios/os/hal/lib/streams -I../../tmk_core/tool/chibios/chibios/os/various -I../../tmk_core -I../../tmk_core/common -I../../tmk_core/protocol/chibios -I../../tmk_core/protocol -I. main.c -o main.o

Compiling crt0_v6m.s
Compiling chcoreasm_v6m.s
Compiling crt1.c
Compiling vectors.c
Compiling chsys.c
Compiling chdebug.c
Compiling chvt.c
Compiling chschd.c
Compiling chthreads.c
Compiling chdynamic.c
Compiling chregistry.c
Compiling chsem.c
Compiling chmtx.c
Compiling chcond.c
Compiling chevents.c
Compiling chmsg.c
Compiling chmboxes.c
Compiling chqueues.c
Compiling chmemcore.c
Compiling chheap.c
Compiling chmempools.c
Compiling chcore.c
Compiling chcore_v6m.c
Compiling osal.c
Compiling hal.c
Compiling st.c
Compiling hal_buffers.c
Compiling hal_queues.c
Compiling hal_mmcsd.c
Compiling pal.c
Compiling usb.c
Compiling nvic.c
Compiling hal_lld.c
Compiling pal_lld.c
Compiling serial_lld.c
Compiling i2c_lld.c
Compiling ext_lld.c
Compiling adc_lld.c
Compiling gpt_lld.c
Compiling pwm_lld.c
Compiling st_lld.c
Compiling usb_lld.c
Compiling board.c
Compiling chprintf.c
Compiling usb_main.c
Compiling main.c
Compiling keymap_plain.c
Compiling matrix.c
Compiling led.c
Compiling host.c
Compiling keyboard.c
Compiling action.c
../../tmk_core/common/action.c: In function 'debug_event':
../../tmk_core/common/action.c:546:29: warning: unused parameter 'event' [-Wunused-parameter]
 void debug_event(keyevent_t event)
                             ^
Compiling action_tapping.c
Compiling action_macro.c
Compiling action_layer.c
Compiling action_util.c
Compiling keymap.c
Compiling print.c
Compiling debug.c
Compiling util.c
Compiling suspend.c
Compiling printf.c
Compiling timer.c
Compiling bootloader.c
Compiling bootmagic.c
Compiling eeconfig.c
Compiling mousekey.c
Compiling command.c
Compiling sleep_led.c
Linking build/ch.elf
/usr/lib/gcc/arm-none-eabi/4.9.3/../../../arm-none-eabi/bin/ld: build/ch.elf section `.isr' will not fit in region `flash0'
/usr/lib/gcc/arm-none-eabi/4.9.3/../../../arm-none-eabi/bin/ld: region `flash0' overflowed by 64 bytes
collect2: error: ld returned 1 exit status
../../tmk_core/tool/chibios/chibios/os/common/ports/ARMCMx/compilers/GCC/rules.mk:238: recipe for target 'build/ch.elf' failed
make: *** [build/ch.elf] Error 1