summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--docs/hand_wire.md21
1 files changed, 14 insertions, 7 deletions
diff --git a/docs/hand_wire.md b/docs/hand_wire.md
index 1cbc16dfea..ba2eee7125 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