deskthority

@fillchiam: Right, sorry. I fixed it in the chibios ld scripts, but the Teensy LC onekey example uses its own custom ld script (because it's needed for the bootmagic), so please edit the file 'teensy_lc_onekey/ld/MKL26Z64.ld' and change the '0xc0' on the line with 'flash0' to '0x100'. This should do it. I will fix this in the TMK repo as well but it might take a bit for hasu to pull the changes into the official one.

@flabbergast: Oh! Yay, it works! Thank you so, so much! I felt totally lost when it didn't work at first, this is kind of my first adventure with microcontrollers.

Hello everyone!

This is my first post here. I've been trying to make my keyboard work for the past two days -- to no avail.

At this point, I suspect the issue is firmware and not hardware. I've ran over the board with a multimeter several dozen times and was unable to detect any shorts. I also tested each individual key, and they all work.

The issue is that only some of the keys work, and the others produce incorrect keys -- keys that don't even exist in the keymap. How can that be? For example, I currently have the keymap set to all "A". No other keys -- just the letter "A".

The working keys (ones that previously produced what I expected) now produce "a", but the weird keys consistently produce "f", "d", "b", "e", "r", "\n", or "8" and some do things I don't expect, like open the Windows "Run" dialog.

Am I crazy? I really, truly, deeply appreciate any assistance or tips you can give me. Thanks a ton in advance!

Pastbin of my firware edits - http://pastebin.com/1r4JggnL

Pin matrix image - http://imgur.com/MTywrPI

Photo of my crappy soldering - http://i.imgur.com/3nFdZRo.jpg

I *think* I see the issue:
A missing backslash after KEYMAP(
EDIT:
Nevermind, I suppose that's just for readability.

Thanks for the reply Phosphorglow. Well, I tried it out before I saw your edit, and yeah, no change

I do appreciate it though!

Wow... okay, so, I added some debugging to keymap_common.c:
And rows and columns were exactly as I hoped they would be, but the LAYER was always set to 6. I only have one layer in my keymap_poker.c... so not sure where "6" came from.

When I replace "&keymaps[(layer)]" with "&keymaps[(0)]" it works as it should.

Is this a bug? Should I file it on github, or are layers defined somewhere else?

It is possible to set the default layer through bootmagic in EEPROM. So it may be that you have something in EEPROM that sets the default layer to 6 (which is indeed strange, because the layer is indicated by the corresponding bit in the 'layer' variable, and 6=0b110).
Anyways, please make sure that you have bootmagic disabled.

A user on Reddit thought that it might have been Boot Magic as well -- I guess I don't understand how it'd get six layers if I only have one in my keymap. I'm going to attempt to clear bootmagic settings and I'll report back. Thank you very much for the reply!

Yup. Clearing Boot Magic with SPACE + BACKSPACE reset the default layer to 0. I don't know what I did, or how I did it, but here's to hoping it doesn't happen again. Thanks again for your reply.

Good that it worked! (For testing, I meant to disable it in the Makefile so that it definitely won't come into play.)
Some explanation: the EEPROM does *not* normally get erased when programming, and TMK expects the layer information at a certain address in EEPROM. So if something's there, TMK will simply load it into the 'default_layer' variable. It seems that you had some leftover stuff in the EEPROM.
{There is a mechanism to prevent this from happening, namely there is a 'magic number' stored at some address in EEPROM as well; if it matches, TMK assumes that it's *it* that wrote the remaining data as well. If it doesn't match, it assumes that the data in EEPROM is not valid. So in your case, for some strange reason, you had both the magic number and the (wrong) layer information there.}

While I was groggily waking up the image of the Teensy came to mind and I wondered if it had been used for something previously... ;P

Nicely solved!

just to follow-up about my question about debounce: thanks to phosphorglow I just discovered a plausible reason for the debounce to be set so low in my firmware. Basically if I disable ps2 then debounce of 5 works again fine, with ps2 mouse support turned on instead it seems not to be able to cope with 5 but needs debounce set to 1..
So what I understand from the code is that a reason might be because the ps2 routine is time consuming so it will go back on the debounce routine loop too late and there will be some wrong keys eaten up by the debounce routine itself!
One should always adapt the debounce value by lovering it, if ps2 mouse is turned on.. at least as usart..
FYI
So my next step is how to be able to use two ps2 with one teensy, if you have suggestions..

tent:wq

any guidance in making my keymap ISO Spanish?

Scottex wrote: any guidance in making my keymap ISO Spanish?

Manuel!!!!!!

(Sorry, couldn't resist.)

Use the ISO keymap in TMK and make sure your OS is set to spanish.
A keyboard controller doesn't map different languages, it only sends scancodes (meant for a key, not a character/function). The OS interpretes them.

The reason people are changing the keymap to their needs is, they don't use standard layouts and/or don't want to change OS settings along different computers.

hbar wrote: Manuel!!!!!!

(Sorry, couldn't resist.)

No worries man
Also I don't think Manuel is that common of a name in Spain (only know 1 person named like that), Jose on the other hand is one of the most heard names around here

Ray wrote: Use the ISO keymap in TMK and make sure your OS is set to spanish.
A keyboard controller doesn't map different languages, it only sends scancodes (meant for a key, not a character/function). The OS interpretes them.

The reason people are changing the keymap to their needs is, they don't use standard layouts and/or don't want to change OS settings along different computers.

Oh nice, and here i was thinking i was going to had to put in new scancodes in some obscure library

i'm getting this error when doing make:
make: *** [obj_gh60_lufa/keymap_poker.o] Error -1073741502

Any clues?

That's very likely not the actual error message. Could you please post the whole output (make clean; make) maybe to pastebin, and some info (windows? version? avr-gcc?).

flabbergast wrote: That's very likely not the actual error message. Could you please post the whole output (make clean; make) maybe to pastebin, and some info (windows? version? avr-gcc?).

http://pastebin.com/dtsEaX7Z
i made a make clean and then make
windows 8.1 64bit
winavr 20100110 (avr-gcc 4.3.3 )

Thanks! It's this: https://github.com/tmk/tmk_keyboard/issues/99
(EDIT: not just based on the fact that you use winavr, but I've seen these kind of error before ("fork: resource temporarily available") and it was a problem with winavr.)

flabbergast wrote: Thanks! It's this: https://github.com/tmk/tmk_keyboard/issues/99
(EDIT: not just based on the fact that you use winavr, but I've seen these kind of error before ("fork: resource temporarily available") and it was a problem with winavr.)

Thanks to you
So I just download, let's say Inferno Embedded AVR Tools, and make clean and make?
or do i have to uninstall winavr?

Please try to remove/uninstall as much of winavr as possible (I've been sorting out a problem with compiling a firmware for ARM (so not actually AVR) for another DT user, and it turned out that the reason it wasn't working is that he's left winavr installed, and also in the PATH, so some of the programs common to all toolchain suites (e.g. 'make', 'grep', and such) were used from the old WinAVR installation, instead of the new ARM toolchain. Problems. Just 'inexplicable' problems, with mysterious error messages.).

Ok, so the keyboard is working almost flawlessly
The only weird thing is that the caps lock activates a whole column, and not even his column
and after activating this column the keyboard goes crazy
the funny thing is that i've replaced the caps lock for A in the keymap (there are two A's in the keymap) and the key works well
i'm using CAPS for caps lock, maybe it's not that what i have to use?
maybe i'm missing some configuration flag?

problem solved!!!!
i missed the led.c file, commenting all inside the led_set fixed the problem

Ray wrote: https://github.com/3ner/tmk_keyboard.git

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

Thanks a lot Ray, I got the trackpoint to work exactly as I need it last night. Outside of my keyboard's directory, the files I took over from your code are, according to git:

modified: ../../tmk_core/common/action.c
modified: ../../tmk_core/common/action_code.h
modified: ../../tmk_core/common/action_layer.c
modified: ../../tmk_core/protocol/ps2_mouse.c
modified: ../../tmk_core/protocol/ps2_mouse.h

Apart from the hardcoded mouse layer (5), I don't think this code is at all bad. Do you see any chance of it making it into mainstream tmk? A pull request at some point maybe?

hasu is considering adding generic hooks to the main code, hopefully enough of them so that one can implement this kind of stuff without having to do specific modifications to the core TMK code.
https://github.com/tmk/tmk_keyboard/issues/304
Ray, hbar: do you think it's possible to do your stuff with these hooks? (Quite possibly more hooks will be needed for the PS/2/mouse code; I don't have any experience with these.)

I am not sure if I understand the concept of the hooks.

My assumption right now is, there's function calls in the main code that call (for now) empty functions that one can replace with custom code?

For the layer-switching by time when the trackpoint is moved, a hook into ps2_mouse_task() in tmk_core/protocol/ps2_mouse.c together with access to mouse_report would be sufficient.

My code for deactivating the mouselayer when a non-mousebutton, non-modifier is pressed is in a distinct place in a switch-case (I remember that was hard to find) in tmk_core/common/action.c. It may still be done in another place but the check if such a key is pressed might be more complicated (I seriously don't remember what that line is comparing, hasu got me in the right direction first).

I also hacked the mousekey feature in a way that is not very clean (global variable and stuff), but it got me the functionality I was looking for.
I don't know what a good way of sending a mousebutton event from a keypress would be. I saw there was one already in place and hacked that. So I have no clue whether it can be done in a clean way with the generic hooks hasu might be providing.

hbar wrote: Apart from the hardcoded mouse layer (5), I don't think this code is at all bad. Do you see any chance of it making it into mainstream tmk? A pull request at some point maybe?

I don't see how more people want that functionality of switching a layer when moving the cursor and falling back after some time. If hasu thinks differently on that, I can make a clean commit containing only these changes (I was/am new to git and didn't want to look into it).

The rest of my changes (the hack mentioned a post above) should be redone by someone who knows how it should be done. Well, I could probably do that if someone guides me through that stuff.

Started my macro pad the other day using this guide, and I can get so painfully close to the end, but am stuck with this terminal error that Ive never seen before!

Can anyone give this particular file a glance and see what's awry?

Thank you for any help

I think you were missing one backslash. Try this.