fixed all the links
This commit is contained in:
Nicolas Munnich
Cem Aksoylar
parent
e6f676ef51
commit
d5263306ab
29 changed files with 74 additions and 65 deletions
|
|
@ -60,7 +60,7 @@ Once the container has rebuilt, VS Code will be running the 2.5 Docker image.
|
|||
|
||||
The following steps will get you building ZMK locally against Zephyr 2.5:
|
||||
|
||||
- Run the updated [toolchain installation](/docs/development/setup) steps, and once completed, remove the previously installed SDK version (optional, existing SDK should still work)
|
||||
- Run the updated [toolchain installation](/docs/development/local-toolchain/setup) steps, and once completed, remove the previously installed SDK version (optional, existing SDK should still work)
|
||||
- pull the latest ZMK `main` with `git pull` for your ZMK checkout
|
||||
- run `west update` to pull the updated Zephyr version and its dependencies
|
||||
|
||||
|
|
|
|||
|
|
@ -61,7 +61,7 @@ Once the container has rebuilt, VS Code will be running the 3.0 Docker image.
|
|||
|
||||
The following steps will get you building ZMK locally against Zephyr 3.0:
|
||||
|
||||
- Run the updated [toolchain installation](/docs/development/setup) steps, and once completed, remove the previously installed SDK version (optional, existing SDK should still work)
|
||||
- Run the updated [toolchain installation](/docs/development/local-toolchain/setup) steps, and once completed, remove the previously installed SDK version (optional, existing SDK should still work)
|
||||
- pull the latest ZMK `main` with `git pull` for your ZMK checkout
|
||||
- run `west update` to pull the updated Zephyr version and its dependencies
|
||||
|
||||
|
|
|
|||
|
|
@ -219,7 +219,7 @@ This can be useful to be sure that lowering brightness doesn't set the brightnes
|
|||
|
||||
## Board/Shield Metadata
|
||||
|
||||
[nicell] and [petejohanson] worked together in [#883](https://github.com/zmkfirmware/zmk/pull/883) to settle on a [metadata format](/docs/development/hardware-metadata-files) that is used to document every board and shield. This now drives automatic generation of our [supported hardware](/docs/hardware) page and our
|
||||
[nicell] and [petejohanson] worked together in [#883](https://github.com/zmkfirmware/zmk/pull/883) to settle on a [metadata format](/docs/development/hardware-integration/hardware-metadata-files) that is used to document every board and shield. This now drives automatic generation of our [supported hardware](/docs/hardware) page and our
|
||||
more nuanced GH Actions automation for testing changes to ZMK.
|
||||
|
||||
## Coming Soon!
|
||||
|
|
|
|||
|
|
@ -86,7 +86,7 @@ Once the container has rebuilt, VS Code will be running the 3.2 Docker image.
|
|||
|
||||
The following steps will get you building ZMK locally against Zephyr 3.2:
|
||||
|
||||
- Run the updated [toolchain installation](/docs/development/setup) steps, and once completed, remove the previously installed SDK version (optional, existing SDK should still work)
|
||||
- Run the updated [toolchain installation](/docs/development/local-toolchain/setup) steps, and once completed, remove the previously installed SDK version (optional, existing SDK should still work)
|
||||
- Install the latest version of `west` by running `pip3 install --user --update west`.
|
||||
- pull the latest ZMK `main` with `git pull` for your ZMK checkout
|
||||
- run `west update` to pull the updated Zephyr version and its dependencies
|
||||
|
|
|
|||
|
|
@ -173,7 +173,7 @@ For users or future contributors that might want to dive into writing their own
|
|||
|
||||
#### Shield interconnects
|
||||
|
||||
[petejohanson] updated the [new shield guide](/docs/development/new-shield) for non-Pro Micro interconnects including Xiao, Arduino Uno and Blackpill in [#1607](https://github.com/zmkfirmware/zmk/pull/1607).
|
||||
[petejohanson] updated the [new shield guide](/docs/development/hardware-integration/new-shield) for non-Pro Micro interconnects including Xiao, Arduino Uno and Blackpill in [#1607](https://github.com/zmkfirmware/zmk/pull/1607).
|
||||
|
||||
#### Bluetooth feature page
|
||||
|
||||
|
|
|
|||
|
|
@ -69,7 +69,7 @@ Once the container has rebuilt, VS Code will be running the 3.5 Docker image.
|
|||
|
||||
The following steps will get you building ZMK locally against Zephyr 3.5:
|
||||
|
||||
- Run the updated [toolchain installation](/docs/development/setup) steps, and once completed, remove the previously installed SDK version (optional, existing SDK should still work)
|
||||
- Run the updated [toolchain installation](/docs/development/local-toolchain/setup) steps, and once completed, remove the previously installed SDK version (optional, existing SDK should still work)
|
||||
- Install the latest version of `west` by running `pip3 install --user --update west`.
|
||||
- Pull the latest ZMK `main` with `git pull` for your ZMK checkout
|
||||
- Run `west update` to pull the updated Zephyr version and its dependencies
|
||||
|
|
|
|||
|
|
@ -64,7 +64,7 @@ ZMK will search the shield folder for the following config files _in addition_ t
|
|||
|
||||
Shared config files (excluding any `_left` or `_right` suffix) are not currently supported in shield folders.
|
||||
|
||||
For more documentation on creating and configuring a new shield, see [Zephyr's shield documentation](https://docs.zephyrproject.org/3.5.0/hardware/porting/shields.html) and [ZMK's new keyboard shield](../development/new-shield.mdx) guide.
|
||||
For more documentation on creating and configuring a new shield, see [Zephyr's shield documentation](https://docs.zephyrproject.org/3.5.0/hardware/porting/shields.html) and [ZMK's new keyboard shield](../development/hardware-integration/new-shield.mdx) guide.
|
||||
|
||||
## Kconfig Files
|
||||
|
||||
|
|
|
|||
|
|
@ -344,7 +344,7 @@ Transforms should be used any time the physical layout of a keyboard's keys does
|
|||
|
||||
Transforms can also be used for keyboards with multiple layouts. You can define multiple matrix transform nodes, one for each layout, and users can select which one they want from the `/chosen` node in their keymaps.
|
||||
|
||||
See the [new shield guide](../development/new-shield.mdx#matrix-transform) for more documentation on how to define a matrix transform.
|
||||
See the [new shield guide](../development/hardware-integration/new-shield.mdx#matrix-transform) for more documentation on how to define a matrix transform.
|
||||
|
||||
### Devicetree
|
||||
|
||||
|
|
|
|||
|
|
@ -40,9 +40,9 @@ If you need to, a review of [Learn The Basics Of Git In Under 10 Minutes](https:
|
|||
:::
|
||||
|
||||
:::note
|
||||
It is also possible to build firmware locally on your computer by following the [toolchain setup](development/setup/index.md) and
|
||||
[building instructions](development/build-flash.mdx), which includes pointers to
|
||||
[building using your `zmk-config` folder](development/build-flash.mdx#building-from-zmk-config-folder).
|
||||
It is also possible to build firmware locally on your computer by following the [toolchain setup](development/local-toolchain/setup/index.md) and
|
||||
[building instructions](development/local-toolchain/build-flash.mdx), which includes pointers to
|
||||
[building using your `zmk-config` folder](development/local-toolchain/build-flash.mdx#building-from-zmk-config-folder).
|
||||
:::
|
||||
|
||||
## Flashing Your Changes
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ The foundational elements needed to get a specific keyboard working with ZMK can
|
|||
- 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 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](../faq.md#why-boards-and-shields-why-not-just-keyboard).
|
||||
keyboard works. For an overview on the general concepts of boards and shields, please see the [FAQs on boards and shields](../../faq.md#why-boards-and-shields-why-not-just-keyboard).
|
||||
|
||||
## Self-Contained Keyboard
|
||||
|
||||
|
|
@ -34,7 +34,7 @@ in the `app/boards/${arch}/${board_name}` directory, e.g. `app/boards/arm/planck
|
|||
|
||||
## Pro Micro Compatible Keyboard
|
||||
|
||||
|
||||
|
||||
|
||||
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
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ title: New Keyboard Shield
|
|||
|
||||
import Tabs from "@theme/Tabs";
|
||||
import TabItem from "@theme/TabItem";
|
||||
import KeymapExampleFile from "../keymap-example-file.md";
|
||||
import KeymapExampleFile from "../../keymap-example-file.md";
|
||||
|
||||
import InterconnectTabs from "@site/src/components/interconnect-tabs";
|
||||
import Metadata from "@site/src/data/hardware-metadata.json";
|
||||
|
|
@ -29,7 +29,7 @@ The high level steps are:
|
|||
It may be helpful to review the upstream [shields documentation](https://docs.zephyrproject.org/3.5.0/hardware/porting/shields.html#shields) to get a proper understanding of the underlying system before continuing.
|
||||
|
||||
:::note
|
||||
ZMK support for [split keyboards](../features/split-keyboards.md) requires a few more files than single boards to ensure proper connectivity between the central and peripheral units. Check the following guides thoroughly to ensure that all the files are in place.
|
||||
ZMK support for [split keyboards](../../features/split-keyboards.md) requires a few more files than single boards to ensure proper connectivity between the central and peripheral units. Check the following guides thoroughly to ensure that all the files are in place.
|
||||
:::
|
||||
|
||||
## New Zephyr Module Repository
|
||||
|
|
@ -76,7 +76,7 @@ mkdir boards/shields/<keyboard_name>
|
|||
## Base Kconfig Files
|
||||
|
||||
:::tip[Example shields]
|
||||
You can check out the [`shields` folder](https://github.com/zmkfirmware/zmk/tree/main/app/boards/shields) in the ZMK repo that houses [the in-tree supported shields](../hardware.mdx) in order to copy and modify as a starting point.
|
||||
You can check out the [`shields` folder](https://github.com/zmkfirmware/zmk/tree/main/app/boards/shields) in the ZMK repo that houses [the in-tree supported shields](../../hardware.mdx) in order to copy and modify as a starting point.
|
||||
:::
|
||||
|
||||
There are two required Kconfig files that need to be created for your new keyboard
|
||||
|
|
@ -95,7 +95,7 @@ config SHIELD_MY_BOARD
|
|||
Kconfig uses only commas for delimiters, and keeps all whitespaces in the function call. Therefore do not add a whitespace after the comma when configuring your shield as this would be treated as <code> my_board</code> (with a leading whitespace) and will cause issues.
|
||||
:::
|
||||
|
||||
This will make sure that a new configuration value named `SHIELD_MY_BOARD` is set to true whenever `my_board` is used as the shield name, either as the `SHIELD` variable [in a local build](build-flash.mdx) or in your `build.yaml` file [when using Github Actions](../customization). Note that this configuration value will be used in `Kconfig.defconfig` to set other properties about your shield, so make sure that they match.
|
||||
This will make sure that a new configuration value named `SHIELD_MY_BOARD` is set to true whenever `my_board` is used as the shield name, either as the `SHIELD` variable [in a local build](../local-toolchain/build-flash.mdx) or in your `build.yaml` file [when using Github Actions](../../customization). Note that this configuration value will be used in `Kconfig.defconfig` to set other properties about your shield, so make sure that they match.
|
||||
|
||||
**For split boards**, you will need to add configurations for the left and right sides. For example, if your split halves are named `my_board_left` and `my_board_right`, it would look like this:
|
||||
|
||||
|
|
@ -200,7 +200,7 @@ this might look something like:
|
|||
};
|
||||
```
|
||||
|
||||
See the [Keyboard Scan configuration documentation](../config/kscan.md) for details on configuring the KSCAN driver.
|
||||
See the [Keyboard Scan configuration documentation](../../config/kscan.md) for details on configuring the KSCAN driver.
|
||||
|
||||
</TabItem>
|
||||
|
||||
|
|
@ -301,7 +301,7 @@ This is exemplified with the iris .overlay files.
|
|||
|
||||
```
|
||||
|
||||
See the [Keyboard Scan configuration documentation](../config/kscan.md) for details on configuring the KSCAN driver.
|
||||
See the [Keyboard Scan configuration documentation](../../config/kscan.md) for details on configuring the KSCAN driver.
|
||||
|
||||
### .conf files (Split Shields)
|
||||
|
||||
|
|
@ -320,7 +320,7 @@ CONFIG_ZMK_SLEEP=y
|
|||
```
|
||||
|
||||
:::note
|
||||
The shared configuration in `my_awesome_split_board.conf` is only applied when you are building with a [`zmk-config` folder](build-flash#building-from-zmk-config-folder) and when it is present at `config/my_awesome_split_board.conf`. If you are not using a `zmk-config` folder, you will need to include the shared configuration in both `my_awesome_split_board_left.conf` and `my_awesome_split_board_right.conf` files.
|
||||
The shared configuration in `my_awesome_split_board.conf` is only applied when you are building with a [`zmk-config` folder](../local-toolchain/build-flash#building-from-zmk-config-folder) and when it is present at `config/my_awesome_split_board.conf`. If you are not using a `zmk-config` folder, you will need to include the shared configuration in both `my_awesome_split_board_left.conf` and `my_awesome_split_board_right.conf` files.
|
||||
:::
|
||||
|
||||
</TabItem>
|
||||
|
|
@ -374,7 +374,7 @@ Some important things to note:
|
|||
- `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, ANSI vs. ISO layouts, or break away portions, define one matrix transform for each possible arrangement to be used in the physical layouts. This will allow the users to select the right layout in their keymap files.
|
||||
|
||||
See the [matrix transform section](../config/kscan.md#matrix-transform) in the Keyboard Scan configuration documentation for details and more examples of matrix transforms.
|
||||
See the [matrix transform section](../../config/kscan.md#matrix-transform) in the Keyboard Scan configuration documentation for details and more examples of matrix transforms.
|
||||
|
||||
## Physical Layout
|
||||
|
||||
|
|
@ -443,7 +443,7 @@ The two `#include` lines at the top of the keymap are required in order to bring
|
|||
|
||||
### Keymap Behaviors
|
||||
|
||||
For documentation on the available behaviors for use in keymaps, see the [overview page for behaviors](../keymaps/behaviors/index.mdx).
|
||||
For documentation on the available behaviors for use in keymaps, see the [overview page for behaviors](../../keymaps/behaviors/index.mdx).
|
||||
|
||||
## Metadata
|
||||
|
||||
|
|
@ -469,7 +469,7 @@ siblings:
|
|||
- corne_right
|
||||
```
|
||||
|
||||
You should place a properly named `foo.zmk.yml` file in the directory next to your other shield values, and fill it out completely and accurately. See [Hardware Metadata Files](/docs/development/hardware-metadata-files) for the full details.
|
||||
You should place a properly named `foo.zmk.yml` file in the directory next to your other shield values, and fill it out completely and accurately. See [Hardware Metadata Files](hardware-metadata-files) for the full details.
|
||||
|
||||
## Build File
|
||||
|
||||
|
|
@ -567,7 +567,7 @@ Once you have defined the encoder sensors, you will have to add them to the list
|
|||
|
||||
In this example, a left_encoder and right_encoder are both added. Additional encoders can be added with spaces separating each, and the order they are added here determines the order in which you define their behavior in your keymap.
|
||||
|
||||
In addition, a default value for the number of times the sensors trigger the bound behavior per full rotation is set via the `triggers-per-rotation` property. See [Encoders Config](../config/encoders.md#devicetree) for more details.
|
||||
In addition, a default value for the number of times the sensors trigger the bound behavior per full rotation is set via the `triggers-per-rotation` property. See [Encoders Config](../../config/encoders.md#devicetree) for more details.
|
||||
|
||||
</TabItem>
|
||||
<TabItem value = "overlay">
|
||||
|
|
@ -591,7 +591,7 @@ Add the following line to your keymap file to add default encoder behavior bindi
|
|||
sensor-bindings = <&inc_dec_kp C_VOL_UP C_VOL_DN>;
|
||||
```
|
||||
|
||||
Add additional bindings as necessary to match the default number of encoders on your board. See the [Encoders](../features/encoders.md) and [Keymaps](../keymaps/index.mdx) documentation pages for more details.
|
||||
Add additional bindings as necessary to match the default number of encoders on your board. See the [Encoders](../../features/encoders.md) and [Keymaps](../../keymaps/index.mdx) documentation pages for more details.
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
|
@ -600,7 +600,7 @@ Add additional bindings as necessary to match the default number of encoders on
|
|||
|
||||
### GitHub Actions
|
||||
|
||||
Using GitHub Actions to build your new firmware can save you from doing any local [development setup](./setup/index.md),
|
||||
Using GitHub Actions to build your new firmware can save you from doing any local [development setup](../local-toolchain/setup/index.md),
|
||||
at the expense of a longer feedback loop if there are issues. To push your changes and trigger a build:
|
||||
|
||||
- Add all your pending changes with `git add .`
|
||||
|
|
@ -612,7 +612,7 @@ Once pushed, click on the "Actions" tab of the repo you created in the first ste
|
|||
### Local Build
|
||||
|
||||
:::note
|
||||
To build locally, be sure you've followed the [development setup](./setup/index.md) guide first.
|
||||
To build locally, be sure you've followed the [development setup](../local-toolchain/setup/index.md) guide first.
|
||||
:::
|
||||
|
||||
Once you've fully created the new keyboard shield definition,
|
||||
|
|
@ -623,7 +623,7 @@ west build --pristine -b nice_nano_v2 -- -DSHIELD=<my_shield> -DZMK_EXTRA_MODULE
|
|||
# replace <my_shield> with e.g. <my_shield>_left for split keyboards, then repeat for <my_shield>_right
|
||||
```
|
||||
|
||||
The above build command generates a `build/zephyr/zmk.uf2` file that you can flash using the steps from the following section. See the dedicated [building and flashing page](build-flash.mdx) for more details.
|
||||
The above build command generates a `build/zephyr/zmk.uf2` file that you can flash using the steps from the following section. See the dedicated [building and flashing page](../local-toolchain/build-flash.mdx) for more details.
|
||||
|
||||
### Flashing
|
||||
|
||||
|
|
@ -642,9 +642,9 @@ west flash
|
|||
```
|
||||
|
||||
Please have a look at documentation specific to
|
||||
[building and flashing](build-flash.mdx) for additional information.
|
||||
[building and flashing](../local-toolchain/build-flash.mdx) for additional information.
|
||||
|
||||
:::note
|
||||
Further testing your keyboard shield without altering the root keymap file can be done with the use of `-DZMK_CONFIG` in your `west build` command,
|
||||
shown [here](build-flash.mdx#building-from-zmk-config-folder)
|
||||
shown [here](../local-toolchain/build-flash.mdx#building-from-zmk-config-folder)
|
||||
:::
|
||||
|
|
|
|||
|
|
@ -95,7 +95,7 @@ west build -b nice_nano_v2 -- -DSHIELD=vendor_shield -DZMK_EXTRA_MODULES="C:/Use
|
|||
|
||||
### Building from `zmk-config` Folder
|
||||
|
||||
Instead of building .uf2 files using the default keymap and config files, you can build directly from your [`zmk-config` folder](../user-setup.mdx#github-repo) by adding
|
||||
Instead of building .uf2 files using the default keymap and config files, you can build directly from your [`zmk-config` folder](../../user-setup.mdx#github-repo) by adding
|
||||
`-DZMK_CONFIG="C:/the/absolute/path/config"` to your `west build` command. **Notice that this path should point to the folder labelled `config` within your `zmk-config` folder.**
|
||||
|
||||
For instance, building kyria firmware from a user `myUser`'s `zmk-config` folder on Windows 10 may look something like this:
|
||||
|
|
@ -109,7 +109,7 @@ The above command must still be invoked from the `zmk/app` directory as noted ab
|
|||
:::
|
||||
|
||||
:::warning
|
||||
If your config is also a [module](../features/modules.mdx), then you should also add the root (the folder in which the `zephyr` folder is found) of your `zmk-config` as an [external module to build with](#building-with-external-modules).
|
||||
If your config is also a [module](../../features/modules.mdx), then you should also add the root (the folder in which the `zephyr` folder is found) of your `zmk-config` as an [external module to build with](#building-with-external-modules).
|
||||
:::
|
||||
|
||||
In order to make your `zmk-config` folder available when building within the VSCode Remote Container, you need to create a docker volume named `zmk-config`
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ git clone https://github.com/zmkfirmware/zmk.git
|
|||
|
||||
Open the `zmk` checkout folder in VS Code. The repository includes a configuration for containerized development, so an alert will pop up:
|
||||
|
||||
|
||||
|
||||
|
||||
Click `Reopen in Container` in order to reopen the VS Code with the running container. If the alert fails to pop up or you accidentally close it, you can perform the same action by pressing `ctrl+shift+p` and selecting `Remote: Show Remote Menu`.
|
||||
|
||||
|
|
|
|||
|
|
@ -11,10 +11,10 @@ We recommend reading through the setup process before following it step by step,
|
|||
|
||||
There are two ways to set up the ZMK development environment:
|
||||
|
||||
- [Docker](/docs/development/setup/docker): \
|
||||
- [Docker](docker.md): \
|
||||
A self-contained development environment. It uses the same [Docker image which is used by the GitHub action](https://github.com/zmkfirmware/zmk-docker) for local development. Beyond the benefits of [dev/prod parity](https://12factor.net/dev-prod-parity), this approach may be easier to set up for some operating systems. No toolchain or dependencies are necessary when using Docker; the container image has the toolchain installed and set up to use.
|
||||
|
||||
- [Native](/docs/development/setup/native):\
|
||||
- [Native](native.mdx):\
|
||||
This uses your operating system directly. Usually runs slightly faster than the Docker approach, and can be preferable for users who already have the dependencies on their system.
|
||||
|
||||
Please see the [Docker](/docs/development/setup/docker) instructions or [native](/docs/development/setup/native) instructions to continue setup.
|
||||
Please see the [Docker](docker.md) instructions or [native](native.mdx) instructions to continue setup.
|
||||
|
|
|
|||
|
|
@ -69,9 +69,9 @@ sudo tio /dev/ttyACM0
|
|||
|
||||
On Windows, you can use [PuTTY](https://www.putty.org/). Once installed, use Device Manager to figure out which COM port your controller is communicating on (listed under 'Ports (COM & LPT)') and specify that as the 'Serial line' in PuTTY.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
If you already have the Ardunio IDE installed you can also use its built-in Serial Monitor.
|
||||
|
||||
|
|
|
|||
|
|
@ -192,7 +192,7 @@ The dependencies required for any ZMK behavior are:
|
|||
|
||||
- `device.h`: [Zephyr Device APIs](https://docs.zephyrproject.org/apidoc/latest/group__device__model.html)
|
||||
- `drivers/behavior.h`: ZMK Behavior Functions (e.g. [`locality`](#api-structure), `behavior_keymap_binding_pressed`, `behavior_keymap_binding_released`, `behavior_sensor_keymap_binding_triggered`)
|
||||
- `logging/log.h`: [Zephyr Logging APIs](https://docs.zephyrproject.org/3.5.0/services/logging/index.html) (for more information on USB Logging in ZMK, see [USB Logging](usb-logging.mdx)).
|
||||
- `logging/log.h`: [Zephyr Logging APIs](https://docs.zephyrproject.org/3.5.0/services/logging/index.html) (for more information on USB Logging in ZMK, see [USB Logging](local-toolchain/usb-logging.mdx)).
|
||||
- `zmk/behavior.h`: ZMK Behavior Information (e.g. parameters, position and timestamp of events)
|
||||
- `return` values:
|
||||
- `ZMK_BEHAVIOR_OPAQUE`: Used to terminate `on_<behavior_name>_binding_pressed` and `on_<behavior_name>_binding_released` functions that accept `(struct zmk_behavior_binding *binding, struct zmk_behavior_binding_event event)` as parameters
|
||||
|
|
@ -432,8 +432,8 @@ Zephyr currently does not support logging over Bluetooth, so any use of the seri
|
|||
|
||||
:::info
|
||||
|
||||
- See [Tests](tests.md) for more information on how to create virtual test sets.
|
||||
- For hardware-based testing, see [USB Logging](usb-logging.mdx).
|
||||
- See [Tests](local-toolchain/tests.md) for more information on how to create virtual test sets.
|
||||
- For hardware-based testing, see [USB Logging](local-toolchain/usb-logging.mdx).
|
||||
|
||||
:::
|
||||
|
||||
|
|
|
|||
|
|
@ -41,4 +41,4 @@ Here, the left encoder is configured to control volume up and down while the rig
|
|||
|
||||
## Adding Encoder Support
|
||||
|
||||
See the [New Keyboard Shield](../development/new-shield.mdx#encoders) documentation for how to add or modify additional encoders to your shield.
|
||||
See the [New Keyboard Shield](../development/hardware-integration/new-shield.mdx#encoders) documentation for how to add or modify additional encoders to your shield.
|
||||
|
|
|
|||
|
|
@ -113,7 +113,7 @@ manifest:
|
|||
|
||||
### Building Locally
|
||||
|
||||
To add a module to your build when building locally, you will need to clone/copy said module into your local file tree. You can then build using the module as described in [Building with External Modules](../development/build-flash.mdx#building-with-external-modules).
|
||||
To add a module to your build when building locally, you will need to clone/copy said module into your local file tree. You can then build using the module as described in [Building with External Modules](../development/local-toolchain/build-flash.mdx#building-with-external-modules).
|
||||
|
||||
## Beta Testing
|
||||
|
||||
|
|
@ -191,4 +191,4 @@ manifest:
|
|||
|
||||
### Building Locally
|
||||
|
||||
When building from a pull request locally, you'll need to [perform the local user setup](../development/setup/index.md), but using the repository of the pull request rather than the official ZMK repository. You can then [build and flash](../development/build-flash.mdx) as usual.
|
||||
When building from a pull request locally, you'll need to [perform the local user setup](../development/local-toolchain/setup/index.md), but using the repository of the pull request rather than the official ZMK repository. You can then [build and flash](../development/local-toolchain/build-flash.mdx) as usual.
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ You can refer to the [power profiler](/power-profiler) to see battery life estim
|
|||
|
||||
### Configuration
|
||||
|
||||
The [new shield guide](../development/new-shield.mdx) details how to define a split keyboard shield with two parts, enabling the split feature and setting up the necessary roles for each part.
|
||||
The [new shield guide](../development/hardware-integration/new-shield.mdx) details how to define a split keyboard shield with two parts, enabling the split feature and setting up the necessary roles for each part.
|
||||
|
||||
Also see the reference section on [split keyboards configuration](../config/system.md#split-keyboards) where the relevant symbols include `CONFIG_ZMK_SPLIT` that enables the feature, `CONFIG_ZMK_SPLIT_ROLE_CENTRAL` which sets the central role and `CONFIG_ZMK_SPLIT_BLE_CENTRAL_PERIPHERALS` that sets the number of peripherals.
|
||||
|
||||
|
|
|
|||
|
|
@ -55,4 +55,4 @@ Please see pages under the "Features" header in the sidebar for details.
|
|||
{/* prettier-ignore */}
|
||||
<Heading as="h2" id="contributing">Contributing</Heading>
|
||||
|
||||
If you'd like to add support for a new keyboard shield, head over to the [New Keyboard Shield](development/new-shield.mdx) documentation and note the [clean room design requirements](development/clean-room.md).
|
||||
If you'd like to add support for a new keyboard shield, head over to the [New Keyboard Shield](development/hardware-integration/new-shield.mdx) documentation and note the [clean room design requirements](development/index.md).
|
||||
|
|
|
|||
|
|
@ -103,5 +103,5 @@ Please note there are five available Bluetooth profiles by default. If you need
|
|||
:::
|
||||
|
||||
:::note
|
||||
If you clear bond of a paired profile, make sure you do the same thing on the peer device as well (typically achieved by _removing_ or _forgetting_ the bluetooth connection). Otherwise the peer will try to connect to your keyboard whenever it discovers it. But while the MAC address of both devices could remain the same, the security key no longer match: the peer device still possess the old key negotiated in the previous pairing procedure, but our keyboard firmware has deleted that key. So the connection will fail. If you [enabled USB logging](../../development/usb-logging.mdx), you might see a lot of failed connection attempts due to the reason of “Security failed”.
|
||||
If you clear bond of a paired profile, make sure you do the same thing on the peer device as well (typically achieved by _removing_ or _forgetting_ the bluetooth connection). Otherwise the peer will try to connect to your keyboard whenever it discovers it. But while the MAC address of both devices could remain the same, the security key no longer match: the peer device still possess the old key negotiated in the previous pairing procedure, but our keyboard firmware has deleted that key. So the connection will fail. If you [enabled USB logging](../../development/local-toolchain/usb-logging.mdx), you might see a lot of failed connection attempts due to the reason of “Security failed”.
|
||||
:::
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ export const Uf2Tabs = (props) => (
|
|||
);
|
||||
|
||||
:::tip
|
||||
[USB logging](../development/usb-logging.mdx) can be very helpful for diagnosing issues with ZMK. However, when connected to USB your ZMK device will output to USB by default. To troubleshoot wireless connection issues using logging, you will need to [change the preferred output endpoint](../keymaps/behaviors/outputs.md).
|
||||
[USB logging](../development/local-toolchain/usb-logging.mdx) can be very helpful for diagnosing issues with ZMK. However, when connected to USB your ZMK device will output to USB by default. To troubleshoot wireless connection issues using logging, you will need to [change the preferred output endpoint](../keymaps/behaviors/outputs.md).
|
||||
:::
|
||||
|
||||
## Split Keyboard Halves Unable to Pair
|
||||
|
|
|
|||
|
|
@ -187,7 +187,7 @@ Run `zmk keyboard list` to print a list of supported keyboard hardware.
|
|||
|
||||
If ZMK doesn't support your keyboard yet, you can run `zmk keyboard new` to create a new keyboard from a template.
|
||||
|
||||
This won't walk you through all of the details of adding support for a new keyboard, but it will generate most of the boilerplate for you. See the [New Keyboard Shield](development/new-shield.mdx) guide for how to finish writing the keyboard files.
|
||||
This won't walk you through all of the details of adding support for a new keyboard, but it will generate most of the boilerplate for you. See the [New Keyboard Shield](development/hardware-integration/new-shield.mdx) guide for how to finish writing the keyboard files.
|
||||
|
||||
### Module Management
|
||||
|
||||
|
|
|
|||
|
|
@ -112,7 +112,7 @@ If you are building firmware for a new keyboard that is not included in the buil
|
|||
list of keyboards, you can choose any keyboard from the list that is similar to yours
|
||||
(e.g. in terms of unibody/split and [onboard controller](hardware.mdx#onboard) /
|
||||
[composite](hardware.mdx#composite)) to generate the repository,
|
||||
and edit / add necessary files. You can follow the [new shield guide](development/new-shield.mdx) if you are adding support for a composite keyboard.
|
||||
and edit / add necessary files. You can follow the [new shield guide](development/hardware-integration/new-shield.mdx) if you are adding support for a composite keyboard.
|
||||
:::
|
||||
|
||||
### MCU Board Selection
|
||||
|
|
|
|||
|
|
@ -81,7 +81,7 @@ module.exports = {
|
|||
},
|
||||
{
|
||||
label: "Development",
|
||||
to: "docs/development/setup",
|
||||
to: "docs/development",
|
||||
},
|
||||
],
|
||||
},
|
||||
|
|
|
|||
|
|
@ -115,10 +115,14 @@ module.exports = {
|
|||
],
|
||||
},
|
||||
{
|
||||
Development: [
|
||||
"development/making-modules",
|
||||
"development/studio-rpc-protocol",
|
||||
"development/new-behavior",
|
||||
type: "category",
|
||||
label: "Development",
|
||||
link: {
|
||||
type: "doc",
|
||||
id: "development/index",
|
||||
},
|
||||
collapsed: true,
|
||||
items: [
|
||||
{
|
||||
type: "category",
|
||||
label: "Hardware Integration",
|
||||
|
|
@ -133,15 +137,6 @@ module.exports = {
|
|||
"development/hardware-integration/boards-shields-keymaps",
|
||||
],
|
||||
},
|
||||
{
|
||||
type: "category",
|
||||
label: "Contributing",
|
||||
collapsed: true,
|
||||
items: [
|
||||
"development/contributing/clean-room",
|
||||
"development/contributing/documentation",
|
||||
],
|
||||
},
|
||||
{
|
||||
type: "category",
|
||||
label: "Local Toolchain",
|
||||
|
|
@ -168,6 +163,9 @@ module.exports = {
|
|||
"development/local-toolchain/posix-board",
|
||||
],
|
||||
},
|
||||
"development/studio-rpc-protocol",
|
||||
"development/new-behavior",
|
||||
"development/documentation",
|
||||
],
|
||||
},
|
||||
],
|
||||
|
|
|
|||
13
docs/static/_redirects
vendored
13
docs/static/_redirects
vendored
|
|
@ -5,4 +5,15 @@
|
|||
/docs/features/encoders /docs/keymaps/encoders 301
|
||||
/docs/codes/modifiers /docs/keymaps/modifiers 301
|
||||
/docs/codes/* /docs/keymaps/list-of-keycodes 301
|
||||
/docs/features/beta-testing /docs/features/modules#beta-testing 301
|
||||
/docs/features/beta-testing /docs/features/modules#beta-testing 301
|
||||
/docs/development/setup /docs/development/local-toolchain/setup 301
|
||||
/docs/development/boards-shields-keymaps /docs/development/hardware-integration/boards-shields-keymaps 301
|
||||
/docs/development/hardware-metadata-files /docs/development/hardware-integration/hardware-metadata-files 301
|
||||
/docs/development/new-shield /docs/development/hardware-integration/new-shield 301
|
||||
/docs/development/build-flash /docs/development/local-toolchain/build-flash 301
|
||||
/docs/development/ide-integration /docs/development/local-toolchain/ide-integration 301
|
||||
/docs/development/posix-board /docs/development/local-toolchain/posix-board 301
|
||||
/docs/development/pre-commit /docs/development/local-toolchain/pre-commit 301
|
||||
/docs/development/tests /docs/development/local-toolchain/tests 301
|
||||
/docs/development/usb-logging /docs/development/local-toolchain/usb-logging 301
|
||||
/docs/development/guides/new-behavior /docs/development/new-behavior 301
|
||||
Loading…
Add table
Reference in a new issue