# 调试的常见问题
本篇详细介绍了人们在键盘故障排除时的各种常见问题。
# 调试控制台
## `hid_listen` 无法识别设备
当设备的调试控制台未就绪时，您将看到如下内容：
```
Waiting for device:.........
```
插入设备后，*hid_listen*找到该设备，您将收到以下消息：
```
Waiting for new device:.........................
Listening:
```
如果您无法获得这条“Listening:”消息，请尝试在[Makefile]中使用 `CONSOLE_ENABLE=yes`
在Linux这样的操作系统上，你可能需要一些权限。
- 使用`sudo hid_listen`
## 控制台没有返回消息
检查:
- *hid_listen* 找到了你的设备。看前面。
- 输入**Magic**+d打开调试。详见[Magic Commands](https://github.com/tmk/tmk_keyboard#magic-commands)。
- 设置`debug_enable=true` ，一般存在于**matrix.c**的`matrix_init()`中。
- 尝试使用'print'函数而不要用调试输出。详见**common/print.h**。
- 断开其他有控制台功能的设备。 详见[Issue #97](https://github.com/tmk/tmk_keyboard/issues/97)。
## Linux或UNIX这样的系统如何请求超级用户权限
用'sudo'来执行*hid_listen*就有权限了。
```
$ sudo hid_listen
```
或者把一个文件放到规则文件夹来为TMK设备添加*udev规则*，不同系统的目录可能有所不同。
文件: /etc/udev/rules.d/52-tmk-keyboard.rules(在Ubuntu系统的情况下)
```
# tmk keyboard products https://github.com/tmk/tmk_keyboard
SUBSYSTEMS=="usb", ATTRS{idVendor}=="feed", MODE:="0666"
```
***
# 其他
## 安全注意事项
你应该不想要把你的键盘变成"砖头"吧，就是变成没法重写固件的那种。
下面讲解一些参数来告诉你什么风险很大（其实也不是很大）。
- 假如你键盘表面没有设计重置键"RESET", 那你要进入bootloader的话就要按PCB上的RESET了。
按PCB上的RESET要拧开键盘底部。
- 如果 tmk_core / common 里面的文件丢失键盘可能失灵。
- .hex太大可能不太好; `make dfu` 会删除块，检验大小（咦?好像反了...）。
一但出错，刷新键盘失败的话就困在DFU出不去了。
- 所以, 要知道大小限制。 Planck键盘上.hex文件最大大小是 is 7000h (十进制是28672)
```
Linking: .build/planck_rev4_cbbrowne.elf [OK]
Creating load file for Flash: .build/planck_rev4_cbbrowne.hex [OK]
Size after:
text data bss dec hex filename
0 22396 0 22396 577c planck_rev4_cbbrowne.hex
```
- 上面那个文件大小是 22396/577ch，比28672/7000h小
- 当你有一个合适的.hex文件时，你就要重试加载那个了
- 您在键盘Makefile中的某些选项可能消耗额外内存；注意以下这几个
BOOTMAGIC_ENABLE, MOUSEKEY_ENABLE, EXTRAKEY_ENABLE, CONSOLE_ENABLE, API_SYSEX_ENABLE
- DFU 工具/不/可以写入bootloader (unless you throw in extra fruit salad of options),
所以还是有点危险的
- EEPROM大概有100000次循环寿命。不要总是频繁重写固件；EEPROM会玩坏的。
## 全键无冲不好用
首先你要在**Makefile**用如下命令编译固件`NKRO_ENABLE`。
全键无冲还不好用的话试着用`Magic` **N** 命令(默认是`LShift+RShift+N`)。这个命令会在**全键无冲**和**六键无冲**之间临时切换。有些情况**全键无冲**不好用你就需要使用**六键无冲**模式，尤其是在BIOS中。
如果你的固件使用`BOOTMAGIC_ENABLE`编译的你要用`BootMagic` **N** 命令(默认`Space+N`)打开开关。这个设置保存在EEPROM中并保存在电源循环中。
https://github.com/tmk/tmk_keyboard#boot-magic-configuration---virtual-dip-switch
## 指点杆需要复位电路(PS/2 鼠标支持)
如果没有复位电路，由于硬件初始化不正确，您将得到不一致的结果。查看TPM754复位电路。
- http://geekhack.org/index.php?topic=50176.msg1127447#msg1127447
- http://www.mikrocontroller.net/attachment/52583/tpm754.pdf
## 矩阵不可读16以上的列
当列超过16时[matrix.h]的`read_cols()`中，用`1UL<<16`而不要用`1<<16`。
在C语言中`1` 是一个[int] 类型的[16 bit]值，在AVR中你不能左移大于15次。如果你使用`1<<16`的话会得到意外的零。你要用 [unsigned long]类型，比如`1UL`。
http://deskthority.net/workshop-f7/rebuilding-and-redesigning-a-classic-thinkpad-keyboard-t6181-60.html#p146279
## 特殊额外键不起作用(系统，音频控制键)
你要在`rules.mk`定义`EXTRAKEY_ENABLE`在QMK中使用它们。
```
EXTRAKEY_ENABLE = yes # 音频控制和系统控制
```
## 睡眠唤醒不好用
在Windows查看设备管理器中该键盘设备属性中电源管理选项卡中的`允许此设备唤醒计算机(O)`是否勾选。同时看一眼BIOS设置。
在主机睡眠时按下任何键都可以唤醒了。
## 使用Arduino?
**注意Arduino的针脚名字和主控芯片的不一样。** 比如, Arduino的`D0`并不是`PD0`。自己用原理图捋一下电路。
- http://arduino.cc/en/uploads/Main/arduino-leonardo-schematic_3b.pdf
- http://arduino.cc/en/uploads/Main/arduino-micro-schematic.pdf
Arduino Leonardo和micro使用**ATMega32U4**，该芯片TMK可用，但Arduino的bootloader会导致问题。
## USB 3 兼容性
据传说有些人用USB3接口会有问题，用USB2的试试。
## Mac 兼容性
### OS X 10.11 和集线器
https://geekhack.org/index.php?topic=14290.msg1884034#msg1884034
## 对于BIOS (UEFI)/恢复(睡眠和唤醒)/重新启动 有问题
有人说他们的键盘在BIOS中，或许是恢复(睡眠和唤醒)后不工作.
截止至目前，其根本原因未知，不排除与某些构建选项有关。试着在Makefile中失能`CONSOLE_ENABLE`, `NKRO_ENABLE`, `SLEEP_LED_ENABLE`这样的选项，也试试其他的。
https://github.com/tmk/tmk_keyboard/issues/266
https://geekhack.org/index.php?topic=41989.msg1967778#msg1967778
96' href='#n96'>96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
# QMK Keyboard Guidelines
Since starting, QMK has grown by leaps and bounds thanks to people like you who contribute to creating and maintaining our community keyboards. As we've grown we've discovered some patterns that work well, and ask that you conform to them to make it easier for other people to benefit from your hard work.
## Naming Your Keyboard/Project
All keyboard names are in lower case, consisting only of letters, numbers, and underscore (`_`). Names may not begin with an underscore. Forward slash (`/`) is used as a sub-folder separation character.
The names `test`, `keyboard`, and `all` are reserved for make commands and may not be used as a keyboard or subfolder name.
Valid Examples:
* `412_64`
* `chimera_ortho`
* `clueboard/66/rev3`
* `planck`
* `v60_type_r`
## Sub-folders
QMK uses sub-folders both for organization and to share code between revisions of the same keyboard. You can nest folders up to 4 levels deep:
qmk_firmware/keyboards/top_folder/sub_1/sub_2/sub_3/sub_4
If a sub-folder has a `rules.mk` file it will be considered a compilable keyboard. It will be available in QMK Configurator and tested with `make all`. If you are using a folder to organize several keyboards from the same maker you should not have a `rules.mk` file.
Example:
Clueboard uses sub-folders for both purposes, organization and keyboard revisions.
* [`qmk_firmware`](https://github.com/qmk/qmk_firmware/tree/master)
* [`keyboards`](https://github.com/qmk/qmk_firmware/tree/master/keyboards)
* [`clueboard`](https://github.com/qmk/qmk_firmware/tree/master/keyboards/clueboard) ← This is the organization folder, there's no `rules.mk` file
* [`60`](https://github.com/qmk/qmk_firmware/tree/master/keyboards/clueboard/60) ← This is a compilable keyboard, it has a `rules.mk` file
* [`66`](https://github.com/qmk/qmk_firmware/tree/master/keyboards/clueboard/66) ← This is also compilable- it uses `DEFAULT_FOLDER` to specify `rev3` as the default revision
* [`rev1`](https://github.com/qmk/qmk_firmware/tree/master/keyboards/clueboard/66/rev1) ← compilable: `make clueboard/66/rev1`
* [`rev2`](https://github.com/qmk/qmk_firmware/tree/master/keyboards/clueboard/66/rev2) ← compilable: `make clueboard/66/rev2`
* [`rev3`](https://github.com/qmk/qmk_firmware/tree/master/keyboards/clueboard/66/rev3) ← compilable: `make clueboard/66/rev3` or `make clueboard/66`
## Keyboard Folder Structure
Your keyboard should be located in `qmk_firmware/keyboards/` and the folder name should be your keyboard's name as described in the previous section. Inside this folder should be several files:
* `readme.md`
* `info.json`
* `config.h`
* `rules.mk`
* `<keyboard_name>.c`
* `<keyboard_name>.h`
### `readme.md`
All projects need to have a `readme.md` file that explains what the keyboard is, who made it and where it's available. If applicable, it should also contain links to more information, such as the maker's website. Please follow the [published template](documentation_templates.md#keyboard-readmemd-template).
### `info.json`
This file is used by the [QMK API](https://github.com/qmk/qmk_api). It contains the information [QMK Configurator](https://config.qmk.fm/) needs to display a representation of your keyboard. You can also set metadata here. For more information see the [reference page](reference_info_json.md).
### `config.h`
All projects need to have a `config.h` file that sets things like the matrix size, product name, USB VID/PID, description and other settings. In general, use this file to set essential information and defaults for your keyboard that will always work.
The `config.h` files can also be placed in sub-folders, and the order in which they are read is as follows:
* `keyboards/top_folder/config.h`
* `keyboards/top_folder/sub_1/config.h`
* `keyboards/top_folder/sub_1/sub_2/config.h`
* `keyboards/top_folder/sub_1/sub_2/sub_3/config.h`
* `keyboards/top_folder/sub_1/sub_2/sub_3/sub_4/config.h`
* `users/a_user_folder/config.h`
* `keyboards/top_folder/keymaps/a_keymap/config.h`
* `keyboards/top_folder/sub_1/sub_2/sub_3/sub_4/post_config.h`
* `keyboards/top_folder/sub_1/sub_2/sub_3/post_config.h`
* `keyboards/top_folder/sub_1/sub_2/post_config.h`
* `keyboards/top_folder/sub_1/post_config.h`
* `keyboards/top_folder/post_config.h`
The `post_config.h` file can be used for additional post-processing, depending on what is specified in the `config.h` file. For example, if you define the `IOS_DEVICE_ENABLE` macro in your keymap-level `config.h` file as follows, you can configure more detailed settings accordingly in the `post_config.h` file:
* `keyboards/top_folder/keymaps/a_keymap/config.h`
```c
#define IOS_DEVICE_ENABLE
```
* `keyboards/top_folder/post_config.h`
```c
#ifndef IOS_DEVICE_ENABLE
// USB_MAX_POWER_CONSUMPTION value for this keyboard
#define USB_MAX_POWER_CONSUMPTION 400
#else
// fix iPhone and iPad power adapter issue
// iOS device need lessthan 100
#define USB_MAX_POWER_CONSUMPTION 100
#endif
#ifdef RGBLIGHT_ENABLE
#ifndef IOS_DEVICE_ENABLE
#define RGBLIGHT_LIMIT_VAL 200
#define RGBLIGHT_VAL_STEP 17
#else
#define RGBLIGHT_LIMIT_VAL 35
#define RGBLIGHT_VAL_STEP 4
#endif
#ifndef RGBLIGHT_HUE_STEP
#define RGBLIGHT_HUE_STEP 10
#endif
#ifndef RGBLIGHT_SAT_STEP
#define RGBLIGHT_SAT_STEP 17
#endif
#endif
```
?> If you define options using `post_config.h` as in the above example, you should not define the same options in the keyboard- or user-level `config.h`.
### `rules.mk`
The presence of this file means that the folder is a keyboard target and can be used in `make` commands. This is where you setup the build environment for your keyboard and configure the default set of features.
The `rules.mk` file can also be placed in a sub-folder, and its reading order is as follows:
* `keyboards/top_folder/rules.mk`
* `keyboards/top_folder/sub_1/rules.mk`
* `keyboards/top_folder/sub_1/sub_2/rules.mk`
* `keyboards/top_folder/sub_1/sub_2/sub_3/rules.mk`
* `keyboards/top_folder/sub_1/sub_2/sub_3/sub_4/rules.mk`
* `keyboards/top_folder/keymaps/a_keymap/rules.mk`
* `users/a_user_folder/rules.mk`
* `common_features.mk`
Many of the settings written in the `rules.mk` file are interpreted by `common_features.mk`, which sets the necessary source files and compiler options.
?> See `build_keyboard.mk` and `common_features.mk` for more details.
### `<keyboard_name.c>`
This is where you will write custom code for your keyboard. Typically you will write code to initialize and interface with the hardware in your keyboard. If your keyboard consists of only a key matrix with no LEDs, speakers, or other auxiliary hardware this file can be blank.
The following functions are typically defined in this file:
* `void matrix_init_kb(void)`
* `void matrix_scan_kb(void)`
* `bool process_record_kb(uint16_t keycode, keyrecord_t *record)`
* `void led_set_kb(uint8_t usb_led)`
### `<keyboard_name.h>`
This file is used to define the matrix for your keyboard. You should define at least one C macro which translates an array into a matrix representing the physical switch matrix for your keyboard. If it's possible to build your keyboard with multiple layouts you should define additional macros.
If you have only a single layout you should call this macro `LAYOUT`.
When defining multiple layouts you should have a base layout, named `LAYOUT_all`, that supports all possible switch positions on your matrix, even if that layout is impossible to build physically. This is the macro you should use in your `default` keymap. You should then have additional keymaps named `default_<layout>` that use your other layout macros. This will make it easier for people to use the layouts you define.
Layout macro names are entirely lowercase, except for the word `LAYOUT` at the front.
As an example, if you have a 60% PCB that supports ANSI and ISO you might define the following layouts and keymaps:
| Layout Name | Keymap Name | Description |
|-------------|-------------|-------------|
| LAYOUT_all | default | A layout that supports both ISO and ANSI |
| LAYOUT_ansi | default_ansi | An ANSI layout |
| LAYOUT_iso | default_iso | An ISO layout |
## Image/Hardware Files
In an effort to keep the repo size down we're no longer accepting binary files of any format, with few exceptions. Hosting them elsewhere (such as <https://imgur.com>) and linking them in the `readme.md` is preferred.
Hardware files (such as plates, cases, pcb) can be contributed to the [qmk.fm repo](https://github.com/qmk/qmk.fm) and they will be made available on [qmk.fm](http://qmk.fm). Downloadable files are stored in `/<keyboard>/` (name follows the same format as above) which are served at `http://qmk.fm/<keyboard>/`, and pages are generated from `/_pages/<keyboard>/` which are served at the same location (.md files are generated into .html files through Jekyll). Check out the `lets_split` folder for an example.
## Keyboard Defaults
Given the amount of functionality that QMK exposes it's very easy to confuse new users. When putting together the default firmware for your keyboard we recommend limiting your enabled features and options to the minimal set needed to support your hardware. Recommendations for specific features follow.
### Bootmagic and Command
[Bootmagic](feature_bootmagic.md) and [Command](feature_command.md) are two related features that allow a user to control their keyboard in non-obvious ways. We recommend you think long and hard about if you're going to enable either feature, and how you will expose this functionality. Keep in mind that users who want this functionality can enable it in their personal keymaps without affecting all the novice users who may be using your keyboard as their first programmable board.
By far the most common problem new users encounter is accidentally triggering Bootmagic while they're plugging in their keyboard. They're holding the keyboard by the bottom, unknowingly pressing in alt and spacebar, and then they find that these keys have been swapped on them. We recommend leaving this feature disabled by default, but if you do turn it on consider setting `BOOTMAGIC_KEY_SALT` to a key that is hard to press while plugging your keyboard in.
If your keyboard does not have 2 shift keys you should provide a working default for `IS_COMMAND`, even when you have set `COMMAND_ENABLE = no`. This will give your users a default to conform to if they do enable Command.
## Custom Keyboard Programming
As documented on [Customizing Functionality](custom_quantum_functions.md) you can define custom functions for your keyboard. Please keep in mind that your users may want to customize that behavior as well, and make it possible for them to do that. If you are providing a custom function, for example `process_record_kb()`, make sure that your function calls the `_user()` version of the call too. You should also take into account the return value of the `_user()` version, and only run your custom code if the user returns `true`.
## Non-Production/Handwired Projects
We're happy to accept any project that uses QMK, including prototypes and handwired ones, but we have a separate `/keyboards/handwired/` folder for them, so the main `/keyboards/` folder doesn't get overcrowded. If a prototype project becomes a production project at some point in the future, we'd be happy to move it to the main `/keyboards/` folder!
## Warnings as Errors
When developing your keyboard, keep in mind that all warnings will be treated as errors - these small warnings can build-up and cause larger errors down the road (and keeping them is generally a bad practice).
## Copyright Blurb
If you're adapting your keyboard's setup from another project, but not using the same code, but sure to update the copyright header at the top of the files to show your name, in this format:
Copyright 2017 Your Name <your@email.com>
If you are modifying someone else's code and have made only trivial changes you should leave their name in the copyright statement. If you have done significant work on the file you should add your name to theirs, like so:
Copyright 2017 Their Name <original_author@example.com> Your Name <you@example.com>
The year should be the first year the file is created. If work was done to that file in later years you can reflect that by appending the second year to the first, like so:
Copyright 2015-2017 Your Name <you@example.com>
## License
The core of QMK is licensed under the [GNU General Public License](https://www.gnu.org/licenses/licenses.en.html). If you are shipping binaries for AVR processors you may choose either [GPLv2](https://www.gnu.org/licenses/old-licenses/gpl-2.0.html) or [GPLv3](https://www.gnu.org/licenses/gpl.html). If you are shipping binaries for ARM processors you must choose [GPL Version 3](https://www.gnu.org/licenses/gpl.html) to comply with the [ChibiOS](http://www.chibios.org) GPLv3 license.
If your keyboard makes use of the [uGFX](https://ugfx.io) features within QMK you must comply with the [uGFX License](https://ugfx.io/license.html), which requires a separate commercial license before selling a device containing uGFX.
## Technical Details
If you're looking for more information on making your keyboard work with QMK, [check out the hardware section](hardware.md)!
|