]> git.donarmstrong.com Git - qmk_firmware.git/blobdiff - docs/porting_your_keyboard_to_qmk_(arm_and_other_chibios_cpus).md
Port DIRECT_PINS from split_common/matrix.c to matrix.c (#5091)
[qmk_firmware.git] / docs / porting_your_keyboard_to_qmk_(arm_and_other_chibios_cpus).md
index 50d291a2300f976e3e453a79f78e2df1ae06b86b..d8e084f466ccd84f3b0862565fad5c8b113138e1 100644 (file)
@@ -22,6 +22,8 @@ The `MATRIX_ROW_PINS` and `MATRIX_COL_PINS` are the pins your MCU uses on each r
 
 For the `DIODE_DIRECTION`, most hand-wiring guides will instruct you to wire the diodes in the `COL2ROW` position, but it's possible that they are in the other - people coming from EasyAVR often use `ROW2COL`. Nothing will function if this is incorrect.
 
+To configure a keyboard where each switch is connected to a separate pin and ground instead of sharing row and column pins, use `DIRECT_PINS`. The mapping defines the pins of each switch in rows and columns, from left to right. Must conform to the sizes within `MATRIX_ROWS` and `MATRIX_COLS`, use `NO_PIN` to fill in blank spaces. Overrides the behaviour of `DIODE_DIRECTION`, `MATRIX_ROW_PINS` and `MATRIX_COL_PINS`.
+
 `BACKLIGHT_PIN` is the pin that your PWM-controlled backlight (if one exists) is hooked-up to. Currently only B5, B6, and B7 are supported.
 
 `BACKLIGHT_BREATHING` is a fancier backlight feature that adds breathing/pulsing/fading effects to the backlight. It uses the same timer as the normal backlight. These breathing effects must be called by code in your keymap.
@@ -54,10 +56,10 @@ This is where all of the custom logic for your keyboard goes - you may not need
 
 ## `/keyboards/<keyboard>/<keyboard>.h`
 
-Here is where you can (optionally) define your `KEYMAP` function to remap your matrix into a more readable format. With ortholinear boards, this isn't always necessary, but it can help to accommodate the dead spots on your matrix, where there are keys that take up more than one space (2u, staggering, 6.25u, etc). The example shows the difference between the physical keys, and the matrix design:
+Here is where you can (optionally) define your `LAYOUT` function to remap your matrix into a more readable format. With ortholinear boards, this isn't always necessary, but it can help to accommodate the dead spots on your matrix, where there are keys that take up more than one space (2u, staggering, 6.25u, etc). The example shows the difference between the physical keys, and the matrix design:
 
 ```
-#define KEYMAP( \
+#define LAYOUT( \
     k00, k01, k02, \
       k10,  k11   \
 ) \