diff options
| -rw-r--r-- | docs/hand_wire.md | 21 |
1 files changed, 14 insertions, 7 deletions
diff --git a/docs/hand_wire.md b/docs/hand_wire.md index 1cbc16dfe..ba2eee712 100644 --- a/docs/hand_wire.md +++ b/docs/hand_wire.md @@ -185,6 +185,13 @@ When you're done with the columns, start with the rows in the same process, from As you move along, be sure that the Teensy is staying in place - recutting and soldering the wires is a pain! +## Additional guides + +If you're more of a visual learner, or want some additional tips and something more to follow along, these two visual step by step guides may be helpful: + +- [BrownFox's step by step guide](https://deskthority.net/viewtopic.php?f=7&t=6050) +- [Cribbit's modern hand wiring guide](https://geekhack.org/index.php?topic=87689.0) + # Getting Some Basic Firmware Set Up From here, you should have a working keyboard once you program a firmware. Before we attach the Teensy permanently to the keyboard, let's quickly get some firmware loaded onto the Teensy so we can test each keyswitch. @@ -231,10 +238,10 @@ This can be described by saying the top row is 3 1u keys, and the bottom row is └─────┴─────┘ ``` -The middle column is unused on the bottom row in this example. Our `KEYMAP` definition would look like this: +The middle column is unused on the bottom row in this example. Our `LAYOUT` definition would look like this: ``` - #define KEYMAP( \ + #define LAYOUT( \ k00, k01, k02, \ k10, k11, \ ) \ @@ -256,10 +263,10 @@ Let's say that instead, we wired our keyboard like this (a fair thing to do): └─────┴─────┘ ``` -This would require our `KEYMAP` definition to look like this: +This would require our `LAYOUT` definition to look like this: ``` - #define KEYMAP( \ + #define LAYOUT( \ k00, k01, k02, \ k10, k11, \ ) \ @@ -269,7 +276,7 @@ This would require our `KEYMAP` definition to look like this: } ``` -Notice how the `k11` and `KC_NO` switched places to represent the wiring, and the unused final column on the bottom row. Sometimes it'll make more sense to put a keyswitch on a particular column, but in the end, it won't matter, as long as all of them are accounted for. You can use this process to write out the `KEYMAP` for your entire keyboard - be sure to remember that your keyboard is actually backwards when looking at the underside of it. +Notice how the `k11` and `KC_NO` switched places to represent the wiring, and the unused final column on the bottom row. Sometimes it'll make more sense to put a keyswitch on a particular column, but in the end, it won't matter, as long as all of them are accounted for. You can use this process to write out the `LAYOUT` for your entire keyboard - be sure to remember that your keyboard is actually backwards when looking at the underside of it. ### `keymaps/<variant>/default.c` @@ -291,7 +298,7 @@ This can be accomplished by using the following `keymaps` definition: ``` const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = { - [0] = KEYMAP( /* Base */ + [0] = LAYOUT( /* Base */ KC_A, KC_1, KC_H, \ KC_TAB, KC_SPC \ ), @@ -300,7 +307,7 @@ const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = { Note that the layout of the keycodes is similar to the physical layout of our keyboard - this make it much easier to see what's going on. A lot of the keycodes should be fairly obvious, but for a full list of them, check out [Keycodes](keycodes.md) - there are also a lot of aliases to condense your keymap file. -It's also important to use the `KEYMAP` function we defined earlier - this is what allows the firmware to associate our intended readable keymap with the actual wiring. +It's also important to use the `LAYOUT` function we defined earlier - this is what allows the firmware to associate our intended readable keymap with the actual wiring. ## Compiling Your Firmware |