commit
36da21b8e3
4 changed files with 7 additions and 1 deletions
BIN
docs/docs/assets/pro-micro/pro-micro-pins-labelled.jpg
Normal file
BIN
docs/docs/assets/pro-micro/pro-micro-pins-labelled.jpg
Normal file
Binary file not shown.
After Width: | Height: | Size: 113 KiB |
|
@ -59,4 +59,4 @@ If this config does not work for you, try the flavor "tap-preferred" and a short
|
||||||
If you want to use a tap-hold with a keycode from a different code page, you have to define another behavior with another "bindings" parameter.For example, if you want to use SHIFT and volume up, define the bindings like `bindings = <&kp>, <&cp>;`. Only single-argument behaviors are supported at the moment.
|
If you want to use a tap-hold with a keycode from a different code page, you have to define another behavior with another "bindings" parameter.For example, if you want to use SHIFT and volume up, define the bindings like `bindings = <&kp>, <&cp>;`. Only single-argument behaviors are supported at the moment.
|
||||||
|
|
||||||
#### Note
|
#### Note
|
||||||
Astute readers may notice similarities between the possible behaviors in ZMK and other firmware, such as QMK. The hold-preferred flavor works similar to the `HOLD_ON_OTHER_KEY_PRESS` setting. The 'balanced' flavor is similar to the `PERMISSIVE_HOLD` setting, and the `tap-preferred` flavor is similar to `IGNORE_MOD_TAP_INTERRUPT`.
|
Astute readers may notice similarities between the possible behaviors in ZMK and other firmware, such as QMK. The hold-preferred flavor works similar to the `HOLD_ON_OTHER_KEY_PRESS` setting. The 'balanced' flavor is similar to the `PERMISSIVE_HOLD` setting, and the `tap-preferred` flavor is similar to `IGNORE_MOD_TAP_INTERRUPT`.
|
||||||
|
|
|
@ -35,6 +35,8 @@ in the `app/boards/${arch}/${board_name}` directory, e.g. `app/boards/arm/planck
|
||||||
|
|
||||||
## Pro Micro Compatible Keyboard
|
## Pro Micro Compatible Keyboard
|
||||||
|
|
||||||
|
![Labelled Pro Micro pins](assets/pro-micro/pro-micro-pins-labelled.jpg)
|
||||||
|
|
||||||
For keyboards that require a (usually Pro Micro compatible) add-on board to operate, the ZMK integration pieces are places
|
For keyboards that require a (usually Pro Micro compatible) add-on board to operate, the ZMK integration pieces are places
|
||||||
in the _shield_ definition for that keyboard, allowing users to
|
in the _shield_ definition for that keyboard, allowing users to
|
||||||
swap in different Pro Micro compatible boards (e.g. Proton-C, or nice!nano) and build a firmware the matches their actual
|
swap in different Pro Micro compatible boards (e.g. Proton-C, or nice!nano) and build a firmware the matches their actual
|
||||||
|
|
|
@ -64,6 +64,10 @@ endif
|
||||||
|
|
||||||
## Shield Overlay
|
## Shield Overlay
|
||||||
|
|
||||||
|
![Labelled Pro Micro pins](assets/pro-micro/pro-micro-pins-labelled.jpg)
|
||||||
|
|
||||||
|
ZMK uses the green color coded pin names to generate devicetree node references. For example, to refer to the node `D0` in the devicetree files, use `&pro_micro_d 0` or to refer to `A1`, use `&pro_micro_a 1`.
|
||||||
|
|
||||||
The `<shield_name>.overlay` is the devicetree description of the keyboard shield that is merged with the primary board devicetree description before the build. For ZMK, this file at a minimum should include the [chosen]() node named `zmk,kscan` that references a KSCAN driver instance. For a simple 3x3 macropad matrix,
|
The `<shield_name>.overlay` is the devicetree description of the keyboard shield that is merged with the primary board devicetree description before the build. For ZMK, this file at a minimum should include the [chosen]() node named `zmk,kscan` that references a KSCAN driver instance. For a simple 3x3 macropad matrix,
|
||||||
this might look something like:
|
this might look something like:
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue