Quick doc update.
This commit is contained in:
CrossR
parent
c4ac722858
commit
3f74814379
|
|
@ -8,11 +8,11 @@ title: Boards, Shields, and Keymaps
|
|||
The foundational elements needed to get a specific keyboard working with ZMK can be broken down into:
|
||||
|
||||
- A [KSCAN driver](https://docs.zephyrproject.org/2.3.0/reference/peripherals/kscan.html), which uses `compatible="zmk,kscan-gpio-matrix"` for GPIO matrix based keyboards, or uses `compatible="zmk,kscan-gpio-direct"` for small direct wires.
|
||||
- An optional matrix transform, which defines how the KSCAN row/column events are translated into logical "key positions". This is required for non-rectangular keyboards/matrixes, where the key positions don't naturally follow the row/columns from the GPIO matrix.
|
||||
- An optional matrix transform, which defines how the KSCAN row/column events are translated into logical "key positions". This is required for non-rectangular keyboards/matrices, where the key positions don't naturally follow the row/columns from the GPIO matrix.
|
||||
- A keymap, which binds each key position to a behavior, e.g. key press, mod-tap, momentary layer, in a set of layers.
|
||||
|
||||
These three core architectural elements are defined per-keyboard, and _where_ they are defined depeneds on the specifics of how that
|
||||
keyboard works. For an overview on the general concepts of boards and shields, please see the [FAQs on boards and sheilds](/docs/faq#why-boards-and-shields--why-not-just-keyboard).
|
||||
These three core architectural elements are defined per-keyboard, and _where_ they are defined depends on the specifics of how that
|
||||
keyboard works. For an overview on the general concepts of boards and shields, please see the [FAQs on boards and shields](/docs/faq#why-boards-and-shields--why-not-just-keyboard).
|
||||
|
||||
## Self-Contained Keyboard
|
||||
|
||||
|
|
|
|||
|
|
@ -11,14 +11,14 @@ The high level steps are:
|
|||
- Create a new shield directory.
|
||||
- Add the base Kconfig files.
|
||||
- Add the shield overlay file to define the [KSCAN driver]() for detecting key press/release.
|
||||
- (Optional) Add the mateix transform for mapping KSCAN row/coluk values to sane key positions. This is needed for non-rectangular keyboards, or where the underlying row/column pin arrangement does not map one to one with logical locations on the keyboard.
|
||||
- (Optional) Add the matrix transform for mapping KSCAN row/column values to sane key positions. This is needed for non-rectangular keyboards, or where the underlying row/column pin arrangement does not map one to one with logical locations on the keyboard.
|
||||
- Add a default keymap, which users can override in their own configs as needed.
|
||||
|
||||
It may be helpful to review the upstream [shields documentation](https://docs.zephyrproject.org/2.3.0/guides/porting/shields.html#shields) to get a proper understanding of the underlying system before continuing.
|
||||
|
||||
## New Shield Directory
|
||||
|
||||
Shields for Zephyr applications go into the `boards/shields/` directory; since ZMK's Zephyr appliction linves in the `app/` subdirectory of the repository, that means the new shield directory should be:
|
||||
Shields for Zephyr applications go into the `boards/shields/` directory; since ZMK's Zephyr application lives in the `app/` subdirectory of the repository, that means the new shield directory should be:
|
||||
|
||||
```bash
|
||||
mkdir app/boards/shields/<keyboard_name>
|
||||
|
|
@ -60,7 +60,7 @@ endif
|
|||
|
||||
## Shield Overlay
|
||||
|
||||
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 minumum should include the [chosen]() node named `zmk,kscan` that refernces 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:
|
||||
|
||||
```
|
||||
|
|
@ -97,7 +97,7 @@ Internally ZMK translates all row/column events into "key position" events to ma
|
|||
1. For non rectangular keyboards with thumb clusters, non `1u` locations, etc.
|
||||
|
||||
A "key position" is the numeric index (zero-based) of a given key, which identifies
|
||||
the logical key location as percieved by the end user. All _keymap_ mappings actually bind behaviors to _key positions_, not to row/column values.
|
||||
the logical key location as perceived by the end user. All _keymap_ mappings actually bind behaviors to _key positions_, not to row/column values.
|
||||
|
||||
_Without_ a matrix transform, that intentionally map each key position to the row/column pair that position corresponds to, the default equation to determine that is:
|
||||
|
||||
|
|
@ -141,13 +141,13 @@ RC(7,0) RC(7,1) RC(7,2) RC(7,3) RC(7
|
|||
|
||||
Some important things to note:
|
||||
|
||||
- The `#include <dt-bindings/zmk/matrix-transform.h>` is critical. The `RC` macro is used to generate the interanl storage in the matrix transform, and is actually replaced by a C preprocessor before the final devicetree is compiled into ZMK.
|
||||
- The `#include <dt-bindings/zmk/matrix-transform.h>` is critical. The `RC` macro is used to generate the internal storage in the matrix transform, and is actually replaced by a C preprocessor before the final devicetree is compiled into ZMK.
|
||||
- `RC(row, column)` is placed sequentially to define what row and column values that position corresponds to.
|
||||
- If you have a keyboard with options for `2u` keys in certain positions, or break away portions, it is a good idea to set the chosen `zmk,matrix_transform` to the default arrangement, and include _other_ possible matrix transform nodes in the devicetree that users can select in their user config by overriding the chosen node.
|
||||
|
||||
## Default Keymap
|
||||
|
||||
Each keyboard should provide an OOTB default keymap to be used when building the firmware, which can be overriden and customized by user configs. For "shield keyboards", this should be placed in the `app/boards/shields/<shield_name>/keymap/keymap.overlay` file. The keymap is configured as an additional devicetree overlay that includes the following:
|
||||
Each keyboard should provide an OOTB default keymap to be used when building the firmware, which can be overridden and customized by user configs. For "shield keyboards", this should be placed in the `app/boards/shields/<shield_name>/keymap/keymap.overlay` file. The keymap is configured as an additional devicetree overlay that includes the following:
|
||||
|
||||
- A node with `compatible="zmk,layers"` where each child node is a layer with a `bindings` array that binds each key position to a given behavior (e.g. key press, momentarily layer, etc).
|
||||
- A node with `compatible="zmk,keymap"` that references the layers with a `layers` phandle-array property.
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ flowing into the handler functions.
|
|||
|
||||
## Prerequisites
|
||||
|
||||
In order to build targetting the `native_posix` board, you need to setup your system
|
||||
In order to build targeting the `native_posix` board, you need to setup your system
|
||||
with a compiler that can target 32-bit POSIX.
|
||||
|
||||
On Debian, you can do this with:
|
||||
|
|
@ -21,7 +21,7 @@ apt install -y gcc-multilib
|
|||
|
||||
## Building
|
||||
|
||||
To do this, you can build ZMK targetting the
|
||||
To do this, you can build ZMK targeting the
|
||||
`native_posix` board.
|
||||
|
||||
```
|
||||
|
|
@ -36,4 +36,4 @@ Once built, you can run the firmware locally:
|
|||
|
||||
## Virtual Key Events
|
||||
|
||||
The virtual key presses are hardcoded in `boards/native_posix.overlay` file. should you want to change the sequence to test various actions like Mod-Tap, etc.
|
||||
The virtual key presses are hardcoded in `boards/native_posix.overlay` file, should you want to change the sequence to test various actions like Mod-Tap, etc.
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ A unix-like environment with the following base packages installed:
|
|||
|
||||
<OsTabs>
|
||||
<TabItem value="debian">
|
||||
On Debian and Ubuntu, we'll use apt to install our base dependencies:
|
||||
On Debian and Ubuntu, we'll use `apt` to install our base dependencies:
|
||||
|
||||
First, if you haven't updated recently, or if this is a new install,
|
||||
you should update to get the latest package information:
|
||||
|
|
@ -200,7 +200,7 @@ source ~/.bashrc
|
|||
|
||||
### Toolchain Installation
|
||||
|
||||
The toolchain provides the compiler, linker, etc necessary to build for the target
|
||||
The toolchain provides the compiler, linker, etc., necessary to build for the target
|
||||
platform.
|
||||
|
||||
<OsTabs>
|
||||
|
|
@ -217,7 +217,7 @@ wget -q "https://github.com/zephyrproject-rtos/sdk-ng/releases/download/v${ZSDK_
|
|||
rm "zephyr-toolchain-arm-${ZSDK_VERSION}-setup.run"
|
||||
```
|
||||
|
||||
The installation will prompt with several questions about installation location, and creating a default `~/.zephyrrc` for you with various variables. The defaults shouldn normally work as expected.
|
||||
The installation will prompt with several questions about installation location, and creating a default `~/.zephyrrc` for you with various variables. The defaults should normally work as expected.
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="raspberryos">
|
||||
|
|
@ -252,11 +252,20 @@ wget -q "https://github.com/zephyrproject-rtos/sdk-ng/releases/download/v${ZSDK_
|
|||
rm "zephyr-toolchain-arm-\${ZSDK_VERSION}-setup.run"
|
||||
```
|
||||
|
||||
The installation will prompt with several questions about installation location, and creating a default `~/.zephyrrc` for you with various variables. The defaults shouldn normally work as expected.
|
||||
The installation will prompt with several questions about installation location, and creating a default `~/.zephyrrc` for you with various variables. The defaults should normally work as expected.
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="win">
|
||||
|
||||
:::note
|
||||
If you intend to build firmware straight away, make sure to correctly setup the current shell.
|
||||
|
||||
Notes on setting this up can be found in the [Environment Variables](#environment-variables) section.
|
||||
The transient instructions can be used to setup the current shell, and the automatic instructions can setup any newly made shells automatically.
|
||||
|
||||
The transient instructions must be run to build firmware using the current shell.
|
||||
:::
|
||||
|
||||
#### GNU ARM Embedded
|
||||
|
||||
Since the Zephyr™ SDK is not available for Windows, we recommending following the steps to install the [GNU ARM Embedded](https://docs.zephyrproject.org/latest/getting_started/toolchain_3rd_party_x_compilers.html#gnu-arm-embedded).
|
||||
|
|
@ -275,7 +284,7 @@ wget -q "https://github.com/zephyrproject-rtos/sdk-ng/releases/download/v${ZSDK_
|
|||
rm "zephyr-toolchain-arm-\${ZSDK_VERSION}-setup.run"
|
||||
```
|
||||
|
||||
The installation will prompt with several questions about installation location, and creating a default `~/.zephyrrc` for you with various variables. The defaults shouldn normally work as expected.
|
||||
The installation will prompt with several questions about installation location, and creating a default `~/.zephyrrc` for you with various variables. The defaults should normally work as expected.
|
||||
|
||||
</TabItem>
|
||||
</OsTabs>
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ Following the steps in this guide, you will:
|
|||
|
||||
## Prerequisites
|
||||
|
||||
The remainder of this guide assumes the following prequisites:
|
||||
The remainder of this guide assumes the following prerequisites:
|
||||
|
||||
1. You have an active, working [GitHub](https://github.com/) account.
|
||||
1. You have installed and configured the [`git`](https://git-scm.com/) version control tool.
|
||||
|
|
|
|||
Loading…
Reference in New Issue