이 가이드에서는 (Pro Micro 호환) MCU 보드를 사용하는 키보드에 ZMK 지원을 추가하기 위한 과정을 안내합니다. 큰 틀에서의 단계는:
- 새 쉴드 디렉터리를 생성
- 기본 Kconfig 파일들을 추가
- 쉴드 오버레이 파일을 추가하여 KSCAN 드라이버를 정의define 함으로써 키 입력/릴리즈를 감지
- 기본default 키맵을 추가, 사용자로 하여금 필요한대로 덮어쓰기override 기능을 지원
- 인코더, OLED 디스플레이, RGB 언더글로우 같은 기능들을 추가
하게 됩니다.
진행 전에 쉴드 문서 를 다시 읽어봄으로써 기반 시스템에 대한 필요 수준의 적정 이해를 갖추는 것이 도움이 될 수 있습니다.
NOTE:
스플릿 키보드에서 ZMK를 지원하기 위해서는 기존의 일반 키보드보다 약간 더 많은 파일들이 필요하며, 이로써 중심Centrl 기기와 부속 기기peripheral units 간의 연결을 확보할 수 있습니다. 이하 모든 내용들을 철저히 점검하여 모든 파일이 제자리에 있음을 확인하십시오.
NOTE:
이 가이드는 ZMK 메인 리포에 쉴드를 추가하는 방법을 설명하고 있습니다. 현재 작업자가 프로토타입이나 핸드와이어 키보드용 펌웨어를 제작하는 것이라면, 귀하의 개인 유저 설정 저장소를 사용할 것이 권장됩니다. 사용자 셋업 가이드 를 따라 귀하의 개인 설정 저장소를 생성하십시오. 이후 나머지 가이드를 따를 때 ZMK의 메인 저장소의
app/디렉터리 대신 사용자 저장소의config/디렉터리를 사용하십시오. 예를 들어,app/boards/shields/키보드명대신config/boards/shields/키보드명이 됩니다.
제피어Zephyr 어플리케이션의 쉴드는 boards/shiels 디렉터리 하위에 위치합니다; ZMK의 제피어 어플리케이션은 app/ 서브디렉터리에 있기 때문에, 새 쉴드 디렉터리는:
mkdir app/boards/shields/키보드명
이 되게 됩니다.
ZMK가 새 키보드 쉴드를 잡아내기 위해서는 Kconfig 파일이 두 개 필요합니다. Kconfig.shield 파일과 Kconfig.defconfig 파일입니다.
Kconfig.shield 파일은 해당 키보드를 사용할 때 관련있는 Kconfig 세팅을 정의합니다. 대부분의 키보드에서는, 쉴드 자체로는 한 가지 설정 값만이 있는데, 예를 들어:
config SHIELD_MY_BOARD
def_bool $(shields_list_contains, my_board)
이는 my_board가 빌드에 쉴드로 추가될 때마다 SHIELD_MY_BOARD 값이 참으로 설정되도록 할 것입니다.
스플릿 키보드에서는, 왼쪽 절반과 오른쪽 절반을 각각 추가 정의해야 합니다.
config SHIELD_MY_BOARD_LEFT
def_bool $(shields_list_contains,my_board_left)
config SHIELD_MY_BOARD_RIGHT
def_bool $(shields_list_contains,my_board_right)
Kconfig.defconfig 파일은 쉴드가 사용될 때 여러 기본 설정값들을 덮어쓰기하는 파일입니다. 주로 새 값을 덮어쓰기하는 한 가지 항목은 ZMK_KEYBOARD_NAME 값으로, USB나 BLE로 연결했을 때 나타나는 키보드의 이름값을 제어합니다.
업데이트되는 새 기본 값은 언제나 Kconfig.shield 파일 안의 쉴드 설정 이름의 조건문으로 싸여있어야 합니다. 아래는 간단한 작은 예시 파일입니다.
주의
키보드 명을 너무 길게 하지 않도록 합니다. 그렇지 않으면 블루투스 연결Bluetooth advertising 에 실패하고 귀하의 키보드를 랩탑/태블릿에서 발견할 수 없을 수도 있습니다.
if SHIELD_MY_BOARD
config ZMK_KEYBOARD_NAME
default "My Awesome Keyboard"
endif
Kconfig.shield 에서 스플릿 키보드의 반 쪽씩 정의했던 것과 비슷하게 ZMK_KEYBOARD_NAME을 설정할 때도 각 절반 씩을 설정하는 것이 중요합니다. 또한 어느 쪽이 중심 쪽인지 설정해야 합니다. 대부분의 보드는 왼쪽을 (중심으로) 설정합니다. 그리고 부속되는 절반에는 USB를 켜서 USB 상황을 제대로 보여주도록 설정합니다. 끝으로 양쪽 모두에서 스플릿 옵션을 켜주도록 합니다. 이런 내용은 아래에서 볼 수 있습니다.
if SHIELD_MY_BOARD_LEFT
config ZMK_KEYBOARD_NAME
default "My Awesome Keyboard"
config ZMK_SPLIT_BLE_ROLE_CENTRAL
default y
endif
if SHIELD_MY_BOARD_LEFT || SHIELD_MY_BOARD_RIGHT
config ZMK_SPLIT
default y
endif
ZMK는 파란색으로 색칠된 핀 이름을 사용해서 디바이스트리 노드 레퍼런스를 생성합니다. 예를 들어 노드 0을 디바이스 트리에서 특정하려면, &pro_micro 0 처럼 사용합니다.
* 유니바디 쉴드 항목이 별도로 있긴 한데 어쨌든 제가 만드는 건 스플릿 키보드가 주(主)기 때문에 스플릿 쉴드를 우선으로 다룹니다. 이후 시간이 나면 유니바디 쉴드도 한글화할지도 모르겠습니다. 디스코드에 물어보니 docsauraus가 다국어 번역 지원을 하는지 확인을 해야 한다고 하니 일단 따로 번역하여 올립니다(역자주)
유니바디 키보드와 달리, 스플릿 키보드는 코어 .dtsi 파일과 쉴드 오버레이를 각 절반마다 가집니다. 일반적으로 diode-direction 값에 따라 공통common .dtsi 쉴드에 col-gpios 또는 row-gpios 만을 정의하는 것이 선호됩니다. iris와 같은 col2row 방향의 보드에서는, 공통shared .dtsi 파일은 아래와 같을 것입니다.
#include <dt-bindings/zmk/matrix_transform.h>
/ {
chosen {
zmk,kscan = &kscan0;
zmk,matrix_transform = &default_transform;
};
default_transform: keymap_transform_0 {
compatible = "zmk,matrix-transform";
columns = <16>;
rows = <4>;
// | SW6 | SW5 | SW4 | SW3 | SW2 | SW1 | | SW1 | SW2 | SW3 | SW4 | SW5 | SW6 |
// | SW12 | SW11 | SW10 | SW9 | SW8 | SW7 | | SW7 | SW8 | SW9 | SW10 | SW11 | SW12 |
// | SW18 | SW17 | SW16 | SW15 | SW14 | SW13 | | SW13 | SW14 | SW15 | SW16 | SW17 | SW18 |
// | SW24 | SW23 | SW22 | SW21 | SW20 | SW19 | SW25 | | SW25 | SW19 | SW20 | SW21 | SW22 | SW23 | SW24 |
// | SW29 | SW28 | SW27 | SW26 | | SW26 | SW27 | SW28 | SW29 |
map = <
RC(0,0) RC(0,1) RC(0,2) RC(0,3) RC(0,4) RC(0,5) RC(0,6) RC(0,7) RC(0,8) RC(0,9) RC(0,10) RC(0,11)
RC(1,0) RC(1,1) RC(1,2) RC(1,3) RC(1,4) RC(1,5) RC(1,6) RC(1,7) RC(1,8) RC(1,9) RC(1,10) RC(1,11)
RC(2,0) RC(2,1) RC(2,2) RC(2,3) RC(2,4) RC(2,5) RC(2,6) RC(2,7) RC(2,8) RC(2,9) RC(2,10) RC(2,11)
RC(3,0) RC(3,1) RC(3,2) RC(3,3) RC(3,4) RC(3,5) RC(4,2) RC(4,9) RC(3,6) RC(3,7) RC(3,8) RC(3,9) RC(3,10) RC(3,11)
RC(4,3) RC(4,4) RC(4,5) RC(4,6) RC(4,7) RC(4,8)
>;
};
kscan0: kscan {
compatible = "zmk,kscan-gpio-matrix";
label = "KSCAN";
diode-direction = "col2row";
row-gpios
= <&pro_micro 6 (GPIO_ACTIVE_HIGH | GPIO_PULL_DOWN)> // Row A from the schematic file
, <&pro_micro 7 (GPIO_ACTIVE_HIGH | GPIO_PULL_DOWN)> // Row B from the schematic file
, <&pro_micro 8 (GPIO_ACTIVE_HIGH | GPIO_PULL_DOWN)> // Row C from the schematic file
, <&pro_micro 0 (GPIO_ACTIVE_HIGH | GPIO_PULL_DOWN)> // Row D from the schematic file
, <&pro_micro 4 (GPIO_ACTIVE_HIGH | GPIO_PULL_DOWN)> // Row E from the schematic file
;
};
};
NOTE:
kscan에서 정의된 공통
row-gopis에 더하여 매트릭스 변환transform도 .dtsi 파일에서 정의된 것에 유의
여기에 없는missing col-gpios 는 <boardname>_left.overlay와 <boardname>_right.overlay 파일에서 정의될 것입니다. 명심해야 할 것은, GPIO의 대칭 위치는 col-gpios도 .overlay 파일에서도 서로 뒤집힌 걸로 나타날 것이라는 점입니다. 또한, 매트릭스 변환 의 컬럼 오프셋은 우측 절반에 더해져야 하는데, 이는 키보드의 스위치 매트릭스가 왼쪽에서 오른쪽으로, 위에서 아래로 읽히기 때문입니다. 아래는 iris의 .overlay 파일입니다.
// iris_left.overlay
#include "iris.dtsi" // Notice that the main dtsi files are included in the overlay.
&kscan0 {
col-gpios
= <&pro_micro 19 GPIO_ACTIVE_HIGH> // col1 in the schematic
, <&pro_micro 18 GPIO_ACTIVE_HIGH> // col2 in the schematic
, <&pro_micro 15 GPIO_ACTIVE_HIGH> // col3 in the schematic
, <&pro_micro 14 GPIO_ACTIVE_HIGH> // col4 in the schematic
, <&pro_micro 16 GPIO_ACTIVE_HIGH> // col5 in the schematic
, <&pro_micro 10 GPIO_ACTIVE_HIGH> // col6 in the schematic
;
};
// iris_right.overlay
#include "iris.dtsi"
&default_transform { // The matrix transform for this board is 6 columns over because the left half is 6 columns wide according to the matrix.
col-offset = <6>;
};
&kscan0 {
col-gpios
= <&pro_micro 10 GPIO_ACTIVE_HIGH> // col6 in the schematic
, <&pro_micro 16 GPIO_ACTIVE_HIGH> // col5 in the schematic
, <&pro_micro 14 GPIO_ACTIVE_HIGH> // col4 in the schematic
, <&pro_micro 15 GPIO_ACTIVE_HIGH> // col3 in the schematic
, <&pro_micro 18 GPIO_ACTIVE_HIGH> // col2 in the schematic
, <&pro_micro 19 GPIO_ACTIVE_HIGH> // col1 in the schematic
;
};
유니바디 보드는 키보드 전체의 특성characteristics을 설정하는 .conf 파일을 한 가지만 갖는 반면, 스플릿 키보드는 다수의 .conf 파일을 포함해서 여러 상이한 범위scope에 설정을 한다는 점에서 독특합니다. 예를 들어, my_awesome_split_board 라는 스플릿 보드는 아래와 같은 파일을 가질 수 있습니다:
my_awsome_split_board.conf- 양쪽 모두에 영향을 미치는 요소element를 설정my_awesome_split_board_left.conf- 왼쪽에만 영향을 미치는 요소를 설정my_awesome_split_board_right.conf- 오르쪽에만 영향을 미치는 요소를 설정
대부분의 경우 양쪽 보드 모두에 영향을 미치는 .conf 파일만이 필요합니다. 이는 딥-슬립deep-sleep 이나 로터리 엔코더rotary encoder의 설정에 사용됩니다.
// my_awesome_split_board.conf
CONFIG_ZMK_SLEEP=y
NOTE:
my_awesome_split_board.conf의 공유 설정은zmk-config폴더에서 빌드할 때 (.conf 파일이)config/my_awesome_split_board.conf에 있는 경우에만 적용됩니다.zmk-config폴더를 사용하지 않는다면, 공유 설정을my_awesome_split_board_left.conf파일과my_awesome_split_board_right.conf양 쪽 모두에 추가해주어야 합니다.
내부적으로 ZMK는 모든 행/열 이벤트를 "키 위치position" 이벤트로 변환하여 특정 키보드에서 어떤 GPIO 매트릭스를 사용하든 일관된 모델을 유지하도록 합니다. 이는 아래와 같은 경우 매우 유용합니다:
- 사용되는 핀의 갯수를 경감하고, 물리적 키 스위치의 행/열 배치와 일치하지 않는 GPIO 매트릭스에 대한 "효율적인" 행/열 사용.
- 비-직사각형 + 엄지 클러스터 키보드의
1u외 키 버튼 위치 등등
"키 위치"는 해당 키의 숫자 인덱스(0-인덱스)로, 종단 사용자에 의해 인식되는 키의 논리적 위치를 나타냅니다.(뭔소리여 ㅅㅂ) 모든 키맵 맵핑은 실제로 행/렬 값이 아니라 키 위치 의 동작behaviours에 종속bind됩니다.
의도적으로 각 키 위치를 해당하는 행/렬 쌍으로 맵핑해주는 매트릭스 변환이 없는 경우, 키의 위치 값을 산출하는 기본 공식은 아래와 같습니다:
($row * NUMBER_OF_COLUMNS) + $column
키 위치를 결정함에 있어서 각 행을 상하로 가로지르면서 더하고 좌우로 더하는 방법입니다.
기본 키 위치 맵핑이 부족하다면, 언제든 <shield_name>.overlay 파일은 매트릭스 변환을 포함시키면 됩니다.
아래는 nice60 의 예시가 있습니다. 8x8 GPIO 매트릭스로 변환을 사용하고 있습니다:
#include <dt-bindings/zmk/matrix_transform.h>
/ {
chosen {
zmk,kscan = &kscan0;
zmk,matrix_transform = &default_transform;
};
default_transform: keymap_transform_0 {
compatible = "zmk,matrix-transform";
columns = <8>;
rows = <8>;
// | MX1 | MX2 | MX3 | MX4 | MX5 | MX6 | MX7 | MX8 | MX9 | MX10 | MX11 | MX12 | MX13 | MX14 |
// | MX15 | MX16 | MX17 | MX18 | MX19 | MX20 | MX21 | MX22 | MX23 | MX34 | MX25 | MX26 | MX27 | MX28 |
// | MX29 | MX30 | MX31 | MX32 | MX33 | MX34 | MX35 | MX36 | MX37 | MX38 | MX39 | MX40 | MX41 |
// | MX42 | MX43 | MX44 | MX45 | MX46 | MX47 | MX48 | MX49 | MX50 | MX51 | MX52 | MX53 |
// | MX54 | MX55 | MX56 | MX57 | MX58 | MX59 | MX60 | MX61 |
map = <
RC(3,0) RC(2,0) RC(1,0) RC(0,0) RC(1,1) RC(0,1) RC(0,2) RC(1,3) RC(0,3) RC(1,4) RC(0,4) RC(0,5) RC(1,6) RC(1,7)
RC(4,0) RC(4,1) RC(3,1) RC(2,1) RC(2,2) RC(1,2) RC(2,3) RC(3,4) RC(2,4) RC(2,5) RC(1,5) RC(2,6) RC(2,7) RC(3,7)
RC(5,0) RC(5,1) RC(5,2) RC(4,2) RC(3,2) RC(4,3) RC(3,3) RC(4,4) RC(4,5) RC(3,5) RC(4,6) RC(3,6) RC(4,7)
RC(6,0) RC(6,1) RC(6,2) RC(6,3) RC(5,3) RC(6,4) RC(5,4) RC(6,5) RC(5,5) RC(6,6) RC(5,6) RC(5,7)
RC(7,0) RC(7,1) RC(7,2) RC(7,3) RC(7,5) RC(7,6) RC(6,7) RC(7,7)
>;
};
유의해서 보아야 할 점들은:
#include <dt-bindings/zmk/matrix_transform.h>는 필수적입니다.RC매크로는 매트릭스 변환 내에서 내부 공간을 생성하기 위해 사용되었으며, 디바이스 트리가 ZMK로 컴파일 되기 전에 C 전처리기에 의해 대체됩니다.(뭔소리야 ㅅㅂㅅㅂ2)RC(row, column)는 각 위치에 해당하는 행과 열 값으로 순차적으로 배치되었습니다.- 만일 특정 위치에
2u키가 있는 키보드를 선택하였다면, 또는 깨지는 부분break away portion이 있다면, 선택된zmk,matrix_transform을 기본 배열arrangement로 두고, 다른 가능한 매트릭스 변환 노드를 디바이스 트리에 포험시켜서 사용자 설정에서 개별 노드로 덮어쓰기 할 수 있도록 하는 것이 좋습니다.
각 키보드는 출고 시점부터OOTB(Out of the box) 초기 키맵을 제공하여 펌웨어를 빌드할 때, 덮어쓰거나 사용자 설정에 의해 커스터마이즈 할 수 있도록 하여야 합니다. "쉴드 키보드"에 대해서는 이는 app/boards/shields/<shield_name>/<shield_name>,keymap 파일에 위치합니다. 키맵은 이하 내용을 포함하는 추가적인 디바이스 트리 오버레이로 구성됩니다:
- 매 개별 하위 노드가
bindings어레이를 갖는 레이어이며——bindings어레이는 각 키 위치에 개별 동작behaviour(예를 들어 키 입력, 임시momentarily 레이어)이 할당된 레이어——인compatible="zmk,keymap"노드.
아래는 키리아에서 단 한 개의 레이어를 갖는 간단한 예시 키맵입니다:
#include <behaviors.dtsi>
#include <dt-bindings/zmk/keys.h>
/ {
keymap {
compatible = "zmk,keymap";
default_layer {
// --------------------------------------------------------------------------------------------------------------------------------------------------------------------
// | ESC | Q | W | E | R | T | | Y | U | I | O | P | \ |
// | TAB | A | S | D | F | G | | H | J | K | L | ; | ' |
// | SHIFT | Z | X | C | V | B | CTRL+A | CTRL+C | | CTRL+V | CTRL+X | N | M | , | . | / | R CTRL |
// | GUI | DEL | RETURN | SPACE | ESCAPE | | RETURN | SPACE | TAB | BSPC | R ALT |
bindings = <
&kp ESC &kp Q &kp W &kp E &kp R &kp T &kp Y &kp U &kp I &kp O &kp P &kp BSLH
&kp TAB &kp A &kp S &kp D &kp F &kp G &kp H &kp J &kp K &kp L &kp SEMI &kp SQT
&kp LSHIFT &kp Z &kp X &kp C &kp V &kp B &kp LC(A) &kp LC(C) &kp LC(V) &kp LC(X) &kp N &kp M &kp COMMA &kp DOT &kp FSLH &kp RCTRL
&kp LGUI &kp DEL &kp RET &kp SPACE &kp ESC &kp RET &kp SPACE &kp TAB &kp BSPC &kp RALT
>;
sensor-bindings = <&inc_dec_kp C_VOL_UP C_VOL_DN &inc_dec_kp PG_UP PG_DN>;
};
};
};
NOTE:
키맵 파일 최상단에 위치한 두 줄
#include는 가능한 기본적인 동작들의 집합을 가져와서 할당bind할 수 있도록 하기 위함입니다. 또한 키 코드에 대한 정의의 집합을 불러와서 키맵이 로raw 키 코드 대신N2나K같은 파라미터를 사용할 수 있게 하기 위함입니다.
동작behaviours 과 할당bindings 에 관한 추가적인 문서화 작업은 진행중forthcoming이지만, 현재 키에 할당할 수 있는 동작은 다음과 같습니다:
kp는 "key press" 동작으로, "keyboard/keypad" HID 사용 테이블에서 단일 키 코드를 인수로 받습니다.(뭔소리야 ㅅㅂㅅㅂ3)mo는 "momentary layer" 동작으로, 숫자 ID를 단일 인수로 받아 키가 눌린 동안 해당 레이어를 일시적으로 활성화시킵니다.trans는 "transparent" 동작으로,mo할당 레이어 위에서 해당 키가 하위 레이어에서 처리됨을 확인할 때 유용합니다. 할당 인수를 요하지 않습니다.mt는 "mod-tap" 동작으로, 두 개의 인수를 받으며, 각 인수는 길게 누르고 있는 동안 할당할 키와, 짧게 누르는 동안 송신할 키 코드로 구성됩니다.
ZMK는 YAML 파일의 추가적인 데이터를 활용하여 모든 보드와 쉴드에 하드웨어에 관련한 고차원의 정보를 제공하여 셋업 스크립트/유틸리티, 웹사이트 하드웨어 리스트 등에 취합incorporate하려 합니다.
메타데이터 파일의 통상적인 형태는 {item_id}.zmk.yml 이며, item_id 에는 보드/쉴드 식별자가 포함되고, 이는 버전 정보를 포함하나 _left / _right 같은 접미사는 붙지 않습니다. 예시) corne.zmk.yml 또는 nrfmicro_11.zmk.yml
아래는 저장소에서의 corne.zmk.yml 의 예시입니다.
file_format: "1"
id: corne
name: Corne
type: shield
url: https://github.com/foostan/crkbd/
requires: [pro_micro]
exposes: [i2c_oled]
features:
- keys
- display
siblings:
- corne_left
- corne_right
foo.zmk.yml 이름으로 된 파일을 다른 쉴드 값들과 같이 위치시켜야 하며, 정확하고 완전하게 항목을 채워야 합니다. 자세한 내용은 하드웨어 메타데이터 파일 항목을 참조하세요.
아래 라인을 보드/쉴드 설정(.conf), 디바이스 트리(.dtsi), 오버레이(.overlay), 키맵(.keymap) 파일에 적절히 추가함으로써 EC11 인코더 지원을 추가할 수 있습니다.
설정 파일에 아래 라인을 추가하여 인코더를 활성/비활성화 시킬 수 있습니다.
# Uncomment to enable encoder
# CONFIG_EC11=y
# CONFIG_EC11_TRIGGER_GLOBAL_THREAD=y
인코더가 부수적이거나 스위치로 대체될 수 있는 디자인에서는 위 코드는 주석 처리되어야 하나, 기본 디자인에 인코더가 포함되는 경우에는 주석처리하지 않아도 무방합니다.
디바이스 트리 파일에 아래 라인을 추가하여 인코더 센서를 정의해야 합니다.
left_encoder: encoder_left {
compatible = "alps,ec11";
label = "LEFT_ENCODER";
a-gpios = <PIN_A (GPIO_ACTIVE_HIGH | GPIO_PULL_UP)>;
b-gpios = <PIN_B (GPIO_ACTIVE_HIGH | GPIO_PULL_UP)>;
resolution = <4>;
};
PIN_A 와 PIN_B를 PCB에 따라 알맞을 핀 번호로 교체해야 합니다. Pro Micro나 유사 대체품에 관하여 Sparkfun의 Pro Micro Hookup Guide 에는 알맞은 핀을 결정하기 위한 훌륭한 핀 아웃 다이어그램이 있습니다. "Arduino"(디지털 핀)로 라벨링 된 파란 숫자 또는 "Analog"(아날로그 핀)로 라벨링 된 초록 숫자를 참조하십시오. 디지털과 아닐로그로 모두 라벨링된 핀에 대하여, 개별 .dtsi 파일에서 참조해야 하는 방식을 확인할 수 있습니다.
필요한만큼 위의 코드를 복사하여 추가적인 인코더를 더하십시오. left 를 각 인코더 명에 맞게 변경하고, 대응 핀을 수정하십시오. 부속peripheral 기기 센서의 블루투스 통신은 아직 개발중에 있음을 주지하여 주시기 바랍니다.
인코더 센서를 정의한 후에, 센서 리스트에 인코더를 추가해야 합니다.
sensors {
compatible = "zmk,keymap-sensors";
sensors = <&left_encoder &right_encoder>;
};
위 예시에서는, left_encoder 와 right_encoder 가 모두 추가되었습니다. 추가분의 인코더 또한 띄어씀으로써 추가가 가능하며, 여기에 추가된 순서가 키 맵핑 과정에서 각 동작을 지정하는 순서가 됩니다.
아래 라인을 오버레이 파일에 추가하여 인코더를 활성화합니다.
&left_encoder {
status = "okay";
};
NOTE:
스플릿 키보드에 대하여, 좌측 인코더는 좌측 오버레이 파일에, 우측 인코더는 우측 오버레이 파일에 추가하여야 합니다.
아래 라인을 키 맵 파일에 추가하여 기본 인코더 동작을 할당합니다.
sensor-bindings = <&inc_dec_kp C_VOL_UP C_VOL_DN>;
보드에 있는 인코더 숫자와 맞을 때까지 동작 할당bindings 을 추가하십시오. 추가적인 내용에 관하여는 인코더와 키 맵 기능 문서를 확인하십시오.
새 키보드 쉴드 정의가 완성되었다면 아래의 빌드 명령어를 사용하여 테스트할 수 있습니다.
west build --pristine -b proton_c -- -DSHIELD=my_board
위의 빌드 명령어는 build/zephyr/zmk.uf2 파일을 생성합니다. 만일 보드가 USB 플래싱 포맷(UF2)를 지원한다면, USB 대용량 저장장치의 최상단에 파일을 복사합니다. 이후 컨트롤러가 제작된 펌웨어를 플래싱하고 플래싱이 완료되면 자동으로 기기를 재부팅 시킬 것입니다.
이외에, 보드가 플래싱을 지원하고, 도커화된 환경에서 개발하는 것이 아닌 경우, 보드에서 Device Firmware Upgrade(DFU) 모드를 활성화하고 아래 명령어를 입력하여 빌드를 테스트할 수 있습니다:
west flash
추가적인 내용은 빌드 및 플래시 문서의 해당 항목을 참조하십시오.
NOTE:
루트 키맵 파일을 건드리지 않고 키보드 쉴드만을 테스트하는 것은
west build명령어에-DZMK_CONFIG를 사용함으로써 가능합니다. 항목 참조
Good