Mapping a Teensy key

[jsborjesson]

Hello! I'm trying to create a key that acts like the little reset-button on the teensy board, I see this mentioned in lots of places but I can't find anywhere that describes how to do it - could someone please point me in the right direction?

Cheers

[jackhumbert]

The RESET keycode will do just this, as long as your bootloader is set to the right size in your Makefile!

[jsborjesson]

Hmmm, there is something else I'm doing wrong too I guess - I'm not sure what the correct size is for the ErgoDox EZ, I tried all the different ones but the button always has the same behaviour - killing the keyboard so you have to plug it out and back in again for any key to work.

EDIT: It's the same if I change one of the supposedly correct default layouts too, so it doesn't seem like I screwed something up in my own layout.

[jackhumbert]

It should be 512 for the EZ, but the behaviour you described sounds exactly like what the reset button does :) does it not show up in the Teensy Loader?

[jsborjesson]

Perhaps I'm asking for the wrong thing, the button I mean is the one you press when you reprogram it, every time I change the layout I do make clean && make teensy ..., then after a bunch of log output it halts and asks me to press the reset button, then I stick a little paperclip through the hole in the upper right corner and it moves on. If I program it once using the paperclip (because the button obviously isn't mapped yet) and then again trying it with the button mapped to RESET it still just kills all the buttons and the process is still halted. Is there anything else I could be missing?

[jackhumbert]

That should be the same as the button - I'm not sure why it wouldn't trigger the same signal.

@ezuk is this anything you've seen before?

[jsborjesson]

Same behaviour when using the Teensy GUI, so it doesn't seem like there is anything isolated to using the make teensy command

[ezuk]

hmm, someone else mentioned something similar. Not a hardware issue obviously because the reset button works fine... any way we can trace this in firmware @jackhumbert ?

[jackhumbert]

Here's some more info on jumping into the bootloader, which is referenced here as not working with the LUFA stack (what QMK uses).

There's also a discussion about it last year - I haven't been able to try it yet, but it looks like these changes would work. I'd be happy to merge in those changes with a TEENSY flag (saving folks from modifying the bootloader location as well).

[mfilej]

@jackhumbert I'd be interested in that change 😄

[aspickard]

+1

[aspickard]

@jackhumbert I was able to test the changes with an original dox and it worked fine. Let me know if you'd like me to make a pull request.

[Rovanion]

@aspickard Could you provide a diff for the changes you made? Reason why I'm asking is because I'm unsure which file to modify.

And beyond that I think it's totally fine for you to open up a PR since jack explicitly states that he'd be happy to merge such a change.

[mfilej]

I'd love to see that diff as well because I'm not confident enough to make the change myself. 😄

[aspickard]

@Rovanion @mfilej I'll try to have something up for you guys very soon.

[Rovanion]

Thank you @aspickard, it's greatly appriciated!

[aspickard]

@Rovanion @mfilej Here you go! https://github.com/jackhumbert/qmk_firmware/pull/160/files

Lmk if there are any issues/improvements.

[Rovanion]

Thank you @aspickard, found that what was really missing was a declaration of which controller the ergodox ez is using in it's config.h. As of such the diff can be reduced to what's in PR #162.

I'd be great if some of you could test the change on your device. But it seems to be working on my end.

[mfilej]

Works for me! Seems #162 is enough but thank you both for sharing the patches 💖

[jackhumbert]

Closing this as it's been narrowed down to the problem described in #164.