forked from kofal.net/zmk
docs: Add syntax highlighting to more code blocks
Added language tags to more code blocks in the documentation to enable syntax highlighting.
This commit is contained in:
Joel Spadin
committed by
Cem Aksoylar
Cem Aksoylar
parent
4a339093ce
commit
65667b863a
@@ -77,7 +77,7 @@ So first I enabled logging of the NVS module by adding
|
||||
`CONFIG_NVS_LOG_LEVEL_DBG=y` to my `.conf` file. I repeated the same test of
|
||||
spamming RGB underglow effect cycle and the resulting logs I got were this:
|
||||
|
||||
```
|
||||
```log
|
||||
[00:00:00.000,671] <inf> fs_nvs: 8 Sectors of 4096 bytes
|
||||
[00:00:00.000,671] <inf> fs_nvs: alloc wra: 3, f70
|
||||
[00:00:00.000,671] <inf> fs_nvs: data wra: 3, f40
|
||||
@@ -130,7 +130,7 @@ and [Dan Halbert](https://github.com/dhalbert) pointed me towards the [linker
|
||||
map](https://github.com/adafruit/Adafruit_nRF52_Bootloader/blob/master/linker/nrf52840.ld)
|
||||
of the nRF52840. Let's take a look.
|
||||
|
||||
```
|
||||
```linker-script
|
||||
FLASH (rx) : ORIGIN = 0xF4000, LENGTH = 0xFE000-0xF4000-2048 /* 38 KB */
|
||||
|
||||
BOOTLOADER_CONFIG (r): ORIGIN = 0xFE000 - 2048, LENGTH = 2048
|
||||
@@ -166,7 +166,7 @@ Now that we've found the issue, we can pretty easily fix this. We'll need to
|
||||
move the settings flash area back so that it doesn't overlap with the
|
||||
bootloader. First we calculate the size of the of flash area the bootloader is using.
|
||||
|
||||
```
|
||||
```linker-script
|
||||
0x100000 (end of flash) - 0x0F4000 (start of bootloader) = 0xC000 (48KB)
|
||||
```
|
||||
|
||||
|
||||
@@ -30,7 +30,7 @@ This also laid the foundation for the other keymap related changes that are now
|
||||
|
||||
[okke-formsma] added the ability to apply modifiers to a code, e.g.:
|
||||
|
||||
```
|
||||
```dts
|
||||
&kp LC(C)
|
||||
```
|
||||
|
||||
@@ -63,7 +63,7 @@ and nice!nano that have specialized hardware for this purpose.
|
||||
|
||||
With this change, you can add
|
||||
|
||||
```
|
||||
```dts
|
||||
&ext_power EP_TOG
|
||||
```
|
||||
|
||||
|
||||
@@ -25,7 +25,7 @@ The initial [combos](/docs/features/combos) work has landed! The amazing [okke-f
|
||||
|
||||
An example, that would send the `ESC` keycode when pressing both the first and second positions on your keyboard:
|
||||
|
||||
```
|
||||
```dts
|
||||
/ {
|
||||
combos {
|
||||
compatible = "zmk,combos";
|
||||
@@ -46,13 +46,13 @@ Combos currently are "global", and not scoped to a given active layer. There is
|
||||
|
||||
[okke-formsma] also contributed the initial "sticky keys" behavior, which can be used for functionality sometimes called "one shot mods" or "one shot layers". In your keymap, this would like like:
|
||||
|
||||
```
|
||||
```dts
|
||||
&sk LEFT_CONTROL
|
||||
```
|
||||
|
||||
for a sticky key/modifier, or:
|
||||
|
||||
```
|
||||
```dts
|
||||
&sl NAV
|
||||
```
|
||||
|
||||
@@ -68,7 +68,7 @@ This is most frequently used when using multiple core base layers with different
|
||||
|
||||
[okke-formsma] added an implementation of the "Grave Escape" behavior, developing a more generic "mod-morph" behavior to do so. Adding
|
||||
|
||||
```
|
||||
```dts
|
||||
&gresc
|
||||
```
|
||||
|
||||
|
||||
@@ -29,12 +29,12 @@ Existing user config repositories using Github Actions to build will pull down Z
|
||||
- Change `zmkfirmware/zmk-build-arm:2.5` to `zmkfirmware/zmk-build-arm:stable` wherever it is found
|
||||
- Locate and delete the lines for the DTS output step, which is no longer needed:
|
||||
|
||||
```
|
||||
- name: ${{ steps.variables.outputs.display-name }} DTS File
|
||||
if: ${{ always() }}
|
||||
run: |
|
||||
if [ -f "build/zephyr/${{ matrix.board }}.pre.tmp" ]; then cat -n build/zephyr/${{ matrix.board }}.pre.tmp; fi
|
||||
if [ -f "build/zephyr/zephyr.dts" ]; then cat -n build/zephyr/zephyr.dts; fi
|
||||
```yaml
|
||||
- name: ${{ steps.variables.outputs.display-name }} DTS File
|
||||
if: ${{ always() }}
|
||||
run: |
|
||||
if [ -f "build/zephyr/${{ matrix.board }}.pre.tmp" ]; then cat -n build/zephyr/${{ matrix.board }}.pre.tmp; fi
|
||||
if [ -f "build/zephyr/zephyr.dts" ]; then cat -n build/zephyr/zephyr.dts; fi
|
||||
```
|
||||
|
||||
:::note
|
||||
@@ -76,7 +76,7 @@ The following changes have [already been completed](https://github.com/zmkfirmwa
|
||||
|
||||
Zephyr's WS2812 `led_strip` driver added a new required property. When adding [underglow](/docs/features/underglow#adding-rgb-underglow-to-a-board) to a board, you now must also add the additional include `#include <dt-bindings/led/led.h>` at the top of your devicetree file, and add a `color-mapping` property like:
|
||||
|
||||
```
|
||||
```dts
|
||||
led_strip: ws2812@0 {
|
||||
compatible = "worldsemi,ws2812-spi";
|
||||
label = "WS2812";
|
||||
@@ -108,7 +108,7 @@ Zephyr moved to using a `chosen` node named `zephyr,display` to select the displ
|
||||
|
||||
For example, for a shield with:
|
||||
|
||||
```
|
||||
```dts
|
||||
&pro_micro_i2c {
|
||||
status = "okay";
|
||||
|
||||
@@ -132,7 +132,7 @@ For example, for a shield with:
|
||||
|
||||
You would add a `chosen` node like:
|
||||
|
||||
```
|
||||
```dts
|
||||
/ {
|
||||
chosen {
|
||||
zephyr,display = &oled;
|
||||
@@ -148,7 +148,7 @@ two sections of the `<board>.dts` file need updating.
|
||||
|
||||
Underneath the USB device, add the CDC ACM node:
|
||||
|
||||
```
|
||||
```dts
|
||||
&usbd {
|
||||
status = "okay";
|
||||
cdc_acm_uart: cdc_acm_uart {
|
||||
@@ -160,7 +160,7 @@ Underneath the USB device, add the CDC ACM node:
|
||||
|
||||
Then, an additional `chosen` node (near the top of the file) will mark the CDC ACM device as the console:
|
||||
|
||||
```
|
||||
```dts
|
||||
/ {
|
||||
chosen {
|
||||
...
|
||||
@@ -175,7 +175,7 @@ Then, an additional `chosen` node (near the top of the file) will mark the CDC A
|
||||
Previously, to get ZMK to build a UF2 image to flash to a given board required adding a `CMakeLists.txt` file that added a custom post build command.
|
||||
Now, the only thing necessary to have Zephyr build a UF2 is to add the following to your `<board>_defconfig` file:
|
||||
|
||||
```
|
||||
```ini
|
||||
CONFIG_BUILD_OUTPUT_UF2=y
|
||||
```
|
||||
|
||||
@@ -187,7 +187,7 @@ For more details on the implementation, see [zephyr#31066](https://github.com/ze
|
||||
|
||||
Clock configuration moved to devicetree as well, out of the Kconfig files. Here is a sample config for a board that uses the HSI for the PLL source:
|
||||
|
||||
```
|
||||
```dts
|
||||
&clk_hsi {
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
@@ -32,7 +32,7 @@ to the host capitalized until a non-alpha, non-"continue list" keycode is sent.
|
||||
|
||||
[petejohanson], taking heavy inspiration on the initial work from [okke-formsma], added [macro support](/docs/behaviors/macros) in [#1168](https://github.com/zmkfirmware/zmk/pull/1166). Several [common patterns](/docs/behaviors/macros#common-patterns) are documented, but one example, changing the underglow color as you activate/deactivate a layer, looks like:
|
||||
|
||||
```
|
||||
```dts
|
||||
ZMK_MACRO(layer_color_macro,
|
||||
wait-ms = <0>;
|
||||
tap-ms = <0>;
|
||||
@@ -50,7 +50,7 @@ ZMK_MACRO(layer_color_macro,
|
||||
[kurtis-lew] worked diligently to add the [tap-dance behavior](/docs/behaviors/tap-dance) in [#1139](https://github.com/zmkfirmware/zmk/pull/1139), allowing different behaviors to be invoked based on the number of times
|
||||
a user taps a single key in their keymap, e.g.
|
||||
|
||||
```
|
||||
```dts
|
||||
/ {
|
||||
behaviors {
|
||||
td0: tap_dance_0 {
|
||||
@@ -80,7 +80,7 @@ a user taps a single key in their keymap, e.g.
|
||||
|
||||
Example:
|
||||
|
||||
```
|
||||
```dts
|
||||
/ {
|
||||
conditional_layers {
|
||||
compatible = "zmk,conditional-layers";
|
||||
@@ -164,7 +164,7 @@ using "high voltage mode" with that SoC.
|
||||
|
||||
[petejohanson]'s work on the HID foundation also included adding support for full NKRO HID in [#726](https://github.com/zmkfirmware/zmk/pull/726) that can be enabled by adding the following to your `.conf` file for your config:
|
||||
|
||||
```
|
||||
```ini
|
||||
CONFIG_ZMK_HID_REPORT_TYPE_NKRO=y
|
||||
```
|
||||
|
||||
@@ -176,7 +176,7 @@ It's been live for a while, but [nicell] added an amazing [power profiler](/powe
|
||||
|
||||
[malinges](https://github.com/malinges) added support for configuring min/max underglow brightness in [#944](https://github.com/zmkfirmware/zmk/pull/944) by setting the values in your `.conf` file as percentages of full:
|
||||
|
||||
```
|
||||
```ini
|
||||
CONFIG_ZMK_RGB_UNDERGLOW_BRT_MIN=20
|
||||
CONFIG_ZMK_RGB_UNDERGLOW_BRT_MAX=80
|
||||
```
|
||||
|
||||
@@ -26,7 +26,7 @@ Existing user config repositories using Github Actions to build will pull down Z
|
||||
|
||||
1. Replace the contents of your `.github/workflows/build.yml` with:
|
||||
|
||||
```
|
||||
```yaml
|
||||
on: [push, pull_request, workflow_dispatch]
|
||||
|
||||
jobs:
|
||||
@@ -36,7 +36,7 @@ Existing user config repositories using Github Actions to build will pull down Z
|
||||
|
||||
1. If it doesn't exist already, add a new file to your repository named `build.yaml`:
|
||||
|
||||
```
|
||||
```yaml
|
||||
# This file generates the GitHub Actions matrix
|
||||
# For simple board + shield combinations, add them
|
||||
# to the top level board and shield arrays, for more
|
||||
@@ -63,12 +63,12 @@ If you have a custom GitHub Actions workflow you need to maintain for some reaso
|
||||
- Change `zmkfirmware/zmk-build-arm:2.5` to `zmkfirmware/zmk-build-arm:stable` wherever it is found
|
||||
- Locate and delete the lines for the DTS output step, which is no longer needed:
|
||||
|
||||
```
|
||||
- name: ${{ steps.variables.outputs.display-name }} DTS File
|
||||
if: ${{ always() }}
|
||||
run: |
|
||||
if [ -f "build/zephyr/${{ matrix.board }}.pre.tmp" ]; then cat -n build/zephyr/${{ matrix.board }}.pre.tmp; fi
|
||||
if [ -f "build/zephyr/zephyr.dts" ]; then cat -n build/zephyr/zephyr.dts; fi
|
||||
```yaml
|
||||
- name: ${{ steps.variables.outputs.display-name }} DTS File
|
||||
if: ${{ always() }}
|
||||
run: |
|
||||
if [ -f "build/zephyr/${{ matrix.board }}.pre.tmp" ]; then cat -n build/zephyr/${{ matrix.board }}.pre.tmp; fi
|
||||
if [ -f "build/zephyr/zephyr.dts" ]; then cat -n build/zephyr/zephyr.dts; fi
|
||||
```
|
||||
|
||||
### VS Code & Docker (Dev Container)
|
||||
@@ -107,7 +107,7 @@ A few testers have reported inconsistent issues with bluetooth connections on Wi
|
||||
|
||||
Zephyr 3.2 introduced [a new Kconfig setting](https://github.com/zephyrproject-rtos/zephyr/pull/48929) that can be used to work around a bug in Windows related to battery reporting. Check out our [bluetooth config](/docs/config/bluetooth) for the full details. The key new configuration that can be set if using Windows is:
|
||||
|
||||
```
|
||||
```ini
|
||||
CONFIG_BT_GATT_ENFORCE_SUBSCRIPTION=n
|
||||
```
|
||||
|
||||
@@ -133,7 +133,7 @@ The main area this affects existing shields is those with board specific overrid
|
||||
|
||||
Previously in ZMK, we relied on per-driver devicetree source properties to set the alternate pin functions for things like SPI or I2C. For example, here is the I2C bus setup as it was previously on the `nice_nano` board:
|
||||
|
||||
```
|
||||
```dts
|
||||
&i2c0 {
|
||||
compatible = "nordic,nrf-twi";
|
||||
sda-pin = <17>;
|
||||
@@ -143,7 +143,7 @@ Previously in ZMK, we relied on per-driver devicetree source properties to set t
|
||||
|
||||
With the move to the `pinctrl` system, this setup now look like:
|
||||
|
||||
```
|
||||
```dts
|
||||
&i2c0 {
|
||||
compatible = "nordic,nrf-twi";
|
||||
pinctrl-0 = <&i2c0_default>;
|
||||
@@ -154,7 +154,7 @@ With the move to the `pinctrl` system, this setup now look like:
|
||||
|
||||
which references the `pinctrl` configuration:
|
||||
|
||||
```
|
||||
```dts
|
||||
&pinctrl {
|
||||
i2c0_default: i2c0_default {
|
||||
group1 {
|
||||
@@ -185,7 +185,7 @@ The approach is the following when updating a _board_:
|
||||
1. Add a new file with the naming convention `<board>-pinctrl.dtsi` to your board directory.
|
||||
1. In the new file, add your `pinctrl` entries that set up different pin control configurations for whatever peripherals/buses are needed. Here's the nice!nano file as an example:
|
||||
|
||||
```
|
||||
```dts
|
||||
/*
|
||||
* Copyright (c) 2022 The ZMK Contributors
|
||||
* SPDX-License-Identifier: MIT
|
||||
@@ -230,7 +230,7 @@ The approach is the following when updating a _board_:
|
||||
1. From the main `<board>.dts` file, add an `#include "<board>-pinctrl.dtsi"` to have the C-preprocessor combine the files.
|
||||
1. Update the various peripheral nodes to use the new `pinctrl` configurations. For example, the following old configuration:
|
||||
|
||||
```
|
||||
```dts
|
||||
&i2c0 {
|
||||
compatible = "nordic,nrf-twi";
|
||||
sda-pin = <15>;
|
||||
@@ -240,7 +240,7 @@ The approach is the following when updating a _board_:
|
||||
|
||||
would be changed to:
|
||||
|
||||
```
|
||||
```dts
|
||||
&i2c0 {
|
||||
compatible = "nordic,nrf-twi";
|
||||
pinctrl-0 = <&i2c0_default>;
|
||||
|
||||
@@ -35,7 +35,7 @@ Splitting these two parts of the encoder configuration allows greater flexibilit
|
||||
|
||||
Previously, an encoder configuration looked like:
|
||||
|
||||
```
|
||||
```dts
|
||||
left_encoder: encoder_left {
|
||||
compatible = "alps,ec11";
|
||||
label = "LEFT_ENCODER";
|
||||
@@ -47,7 +47,7 @@ Previously, an encoder configuration looked like:
|
||||
|
||||
Here, the `resolution` property was used to indicate how many encoder pulses should trigger the sensor behavior one time. Next, the encoder is selected in the sensors node:
|
||||
|
||||
```
|
||||
```dts
|
||||
sensors {
|
||||
compatible = "zmk,keymap-sensors";
|
||||
sensors = <&left_encoder &right_encoder>;
|
||||
@@ -58,7 +58,7 @@ That was the entirety of the configuration for encoders.
|
||||
|
||||
### New Configuration
|
||||
|
||||
```
|
||||
```dts
|
||||
left_encoder: encoder_left {
|
||||
compatible = "alps,ec11";
|
||||
label = "LEFT_ENCODER";
|
||||
@@ -70,7 +70,7 @@ That was the entirety of the configuration for encoders.
|
||||
|
||||
Here, the `steps` property is now used to indicate how many encoder pulses there are in a single complete rotation of the encoder. Next, the encoder is selected in the sensors node as before, but an additional configuration is used to indicate how many times the encoder should trigger the behavior in your keymap per rotation:
|
||||
|
||||
```
|
||||
```dts
|
||||
sensors {
|
||||
compatible = "zmk,keymap-sensors";
|
||||
sensors = <&left_encoder &right_encoder>;
|
||||
@@ -84,7 +84,7 @@ For tactile encoders that have detents, the `triggers-per-rotation` would match
|
||||
|
||||
The configuration changes bring ZMK's code in line with how upstream Zephyr sensor drivers handle rotations. This has the added advantage of allowing us to leverage other sensor drivers. On Nordic MCUs, like nRF52840, the NRFX QDEC driver can be used, for example:
|
||||
|
||||
```
|
||||
```dts
|
||||
&pinctrl {
|
||||
qdec_default: qdec_default {
|
||||
group1 {
|
||||
|
||||
Reference in New Issue
Block a user