geekhack
geekhack Projects => Making Stuff Together! => Topic started by: emenelopee on Wed, 31 January 2018, 21:10:05
-
I've been using kbfirmware to generate my teensy firmware - looking for advice on how to get into direct editing of the code so I can mess with the guts a little more: What's the goto for step-by-step instructions to edit the code directly?
EDIT: follow-up question: what are the benefits of getting into the weeds of QMK that kbfirmware doesn't cover?
-
What's the goto for step-by-step instructions to edit the code directly?
Assuming that you have already downloaded the source, the files you might wanna look into are config.h, your header file (kb.h when downloading from kbfirmware.com) and the keymaps.
The real deal is in the header file as you can add multiple layout supports which are then implemented by the keymap files.
A straightforward example of that is the code for the XMMX and the Toad (https://github.com/qmk/qmk_firmware/tree/master/keyboards/xmmx) which share the same matrix and therefore use the same firmware. You can find more info about those in my signature.
what are the benefits of getting into the weeds of QMK that kbfirmware doesn't cover?
Basically implementing other features. For example, if you have shift registers in your keyboard, you need a custom matrix.c file as in the Pegasus Hoof (https://github.com/qmk/qmk_firmware/blob/master/keyboards/pegasushoof/matrix.c).
-
Looking at your Toad code and my kbfirmware generated one I don't see much of a difference other than a bunch of redundant layer code kbfirmware generates (KC_TRNS on about a thousand or so placeholder layers I haven't programmed).
I'm not clued up on what shift registers are - I guess the question is: what are the limitations of kbfirmware that I, for a fairly standard keyboard with only one FN layer and no programmable lighting, would want to edit and compile the code manually?
-
Looking at your Toad code and my kbfirmware generated one I don't see much of a difference other than a bunch of redundant layer code kbfirmware generates (KC_TRNS on about a thousand or so placeholder layers I haven't programmed).
The only difference is that you would need a different config file (json) for each layout with the kbfirmware tool, while a manually edited source wouldn't.
what are the limitations of kbfirmware?
Implementing your own code, for whatever reason, might be harder without direct access to the code.
for a fairly standard keyboard with only one FN layer and no programmable lighting, would want to edit and compile the code manually?
Not really. That online tool has everything you need for that.
-
Great, thanks, that's exactly what I needed. One layout, nothing fancy, I'll stick with kbfirmware. Kudos to the developer - what a timesaver and democratizer of this whole custom kb scene!