Compare commits

..

1 Commits

Author SHA1 Message Date
Jack Humbert 9e64d5f6c2 add encoder matrix functionality 2019-10-30 13:39:18 -04:00
2729 changed files with 35149 additions and 96300 deletions
+1 -7
View File
@@ -1,11 +1,5 @@
---
name: Blank issue
about: If you're 100% sure that you don't need one of the other issue templates, use
this one instead.
title: ''
labels: help wanted, question
assignees: ''
about: If you're 100% sure that you don't need one of the other issue templates, use this one instead.
---
+1 -6
View File
@@ -1,12 +1,7 @@
---
name: Bug report
about: Create a report to help us improve QMK Firmware.
title: "[Bug] "
labels: bug, help wanted
assignees: ''
about: Create a report to help us improve the QMK Firmware
---
<!-- Provide a general summary of the bug in the title above. -->
<!--- This template is entirely optional and can be removed, but is here to help both you and us. -->
-8
View File
@@ -1,8 +0,0 @@
blank_issues_enabled: false
contact_links:
- name: QMK Discord
url: https://discord.gg/Uq7gcHh
about: Ask questions, discuss issues and features. Chill.
- name: OLKB Subreddit
url: https://www.reddit.com/r/olkb
about: All things OLKB and QMK.
+1 -6
View File
@@ -1,12 +1,7 @@
---
name: Feature request
about: Suggest a new feature or changes to existing features.
title: "[Feature Request] "
labels: enhancement, help wanted
assignees: ''
about: Suggest a new feature or changes to existing features
---
<!--- Provide a general summary of the changes you want in the title above. -->
<!--- This template is entirely optional and can be removed, but is here to help both you and us. -->
+1 -6
View File
@@ -1,12 +1,7 @@
---
name: Other issues
about: Anything else that doesn't fall into the above categories.
title: ''
labels: help wanted, question
assignees: ''
about: Anything else that doesn't fall into the above categories.
---
<!--- Provide a general summary of the changes you want in the title above. -->
<!--- Anything on lines wrapped in comments like these will not show up in the final text. -->
-58
View File
@@ -1,58 +0,0 @@
# Configuration for probot-stale - https://github.com/probot/stale
# General configuration
# Pull request specific configuration
pulls:
staleLabel: awaiting changes
# Number of days of inactivity before an Issue or Pull Request becomes stale
daysUntilStale: 45
# Number of days of inactivity before a stale Issue or Pull Request is closed.
# Set to false to disable. If disabled, issues still need to be closed manually, but will remain marked as stale.
daysUntilClose: 30
# Comment to post when marking as stale. Set to `false` to disable
markComment: >
Thank you for your contribution!
This pull request has been automatically marked as stale because it has not had
activity in the last 45 days. It will be closed in 30 days if no further activity occurs.
Please feel free to give a status update now, or re-open when it's ready.
For maintainers: Please label with `awaiting review`, `breaking_change`, `in progress`, or `on hold` to prevent
the issue from being re-flagged.
# Comment to post when closing a stale Issue or Pull Request.
closeComment: >
Thank you for your contribution!
This pull request has been automatically closed because it has not had activity in the last 30 days.
Please feel free to give a status update now, ping for review, or re-open when it's ready.
# Limit the number of actions per hour, from 1-30. Default is 30
limitPerRun: 30
exemptLabels:
- awaiting review
- breaking_change
- in progress
- on hold
# Issue specific configuration
issues:
staleLabel: stale
limitPerRun: 10
daysUntilStale: 90
daysUntilClose: 30
markComment: >
This issue has been automatically marked as stale because it has not had activity in the
last 90 days. It will be closed in the next 30 days unless it is tagged properly or other activity
occurs.
For maintainers: Please label with `bug`, `in progress`, `on hold`, `discussion` or `to do` to prevent
the issue from being re-flagged.
closeComment: >
This issue has been automatically closed because it has not had activity in the last 30 days.
If this issue is still valid, re-open the issue and let us know.
exemptLabels:
- bug
- in progress
- on hold
- discussion
- to do
-1
View File
@@ -16,7 +16,6 @@ install:
- npm install -g moxygen
script:
- git rev-parse --short HEAD
- git diff --name-only HEAD $TRAVIS_BRANCH
- bash util/travis_test.sh
- bash util/travis_build.sh
- bash util/travis_docs.sh
+4 -9
View File
@@ -272,14 +272,12 @@ define PARSE_RULE
# If the rule starts with all, then continue the parsing from
# PARSE_ALL_KEYBOARDS
ifeq ($$(call COMPARE_AND_REMOVE_FROM_RULE,all),true)
KEYBOARD_RULE=all
$$(eval $$(call PARSE_ALL_KEYBOARDS))
else ifeq ($$(call COMPARE_AND_REMOVE_FROM_RULE,test),true)
$$(eval $$(call PARSE_TEST))
# If the rule starts with the name of a known keyboard, then continue
# the parsing from PARSE_KEYBOARD
else ifeq ($$(call TRY_TO_MATCH_RULE_FROM_LIST,$$(KEYBOARDS)),true)
KEYBOARD_RULE=$$(MATCHED_ITEM)
$$(eval $$(call PARSE_KEYBOARD,$$(MATCHED_ITEM)))
# Otherwise use the KEYBOARD variable, which is determined either by
# the current directory you run make from, or passed in as an argument
@@ -382,9 +380,6 @@ define PARSE_KEYBOARD
# Otherwise try to match the keymap from the current folder, or arguments to the make command
else ifneq ($$(KEYMAP),)
$$(eval $$(call PARSE_KEYMAP,$$(KEYMAP)))
# Otherwise if we are running make all:<user> just skip
else ifeq ($$(KEYBOARD_RULE),all)
# $$(info Skipping: No user keymap for $$(CURRENT_KB))
# Otherwise, make all keymaps, again this is consistent with how it works without
# any arguments
else
@@ -563,10 +558,10 @@ endef
if ! python3 --version 1> /dev/null 2>&1; then printf "$(MSG_PYTHON_MISSING)"; fi
# Check if the submodules are dirty, and display a warning if they are
ifndef SKIP_GIT
if [ ! -e lib/chibios ]; then git submodule sync lib/chibios && git submodule update --depth 50 --init lib/chibios; fi
if [ ! -e lib/chibios-contrib ]; then git submodule sync lib/chibios-contrib && git submodule update --depth 50 --init lib/chibios-contrib; fi
if [ ! -e lib/ugfx ]; then git submodule sync lib/ugfx && git submodule update --depth 50 --init lib/ugfx; fi
if [ ! -e lib/lufa ]; then git submodule sync lib/lufa && git submodule update --depth 50 --init lib/lufa; fi
if [ ! -e lib/chibios ]; then git submodule sync lib/chibios && git submodule update --depth 1 --init lib/chibios; fi
if [ ! -e lib/chibios-contrib ]; then git submodule sync lib/chibios-contrib && git submodule update --depth 1 --init lib/chibios-contrib; fi
if [ ! -e lib/ugfx ]; then git submodule sync lib/ugfx && git submodule update --depth 1 --init lib/ugfx; fi
if [ ! -e lib/lufa ]; then git submodule sync lib/lufa && git submodule update --depth 1 --init lib/lufa; fi
git submodule status --recursive 2>/dev/null | \
while IFS= read -r x; do \
case "$$x" in \
+3 -8
View File
@@ -25,13 +25,8 @@ with open(os.path.join(qmk_dir, 'requirements.txt'), 'r') as fd:
line = line.split('#')[0]
module = line.split('=')[0] if '=' in line else line
if module in ['pep8-naming']:
# Not every module is importable by its own name.
continue
if not find_spec(module):
print('Could not find module %s!' % module)
print('Could not find module %s!', module)
print('Please run `pip3 install -r requirements.txt` to install the python dependencies.')
exit(255)
@@ -46,7 +41,7 @@ else:
os.environ['QMK_VERSION'] = 'nogit-' + strftime('%Y-%m-%d-%H:%M:%S') + '-dirty'
# Setup the CLI
import milc # noqa
import milc
milc.EMOJI_LOGLEVELS['INFO'] = '{fg_blue}Ψ{style_reset_all}'
@@ -66,7 +61,7 @@ def main():
os.chdir(qmk_dir)
# Import the subcommands
import qmk.cli # noqa
import qmk.cli
# Execute
return_code = milc.cli()
-7
View File
@@ -82,13 +82,6 @@ ifeq ($(strip $(BOOTLOADER)), USBasp)
OPT_DEFS += -DBOOTLOADER_USBASP
BOOTLOADER_SIZE = 4096
endif
ifeq ($(strip $(BOOTLOADER)), lufa-ms)
# DO NOT USE THIS BOOTLOADER IN NEW PROJECTS!
# It is extremely prone to bricking, and is only included to support existing boards.
OPT_DEFS += -DBOOTLOADER_MS
BOOTLOADER_SIZE = 6144
FIRMWARE_FORMAT = bin
endif
ifdef BOOTLOADER_SIZE
OPT_DEFS += -DBOOTLOADER_SIZE=$(strip $(BOOTLOADER_SIZE))
+3 -2
View File
@@ -22,5 +22,6 @@ else ifneq ("$(wildcard $(MAIN_KEYMAP_PATH_1)/keymap.json)","")
endif
# Generate the keymap.c
$(KEYBOARD_OUTPUT)/src/keymap.c: $(KEYMAP_JSON)
bin/qmk json-keymap --quiet --output $(KEYMAP_C) $(KEYMAP_JSON)
ifneq ("$(KEYMAP_JSON)","")
_ = $(shell test -e $(KEYMAP_C) || bin/qmk json-keymap $(KEYMAP_JSON) -o $(KEYMAP_C))
endif
+31 -75
View File
@@ -61,7 +61,7 @@ endif
ifeq ($(strip $(STENO_ENABLE)), yes)
OPT_DEFS += -DSTENO_ENABLE
VIRTSER_ENABLE ?= yes
VIRTSER_ENABLE := yes
SRC += $(QUANTUM_DIR)/process_keycode/process_steno.c
endif
@@ -82,19 +82,19 @@ endif
ifeq ($(strip $(UCIS_ENABLE)), yes)
OPT_DEFS += -DUCIS_ENABLE
UNICODE_COMMON := yes
UNICODE_COMMON = yes
SRC += $(QUANTUM_DIR)/process_keycode/process_ucis.c
endif
ifeq ($(strip $(UNICODEMAP_ENABLE)), yes)
OPT_DEFS += -DUNICODEMAP_ENABLE
UNICODE_COMMON := yes
UNICODE_COMMON = yes
SRC += $(QUANTUM_DIR)/process_keycode/process_unicodemap.c
endif
ifeq ($(strip $(UNICODE_ENABLE)), yes)
OPT_DEFS += -DUNICODE_ENABLE
UNICODE_COMMON := yes
UNICODE_COMMON = yes
SRC += $(QUANTUM_DIR)/process_keycode/process_unicode.c
endif
@@ -107,13 +107,12 @@ ifeq ($(strip $(RGBLIGHT_ENABLE)), yes)
OPT_DEFS += -DRGBLIGHT_ENABLE
SRC += $(QUANTUM_DIR)/color.c
SRC += $(QUANTUM_DIR)/rgblight.c
CIE1931_CURVE := yes
LED_BREATHING_TABLE := yes
RGB_KEYCODES_ENABLE := yes
CIE1931_CURVE = yes
LED_BREATHING_TABLE = yes
ifeq ($(strip $(RGBLIGHT_CUSTOM_DRIVER)), yes)
OPT_DEFS += -DRGBLIGHT_CUSTOM_DRIVER
else
WS2812_DRIVER_REQUIRED := yes
WS2812_DRIVER_REQUIRED = yes
endif
endif
@@ -147,12 +146,11 @@ endif
SRC += $(QUANTUM_DIR)/color.c
SRC += $(QUANTUM_DIR)/rgb_matrix.c
SRC += $(QUANTUM_DIR)/rgb_matrix_drivers.c
CIE1931_CURVE := yes
RGB_KEYCODES_ENABLE := yes
CIE1931_CURVE = yes
endif
ifeq ($(strip $(RGB_MATRIX_ENABLE)), yes)
RGB_MATRIX_ENABLE := IS31FL3731
RGB_MATRIX_ENABLE = IS31FL3731
endif
ifeq ($(strip $(RGB_MATRIX_ENABLE)), IS31FL3731)
@@ -178,7 +176,7 @@ endif
ifeq ($(strip $(RGB_MATRIX_ENABLE)), WS2812)
OPT_DEFS += -DWS2812
WS2812_DRIVER_REQUIRED := yes
WS2812_DRIVER_REQUIRED = yes
endif
ifeq ($(strip $(RGB_MATRIX_CUSTOM_KB)), yes)
@@ -189,10 +187,6 @@ ifeq ($(strip $(RGB_MATRIX_CUSTOM_USER)), yes)
OPT_DEFS += -DRGB_MATRIX_CUSTOM_USER
endif
ifeq ($(strip $(RGB_KEYCODES_ENABLE)), yes)
SRC += $(QUANTUM_DIR)/process_keycode/process_rgb.c
endif
ifeq ($(strip $(TAP_DANCE_ENABLE)), yes)
OPT_DEFS += -DTAP_DANCE_ENABLE
SRC += $(QUANTUM_DIR)/process_keycode/process_tap_dance.c
@@ -232,41 +226,39 @@ endif
endif
ifeq ($(strip $(LCD_ENABLE)), yes)
CIE1931_CURVE := yes
CIE1931_CURVE = yes
endif
# backward compat
ifeq ($(strip $(BACKLIGHT_CUSTOM_DRIVER)), yes)
BACKLIGHT_DRIVER := custom
BACKLIGHT_ENABLE = custom
endif
VALID_BACKLIGHT_TYPES := pwm software custom
VALID_BACKLIGHT_TYPES := yes custom
BACKLIGHT_ENABLE ?= no
BACKLIGHT_DRIVER ?= pwm
ifeq ($(strip $(BACKLIGHT_ENABLE)), yes)
ifeq ($(filter $(BACKLIGHT_DRIVER),$(VALID_BACKLIGHT_TYPES)),)
$(error BACKLIGHT_DRIVER="$(BACKLIGHT_DRIVER)" is not a valid backlight type)
ifneq ($(strip $(BACKLIGHT_ENABLE)), no)
ifeq ($(filter $(BACKLIGHT_ENABLE),$(VALID_BACKLIGHT_TYPES)),)
$(error BACKLIGHT_ENABLE="$(BACKLIGHT_ENABLE)" is not a valid backlight type)
endif
ifeq ($(strip $(VISUALIZER_ENABLE)), yes)
CIE1931_CURVE := yes
CIE1931_CURVE = yes
endif
COMMON_VPATH += $(QUANTUM_DIR)/backlight
SRC += $(QUANTUM_DIR)/backlight/backlight.c
OPT_DEFS += -DBACKLIGHT_ENABLE
ifeq ($(strip $(BACKLIGHT_DRIVER)), custom)
ifeq ($(strip $(BACKLIGHT_ENABLE)), custom)
OPT_DEFS += -DBACKLIGHT_CUSTOM_DRIVER
else ifeq ($(strip $(BACKLIGHT_DRIVER)), software)
SRC += $(QUANTUM_DIR)/backlight/backlight_soft.c
endif
ifeq ($(PLATFORM),AVR)
SRC += $(QUANTUM_DIR)/backlight/backlight_avr.c
else
ifeq ($(PLATFORM),AVR)
SRC += $(QUANTUM_DIR)/backlight/backlight_avr.c
else
SRC += $(QUANTUM_DIR)/backlight/backlight_arm.c
endif
SRC += $(QUANTUM_DIR)/backlight/backlight_arm.c
endif
endif
@@ -278,8 +270,6 @@ ifeq ($(strip $(WS2812_DRIVER_REQUIRED)), yes)
$(error WS2812_DRIVER="$(WS2812_DRIVER)" is not a valid WS2812 driver)
endif
OPT_DEFS += -DWS2812_DRIVER_$(strip $(shell echo $(WS2812_DRIVER) | tr '[:lower:]' '[:upper:]'))
ifeq ($(strip $(WS2812_DRIVER)), bitbang)
SRC += ws2812.c
else
@@ -294,12 +284,12 @@ endif
ifeq ($(strip $(CIE1931_CURVE)), yes)
OPT_DEFS += -DUSE_CIE1931_CURVE
LED_TABLES := yes
LED_TABLES = yes
endif
ifeq ($(strip $(LED_BREATHING_TABLE)), yes)
OPT_DEFS += -DUSE_LED_BREATHING_TABLE
LED_TABLES := yes
LED_TABLES = yes
endif
ifeq ($(strip $(LED_TABLES)), yes)
@@ -349,14 +339,6 @@ ifeq ($(strip $(VELOCIKEY_ENABLE)), yes)
SRC += $(QUANTUM_DIR)/velocikey.c
endif
ifeq ($(strip $(VIA_ENABLE)), yes)
DYNAMIC_KEYMAP_ENABLE := yes
RAW_ENABLE := yes
BOOTMAGIC_ENABLE := lite
SRC += $(QUANTUM_DIR)/via.c
OPT_DEFS += -DVIA_ENABLE
endif
ifeq ($(strip $(DYNAMIC_KEYMAP_ENABLE)), yes)
OPT_DEFS += -DDYNAMIC_KEYMAP_ENABLE
SRC += $(QUANTUM_DIR)/dynamic_keymap.c
@@ -374,28 +356,12 @@ QUANTUM_SRC:= \
$(QUANTUM_DIR)/keymap_common.c \
$(QUANTUM_DIR)/keycode_config.c
VALID_CUSTOM_MATRIX_TYPES:= yes lite no
CUSTOM_MATRIX ?= no
# Include the standard or split matrix code if needed
ifneq ($(strip $(CUSTOM_MATRIX)), yes)
ifeq ($(filter $(CUSTOM_MATRIX),$(VALID_CUSTOM_MATRIX_TYPES)),)
$(error CUSTOM_MATRIX="$(CUSTOM_MATRIX)" is not a valid custom matrix type)
endif
# Include common stuff for all non custom matrix users
QUANTUM_SRC += $(QUANTUM_DIR)/matrix_common.c
# if 'lite' then skip the actual matrix implementation
ifneq ($(strip $(CUSTOM_MATRIX)), lite)
# Include the standard or split matrix code if needed
ifeq ($(strip $(SPLIT_KEYBOARD)), yes)
QUANTUM_SRC += $(QUANTUM_DIR)/split_common/matrix.c
else
QUANTUM_SRC += $(QUANTUM_DIR)/matrix.c
endif
ifeq ($(strip $(SPLIT_KEYBOARD)), yes)
QUANTUM_SRC += $(QUANTUM_DIR)/split_common/matrix.c
else
QUANTUM_SRC += $(QUANTUM_DIR)/matrix.c
endif
endif
@@ -438,16 +404,6 @@ ifeq ($(strip $(SPACE_CADET_ENABLE)), yes)
OPT_DEFS += -DSPACE_CADET_ENABLE
endif
MAGIC_ENABLE ?= yes
ifeq ($(strip $(MAGIC_ENABLE)), yes)
SRC += $(QUANTUM_DIR)/process_keycode/process_magic.c
OPT_DEFS += -DMAGIC_KEYCODE_ENABLE
endif
ifeq ($(strip $(DYNAMIC_MACRO_ENABLE)), yes)
SRC += $(QUANTUM_DIR)/process_keycode/process_dynamic_macro.c
OPT_DEFS += -DDYNAMIC_MACRO_ENABLE
endif
ifeq ($(strip $(DIP_SWITCH_ENABLE)), yes)
SRC += $(QUANTUM_DIR)/dip_switch.c
+1 -1
View File
@@ -15,7 +15,7 @@ QMK (*Quantum Mechanical Keyboard*) is an open source community that maintains Q
If you plan on contributing a keymap, keyboard, or features to QMK, the easiest thing to do is [fork the repo through Github](https://github.com/qmk/qmk_firmware#fork-destination-box), and clone your repo locally to make your changes, push them, then open a [Pull Request](https://github.com/qmk/qmk_firmware/pulls) from your fork.
Otherwise, you can clone it directly with `git clone https://github.com/qmk/qmk_firmware`. Do not download the zip or tar files; a git repository is required to download the submodules in order to compile.
Otherwise, you can either download it directly ([zip](https://github.com/qmk/qmk_firmware/zipball/master), [tar](https://github.com/qmk/qmk_firmware/tarball/master)), or clone it via git (`git@github.com:qmk/qmk_firmware.git`), or https (`https://github.com/qmk/qmk_firmware.git`).
## How to Compile
-4
View File
@@ -1,9 +1,5 @@
- Translations
- [:uk: English](/)
- [:cn: 中文](/zh-cn/)
- [:es: Español](/es/)
- [:fr: Français](/fr-fr/)
- [:he: עברית](/he-il/)
- [:brazil: Português](/pt-br/)
- [:ru: Русский](/ru-ru/)
- [:jp: 日本語](/ja/)
+2 -8
View File
@@ -3,10 +3,7 @@
* [Building Your First Firmware](newbs_building_firmware.md)
* [Flashing Firmware](newbs_flashing.md)
* [Testing and Debugging](newbs_testing_debugging.md)
* [Best Git Practices](newbs_git_best_practices.md)
* [Using Your Fork's Master](newbs_git_using_your_master_branch.md)
* [Resolving Merge Conflicts](newbs_git_resolving_merge_conflicts.md)
* [Resynchronizing a Branch](newbs_git_resynchronize_a_branch.md)
* [Git Best Practices](newbs_best_practices.md)
* [Learning Resources](newbs_learn_more_resources.md)
* [QMK Basics](README.md)
@@ -36,7 +33,6 @@
* [Keymap Overview](keymap.md)
* [Hardware](hardware.md)
* [Compatible Microcontrollers](compatible_microcontrollers.md)
* [AVR Processors](hardware_avr.md)
* [Drivers](hardware_drivers.md)
@@ -101,11 +97,9 @@
* [Hand Wiring Guide](hand_wire.md)
* [ISP Flashing Guide](isp_flashing_guide.md)
* [ARM Debugging Guide](arm_debugging.md)
* [ADC Driver](adc_driver.md)
* [I2C Driver](i2c_driver.md)
* [WS2812 Driver](ws2812_driver.md)
* [GPIO Controls](internals_gpio_control.md)
* [Custom Matrix](custom_matrix.md)
* [Proton C Conversion](proton_c_conversion.md)
* For a Deeper Understanding
@@ -116,7 +110,7 @@
* [Using Eclipse with QMK](other_eclipse.md)
* [Using VSCode with QMK](other_vscode.md)
* [Support](support.md)
* [Translating the QMK Docs](translating.md)
* [How to add translations](translating.md)
* QMK Internals (In Progress)
* [Defines](internals_defines.md)
-50
View File
@@ -1,50 +0,0 @@
# ADC Driver
QMK can leverage the Analog-to-Digital Converter (ADC) on supported MCUs to measure voltages on certain pins. This can be useful for implementing things such as battery level indicators for Bluetooth keyboards, or volume controls using a potentiometer, as opposed to a [rotary encoder](feature_encoders.md).
This driver is currently AVR-only. The values returned are 10-bit integers (0-1023) mapped between 0V and VCC (usually 5V or 3.3V).
## Usage
To use this driver, add the following to your `rules.mk`:
```make
SRC += analog.c
```
Then place this include at the top of your code:
```c
#include "analog.h"
```
## Channels
|Channel|AT90USB64/128|ATmega16/32U4|ATmega32A|ATmega328P|
|-------|-------------|-------------|---------|----------|
|0 |`F0` |`F0` |`A0` |`C0` |
|1 |`F1` |`F1` |`A1` |`C1` |
|2 |`F2` | |`A2` |`C2` |
|3 |`F3` | |`A3` |`C3` |
|4 |`F4` |`F4` |`A4` |`C4` |
|5 |`F5` |`F5` |`A5` |`C5` |
|6 |`F6` |`F6` |`A6` |* |
|7 |`F7` |`F7` |`A7` |* |
|8 | |`D4` | | |
|9 | |`D6` | | |
|10 | |`D7` | | |
|11 | |`B4` | | |
|12 | |`B5` | | |
|13 | |`B6` | | |
<sup>\* The ATmega328P possesses two extra ADC channels; however, they are not present on the DIP pinout, and are not shared with GPIO pins. You can use `adc_read()` directly to gain access to these.</sup>
## Functions
|Function |Description |
|----------------------------|-------------------------------------------------------------------------------------------------------------------|
|`analogReference(mode)` |Sets the analog voltage reference source. Must be one of `ADC_REF_EXTERNAL`, `ADC_REF_POWER` or `ADC_REF_INTERNAL`.|
|`analogRead(pin)` |Reads the value from the specified Arduino pin, eg. `4` for ADC6 on the ATmega32U4. |
|`analogReadPin(pin)` |Reads the value from the specified QMK pin, eg. `F6` for ADC6 on the ATmega32U4. |
|`pinToMux(pin)` |Translates a given QMK pin to a mux value. If an unsupported pin is given, returns the mux value for "0V (GND)". |
|`adc_read(mux)` |Reads the value from the ADC according to the specified mux. See your MCU's datasheet for more information. |
+11 -11
View File
@@ -1,4 +1,4 @@
# ARM Debugging using Eclipse
# ARM Debugging usign Eclipse
This page describes how to setup debugging for ARM MCUs using an SWD adapter and open-source/free tools. In this guide we will install GNU MCU Eclipse IDE for C/C++ Developers and OpenOCD together with all the necessary dependencies.
@@ -18,7 +18,7 @@ XPM installation instructions can be found [here](https://www.npmjs.com/package/
### The ARM Toolchain
Using XPM it is very easy to install the ARM toolchain. Enter the command `xpm install --global @xpack-dev-tools/arm-none-eabi-gcc`.
Using XPM it is very easy to install the ARM toolchain. Enter the command `xpm install --global @gnu-mcu-eclipse/arm-none-eabi-gcc`.
### Windows build tools
@@ -33,7 +33,7 @@ If you have an ST-Link the drivers can be found [here](https://www.st.com/en/dev
### OpenOCD
This dependency allows SWD access from GDB and it is essential for debugging. Run `xpm install --global @xpack-dev-tools/openocd`.
This dependency allows SWD access from GDB and it is essential for debugging. Run `xpm install --global @gnu-mcu-eclipse/openocd`.
### Java
@@ -45,17 +45,17 @@ Now its finally time to install the IDE. Use the Release page [here](https://git
## Configuring Eclipse
Open up the Eclipse IDE we just downloaded. To import our QMK directory select File -> Import -> C/C++ -> Existing Code as Makefile Project. Select Next and use Browse to select your QMK folder. In the tool-chain list select ARM Cross GCC and select Finish.
Open up the Eclipse IDE we just downloaded. To import our QMK directory select File -> Import -> C/C++ -> Existing code as Makefile Project. Select next and use Browse to select your QMK folder. In the tool-chain list select ARM Cross GCC and select Finish.
Now you can see the QMK folder on the left hand side. Right click it and select Properties. On the left hand side, expand MCU and select ARM Toolchains Paths. Press xPack and OK. Repeat for OpenOCD Path and if you are on Windows for Build Tools Path. Select Apply and Close.
Now you can see the QMK folder on the left hand side. Right click it and select Properties. On the left hand side, expand MCU and select ARM Toolchain Paths. Press xPack and OK. Repeat for OpenOCD Path and if you are on windows for Build Tool Path. Select Apply and Close.
Now its time to install the necessary MCU packages. Go to Packs perspective by selecting Window -> Perspective -> Open Perspective -> Other... -> Packs. Now select the yellow refresh symbol next to the Packs tab. This will take a long time as it is requesting the MCU definitions from various places. If some of the links fail you can probably select Ignore.
Now its time to install the necessary MCU packages. Go to Packs perspective by selecting Window -> Open Perspective -> Others -> Packs. Now select the yellow refresh symbol next to the Packs tab. This will take a long time as it is requesting the MCU definitions from various places. If some of the links fail you can probably select Ignore.
When this finishes you must find the MCU which we will be building/debugging for. In this example I will be using the STM32F3 series MCUs. On the left, select STMicroelectronics -> STM32F3 Series. On the middle window we can see the pack. Right click and select Install. Once that is done we can go back to the default perspective, Window -> Perspective -> Open Perspective -> Other... -> C/C++.
When this finishes you must find the MCU which we will be building/debugging for. In this example I will be using the STM32F3 series MCUs. On the left, select STMicroelectonics -> STM32F3 Series. On the middle window we can see the pack. Right click and select Install. Once that is done we can go back to the default perspective, Window -> Open Perspective -> Others -> C/C++.
We need to let eclipse know the device we intent to build QMK on. Right click on the QMK folder -> Properties -> C/C++ Build -> Settings. Select the Devices tab and under Devices select the appropriate variant of your MCU. For my example it is STM32F303CC
We need to let eclipse know the device we intent to build QMK on. Right click on the QMK folder -> Properties -> C/C++ Build -> Settings. Select the Devices tab and under devices select the appropriate variant of your MCU. For my example it is STM32F303CC
While we are here let's setup the build command as well. Select C/C++ Build and then the Behavior tab. On the Build command, replace `all` with your necessary make command. For example for a rev6 Planck with the default keymap this would be `planck/rev6:default`. Select Apply and Close.
While we are here let's setup the build command as well. Select C/C++ Build and then the Behavior tab. On the build command, replace `all` with your necessary make command. For example for a rev6 Planck with the default keymap this would be `planck/rev6:default`. Select Apply and Close.
## Building
@@ -71,7 +71,7 @@ NOTE: Make sure the SWCLK and SWDIO pins are not used in the matrix of your keyb
### Configuring the Debugger
Right click on your QMK folder, select Debug As -> Debug Configurations... . Here double click on GDB OpenOCD Debugging. Select the Debugger tab and enter the configuration necessary for your MCU. This might take some fiddling and Googling to find out. The default script for the STM32F3 is called `stm32f3discovery.cfg`. To let OpenOCD know, in the Config options enter `-f board/stm32f3discovery.cfg`.
Right click on your QMK folder, select Debug As -> Debug Configuration. Here double click on GDB OpenOCD Debugging. Select the debugger tab and enter the configuration necessary for your MCU. This might take some fiddling and googleing to find out. The default script for the STM32F3 is called stm32f3discovery.cfg. To let OpenOCD know, in the Config options enter `-f board/stm32f3discovery.cfg`.
NOTE: In my case this configuration script requires editing to disable the reset assertion. The locations of the scripts can be found in the actual executable field usually under the path `openocd/version/.content/scripts/board`. Here I edited `reset_config srst_only` to `reset_config none`.
@@ -81,7 +81,7 @@ Select Apply and Close.
Reset your keyboard.
Press the bug icon and if all goes well you should soon find yourself in the Debug perspective. Here the program counter will pause at the beginning of the main function and wait for you to press Play. Most of the features of all debuggers work on Arm MCUs but for exact details Google is your friend!
Press the bug icon and if all goes well you should soon find yourself in the debug perspective. Here the program counter will pause at the beginning of the main function and way for you to press Play. Most of the features of all debuggers work on ARM MCUs but for exact details google is your friend!
Happy debugging!
+6 -6
View File
@@ -10,16 +10,16 @@ The breaking change period is when we will merge PR's that change QMK in dangero
## When is the next Breaking Change?
The next Breaking Change is scheduled for February 29, 2020.
The next Breaking Change is scheduled for Nov 29.
### Important Dates
* [x] 2019 Sep 21 - `future` is created. It will be rebased weekly.
* [ ] 2020 Feb 1 - `future` closed to new PR's.
* [ ] 2020 Feb 1 - Call for testers.
* [ ] 2020 Feb 26 - `master` is locked, no PR's merged.
* [ ] 2020 Feb 28 - Merge `future` to `master`.
* [ ] 2020 Feb 29 - `master` is unlocked. PR's can be merged again.
* [ ] 2019 Nov 01 - `future` closed to new PR's.
* [ ] 2019 Nov 01 - Call for testers.
* [ ] 2019 Nov 27 - `master` is locked, no PR's merged.
* [ ] 2019 Nov 29 - Merge `future` to `master`.
* [ ] 2019 Nov 30 - `master` is unlocked. PR's can be merged again.
## What changes will be included?
-46
View File
@@ -95,30 +95,6 @@ qmk compile <configuratorExport.json>
qmk compile -kb <keyboard_name> -km <keymap_name>
```
## `qmk flash`
This command is similar to `qmk compile`, but can also target a bootloader. The bootloader is optional, and is set to `:flash` by default.
To specify a different bootloader, use `-bl <bootloader>`. Visit <https://docs.qmk.fm/#/flashing>
for more details of the available bootloaders.
**Usage for Configurator Exports**:
```
qmk flash <configuratorExport.json> -bl <bootloader>
```
**Usage for Keymaps**:
```
qmk flash -kb <keyboard_name> -km <keymap_name> -bl <bootloader>
```
**Listing the Bootloaders**
```
qmk flash -b
```
## `qmk config`
This command lets you configure the behavior of QMK. For the full `qmk config` documentation see [CLI Configuration](cli_configuration.md).
@@ -159,28 +135,6 @@ Creates a keymap.c from a QMK Configurator export.
qmk json-keymap [-o OUTPUT] filename
```
## `qmk kle2json`
This command allows you to convert from raw KLE data to QMK Configurator JSON. It accepts either an absolute file path, or a file name in the current directory. By default it will not overwrite `info.json` if it is already present. Use the `-f` or `--force` flag to overwrite.
**Usage**:
```
qmk kle2json [-f] <filename>
```
**Examples**:
```
$ qmk kle2json kle.txt
☒ File info.json already exists, use -f or --force to overwrite.
```
```
$ qmk kle2json -f kle.txt -f
Ψ Wrote out to info.json
```
## `qmk list-keyboards`
This command lists all the keyboards currently defined in `qmk_firmware`
-32
View File
@@ -173,35 +173,3 @@ You will only be able to access these arguments using `cli.args`. For example:
```
cli.log.info('Reading from %s and writing to %s', cli.args.filename, cli.args.output)
```
# Testing, and Linting, and Formatting (oh my!)
We use nose2, flake8, and yapf to test, lint, and format code. You can use the `pytest` and `pyformat` subcommands to run these tests:
### Testing and Linting
qmk pytest
### Formatting
qmk pyformat
## Formatting Details
We use [yapf](https://github.com/google/yapf) to automatically format code. Our configuration is in the `[yapf]` section of `setup.cfg`.
?> Tip- Many editors can use yapf as a plugin to automatically format code as you type.
## Testing Details
Our tests can be found in `lib/python/qmk/tests/`. You will find both unit and integration tests in this directory. We hope you will write both unit and integration tests for your code, but if you do not please favor integration tests.
If your PR does not include a comprehensive set of tests please add comments like this to your code so that other people know where they can help:
# TODO(unassigned/<yourGithubUsername>): Write <unit|integration> tests
We use [nose2](https://nose2.readthedocs.io/en/latest/getting_started.html) to run our tests. You can refer to the nose2 documentation for more details on what you can do in your test functions.
## Linting Details
We use flake8 to lint our code. Your code should pass flake8 before you open a PR. This will be checked when you run `qmk pytest` and by CI when you submit a PR.
+1 -1
View File
@@ -14,7 +14,7 @@ Most of our style is pretty easy to pick up on, but right now it's not entirely
* Think of them as a story describing the feature
* Use them liberally to explain why particular decisions were made.
* Do not write obvious comments
* If you're not sure if a comment is obvious, go ahead and include it.
* If you not sure if a comment is obvious, go ahead and include it.
* In general we don't wrap lines, they can be as long as needed. If you do choose to wrap lines please do not wrap any wider than 76 columns.
* We use `#pragma once` at the start of header files rather than old-style include guards (`#ifndef THIS_FILE_H`, `#define THIS_FILE_H`, ..., `#endif`)
* We accept both forms of preprocessor if's: `#ifdef DEFINED` and `#if defined(DEFINED)`
+6 -18
View File
@@ -8,7 +8,7 @@ Most of our style follows PEP8 with some local modifications to make things less
* Think of them as a story describing the feature
* Use them liberally to explain why particular decisions were made.
* Do not write obvious comments
* If you're not sure if a comment is obvious, go ahead and include it.
* If you not sure if a comment is obvious, go ahead and include it.
* We require useful docstrings for all functions.
* In general we don't wrap lines, they can be as long as needed. If you do choose to wrap lines please do not wrap any wider than 76 columns.
* Some of our practices conflict with the wider python community to make our codebase more approachable to non-pythonistas.
@@ -77,9 +77,9 @@ Always use a .py filename extension. Never use dashes.
## Names to Avoid
* single character names except for counters or iterators. You may use `e` as an exception identifier in try/except statements.
* dashes (`-`) in any package/module name
* `__double_leading_and_trailing_underscore__` names (reserved by Python)
* single character names except for counters or iterators. You may use "e" as an exception identifier in try/except statements.
* dashes (-) in any package/module name
* __double_leading_and_trailing_underscore__ names (reserved by Python)
# Docstrings
@@ -309,18 +309,6 @@ FIXME(username): Revisit this code when the frob feature is done.
...where username is your GitHub username.
# Testing
# Unit Tests
We use a combination of Integration and Unit testing to ensure that the our code is as bug-free as possible. All the tests can be found in `lib/python/qmk/tests/`. You can run all the tests with `qmk pytest`.
At the time of this writing our tests are not very comprehensive. Looking at the current tests and writing new test cases for untested situations is a great way to both familiarize yourself with the codebase and contribute to QMK.
## Integration Tests
Integration tests can be found in `lib/python/qmk/tests/test_cli_commands.py`. This is where CLI commands are actually run and their overall behavior is verified. We use [`subprocess`](https://docs.python.org/3.5/library/subprocess.html#module-subprocess) to launch each CLI command and a combination of checking output and returncode to determine if the right thing happened.
## Unit Tests
The other `test_*.py` files in `lib/python/qmk/tests/` contain unit tests. You can write tests for individual functions inside `lib/python/qmk/` here. Generally these files are named after the module, with dots replaced by underscores.
At the time of this writing we do not do any mocking for our tests. If you would like to help us change this please [open an issue](https://github.com/qmk/qmk_firmware/issues/new?assignees=&labels=cli%2C+python&template=other_issues.md&title=) or [join #cli on Discord](https://discord.gg/heQPAgy) and start a conversation there.
These are good. We should have some one day.
+18 -29
View File
@@ -1,36 +1,25 @@
# Compatible Microcontrollers
# Atmel AVR
QMK runs on any USB-capable AVR or ARM microcontroller with enough flash space - generally 32kB or more, though it will *just* squeeze into 16kB with most features disabled.
QMK should run on any Atmel AVR processor with enough Flash. It has been tested on the following:
## Atmel AVR
* ATmega32U4 ([PJRC Teensy 2.0](http://www.pjrc.com/teensy/))
* AT90USB1286 ([PJRC Teensy++ 2.0](http://www.pjrc.com/teensy/))
* AT90USB1287 ([Atmel USBKEY](http://www.atmel.com/tools/AT90USBKEY.aspx))
* ATmega168P with using [V-USB](http://www.obdev.at/products/vusb/index.html)
* ATmega328P with using [V-USB](http://www.obdev.at/products/vusb/index.html)
* ATmega32U2
* AT90USB1286, 646, 647 should work
* AT90USB162 testing...
The following use [LUFA](https://www.fourwalledcubicle.com/LUFA.php) as the USB stack:
NOTE: To enable full features of firmware you'll need 32KB flash size.
* [ATmega16U2](https://www.microchip.com/wwwproducts/en/ATmega16U2) / [ATmega32U2](https://www.microchip.com/wwwproducts/en/ATmega32U2)
* [ATmega16U4](https://www.microchip.com/wwwproducts/en/ATmega16U4) / [ATmega32U4](https://www.microchip.com/wwwproducts/en/ATmega32U4)
* [AT90USB64](https://www.microchip.com/wwwproducts/en/AT90USB646) / [AT90USB128](https://www.microchip.com/wwwproducts/en/AT90USB1286)
Please add any tested microcontrollers to this list.
Certain MCUs which do not have native USB will use [V-USB](https://www.obdev.at/products/vusb/index.html) instead:
# ARM
* [ATmega32A](https://www.microchip.com/wwwproducts/en/ATmega32A)
* [ATmega328P](https://www.microchip.com/wwwproducts/en/ATmega328P)
You can also use any ARM processor that [ChibiOS](http://www.chibios.org) supports. The following processors have been tested:
## ARM
You can also use any ARM chip with USB that [ChibiOS](http://www.chibios.org) supports. Most have plenty of flash. Known to work are:
### STMicroelectronics (STM32)
* [STM32F0x2](https://www.st.com/en/microcontrollers-microprocessors/stm32f0x2.html)
* [STM32F103](https://www.st.com/en/microcontrollers-microprocessors/stm32f103.html)
* [STM32F303](https://www.st.com/en/microcontrollers-microprocessors/stm32f303.html)
### NXP (Kinetis)
* [MKL26Z64](https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontrollers/general-purpose-mcus/kl-series-cortex-m0-plus/kinetis-kl2x-72-96-mhz-usb-ultra-low-power-microcontrollers-mcus-based-on-arm-cortex-m0-plus-core:KL2x)
* [MK20DX128](https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontrollers/general-purpose-mcus/k-series-cortex-m4/k2x-usb/kinetis-k20-50-mhz-full-speed-usb-mixed-signal-integration-microcontrollers-based-on-arm-cortex-m4-core:K20_50)
* [MK20DX256](https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontrollers/general-purpose-mcus/k-series-cortex-m4/k2x-usb/kinetis-k20-72-mhz-full-speed-usb-mixed-signal-integration-microcontrollers-mcus-based-on-arm-cortex-m4-core:K20_72)
## Atmel ATSAM
There is limited support for one of Atmel's ATSAM microcontrollers, that being the [ATSAMD51J18A](https://www.microchip.com/wwwproducts/en/ATSAMD51J18A) used by the [Massdrop keyboards](https://github.com/qmk/qmk_firmware/tree/master/keyboards/massdrop).
* [Kinetis MKL26Z64](http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/kinetis-cortex-m-mcus/l-series-ultra-low-power-m0-plus/kinetis-kl2x-48-mhz-usb-ultra-low-power-microcontrollers-mcus-based-on-arm-cortex-m0-plus-core:KL2x)
* [Kinetis MK20DX128](http://www.nxp.com/assets/documents/data/en/data-sheets/K20P64M50SF0.pdf)
* [Kinetis MK20DX128](http://www.nxp.com/assets/documents/data/en/data-sheets/K20P64M50SF0.pdf)
* [Kinetis MK20DX256](http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/kinetis-cortex-m-mcus/k-series-performance-m4/k2x-usb/kinetis-k20-72-mhz-full-speed-usb-mixed-signal-integration-microcontrollers-mcus-based-on-arm-cortex-m4-core:K20_72)
+4 -25
View File
@@ -143,14 +143,10 @@ If you define these options you will enable the associated feature, which may in
* `#define IGNORE_MOD_TAP_INTERRUPT`
* makes it possible to do rolling combos (zx) with keys that convert to other keys on hold, by enforcing the `TAPPING_TERM` for both keys.
* See [Mod tap interrupt](feature_advanced_keycodes.md#ignore-mod-tap-interrupt) for details
* `#define IGNORE_MOD_TAP_INTERRUPT_PER_KEY`
* enables handling for per key `IGNORE_MOD_TAP_INTERRUPT` settings
* `#define TAPPING_FORCE_HOLD`
* makes it possible to use a dual role key as modifier shortly after having been tapped
* See [Hold after tap](feature_advanced_keycodes.md#tapping-force-hold)
* Breaks any Tap Toggle functionality (`TT` or the One Shot Tap Toggle)
* `#define TAPPING_FORCE_HOLD_PER_KEY`
* enables handling for per key `TAPPING_FORCE_HOLD` settings
* `#define LEADER_TIMEOUT 300`
* how long before the leader key times out
* If you're having issues finishing the sequence before it times out, you may need to increase the timeout setting. Or you may want to enable the `LEADER_PER_KEY_TIMING` option, which resets the timeout after each key is tapped.
@@ -200,8 +196,8 @@ If you define these options you will enable the associated feature, which may in
* units to step when in/decreasing saturation
* `#define RGBLIGHT_VAL_STEP 12`
* units to step when in/decreasing value (brightness)
* `#define RGBW`
* Enables RGBW LED support
* `#define RGBW_BB_TWI`
* bit-bangs TWI to EZ RGBW LEDs (only required for Ergodox EZ)
## Mouse Key Options
@@ -291,27 +287,8 @@ This is a [make](https://www.gnu.org/software/make/manual/make.html) file that i
* Defines which format (bin, hex) is copied to the root `qmk_firmware` folder after building.
* `SRC`
* Used to add files to the compilation/linking list.
* `LIB_SRC`
* Used to add files as a library to the compilation/linking list.
The files specified by `LIB_SRC` is linked after the files specified by `SRC`.
For example, if you specify:
```
SRC += a.c
LIB_SRC += lib_b.c
SRC += c.c
LIB_SRC += lib_d.c
```
The link order is as follows.
```
... a.o c.o ... lib_b.a lib_d.a ...
```
* `LAYOUTS`
* A list of [layouts](feature_layouts.md) this keyboard supports.
* `LINK_TIME_OPTIMIZATION_ENABLE`
* Enables Link Time Optimization (`LTO`) when compiling the keyboard. This makes the process take longer, but can significantly reduce the compiled size (and since the firmware is small, the added time is not noticeable). However, this will automatically disable the old Macros and Functions features automatically, as these break when `LTO` is enabled.
It does this by automatically defining `NO_ACTION_MACRO` and `NO_ACTION_FUNCTION`
* `LTO_ENABLE`
* It has the same meaning as LINK_TIME_OPTIMIZATION_ENABLE. You can use `LTO_ENABLE` instead of `LINK_TIME_OPTIMIZATION_ENABLE`.
## AVR MCU Options
* `MCU = atmega32u4`
@@ -370,6 +347,8 @@ Use these to enable or disable building certain features. The more you have enab
* Forces the keyboard to wait for a USB connection to be established before it starts up
* `NO_USB_STARTUP_CHECK`
* Disables usb suspend check after keyboard startup. Usually the keyboard waits for the host to wake it up before any tasks are performed. This is useful for split keyboards as one half will not get a wakeup call but must send commands to the master.
* `LINK_TIME_OPTIMIZATION_ENABLE`
= Enables Link Time Optimization (`LTO`) when compiling the keyboard. This makes the process take longer, but can significantly reduce the compiled size (and since the firmware is small, the added time is not noticable). However, this will automatically disable the old Macros and Functions features automatically, as these break when `LTO` is enabled. It does this by automatically defining `NO_ACTION_MACRO` and `NO_ACTION_FUNCTION`
## USB Endpoint Limitations
+1 -13
View File
@@ -85,7 +85,7 @@ Limited experimentation on the devices I have available shows that 7 is high eno
Documentation is one of the easiest ways to get started contributing to QMK. Finding places where the documentation is wrong or incomplete and fixing those is easy! We also very badly need someone to edit our documentation, so if you have editing skills but aren't sure where or how to jump in please [reach out for help](#where-can-i-go-for-help)!
You'll find all our documentation in the `qmk_firmware/docs` directory, or if you'd rather use a web based workflow you can click the "Edit this page" link at the bottom of each page on https://docs.qmk.fm/.
You'll find all our documentation in the `qmk_firmware/docs` directory, or if you'd rather use a web based workflow you can click "Suggest An Edit" at the top of each page on http://docs.qmk.fm/.
When providing code examples in your documentation, try to observe naming conventions used elsewhere in the docs. For example, standardizing enums as `my_layers` or `my_keycodes` for consistency:
@@ -101,18 +101,6 @@ enum my_keycodes {
};
```
### Previewing the Documentation
Before opening a pull request, you can preview your changes if you have set up the development environment by running this command from the `qmk_firmware/` folder:
./bin/qmk docs
or if you only have Python 3 installed:
python3 -m http.server 8936
and navigating to `http://localhost:8936/`.
## Keymaps
Most first-time QMK contributors start with their personal keymaps. We try to keep keymap standards pretty casual (keymaps, after all, reflect the personality of their creators) but we do ask that you follow these guidelines to make it easier for others to discover and learn from your keymap.
-108
View File
@@ -1,108 +0,0 @@
# Custom Matrix
QMK provides a mechanism to supplement or replace the default matrix scanning routine with your own code.
The reasons to use this feature include:
* Extra hardware between the keyboard's switches and MCU pins
* I/O multiplexer
* Line decoder
* Irregular switch matrix
* Simultaneous use of `COL2ROW` and `ROW2COL`
## Prerequisites
Implementing custom matrix usually involves compilation of an additional source file. It is recommended that for consistency, this file is called `matrix.c`.
Add a new file to your keyboard directory:
```text
keyboards/<keyboard>/matrix.c
```
And to configure compilation for the new file, add this to your `rules.mk`:
```make
SRC += matrix.c
```
## 'lite'
Provides a default implementation for various scanning functions, reducing the boilerplate code when implementing custom matrix.
To configure it, add this to your `rules.mk`:
```make
CUSTOM_MATRIX = lite
```
And implement the following functions in a `matrix.c` file in your keyboard folder:
```c
void matrix_init_custom(void) {
// TODO: initialize hardware here
}
bool matrix_scan_custom(matrix_row_t current_matrix[]) {
bool matrix_has_changed = false;
// TODO: add matrix scanning routine here
return matrix_has_changed;
}
```
## Full Replacement
When more control over the scanning routine is required, you can choose to implement the full scanning routine.
To configure it, add this to your rules.mk:
```make
CUSTOM_MATRIX = yes
```
And implement the following functions in a `matrix.c` file in your keyboard folder:
```c
matrix_row_t matrix_get_row(uint8_t row) {
// TODO: return the requested row data
}
void matrix_print(void) {
// TODO: use print() to dump the current matrix state to console
}
void matrix_init(void) {
// TODO: initialize hardware and global matrix state here
// Unless hardware debouncing - Init the configured debounce routine
debounce_init(MATRIX_ROWS);
// This *must* be called for correct keyboard behavior
matrix_init_quantum();
}
uint8_t matrix_scan(void) {
bool matrix_has_changed = false;
// TODO: add matrix scanning routine here
// Unless hardware debouncing - use the configured debounce routine
debounce(raw_matrix, matrix, MATRIX_ROWS, changed);
// This *must* be called for correct keyboard behavior
matrix_scan_quantum();
return matrix_has_changed;
}
```
And also provide defaults for the following callbacks:
```c
__attribute__((weak)) void matrix_init_kb(void) { matrix_init_user(); }
__attribute__((weak)) void matrix_scan_kb(void) { matrix_scan_user(); }
__attribute__((weak)) void matrix_init_user(void) {}
__attribute__((weak)) void matrix_scan_user(void) {}
```
+57 -107
View File
@@ -90,93 +90,68 @@ keyrecord_t record {
# LED Control
QMK provides methods to read 5 of the LEDs defined in the HID spec:
QMK provides methods to read the 5 LEDs defined as part of the HID spec:
* Num Lock
* Caps Lock
* Scroll Lock
* Compose
* Kana
* `USB_LED_NUM_LOCK`
* `USB_LED_CAPS_LOCK`
* `USB_LED_SCROLL_LOCK`
* `USB_LED_COMPOSE`
* `USB_LED_KANA`
There are two ways to get the lock LED state:
These five constants correspond to the positional bits of the host LED state.
There are two ways to get the host LED state:
* by implementing `bool led_update_kb(led_t led_state)` or `_user(led_t led_state)`; or
* by calling `led_t host_keyboard_led_state()`
* by implementing `led_set_user()`
* by calling `host_keyboard_leds()`
!> `host_keyboard_led_state()` may already reflect a new value before `led_update_user()` is called.
## `led_set_user()`
Two more deprecated functions exist that provide the LED state as a `uint8_t`:
This function will be called when the state of one of those 5 LEDs changes. It receives the LED state as a parameter.
Use the `IS_LED_ON(usb_led, led_name)` and `IS_LED_OFF(usb_led, led_name)` macros to check the LED status.
* `uint8_t led_set_kb(uint8_t usb_led)` and `_user(uint8_t usb_led)`
* `uint8_t host_keyboard_leds()`
!> `host_keyboard_leds()` may already reflect a new value before `led_set_user()` is called.
## `led_update_user()`
This function will be called when the state of one of those 5 LEDs changes. It receives the LED state as a struct parameter.
By convention, return `true` from `led_update_user()` to get the `led_update_kb()` hook to run its code, and
return `false` when you would prefer not to run the code in `led_update_kb()`.
Some examples include:
- overriding the LEDs to use them for something else like layer indication
- return `false` because you do not want the `_kb()` function to run, as it would override your layer behavior.
- play a sound when an LED turns on or off.
- return `true` because you want the `_kb` function to run, and this is in addition to the default LED behavior.
?> Because the `led_set_*` functions return `void` instead of `bool`, they do not allow for overriding the keyboard LED control, and thus it's recommended to use `led_update_*` instead.
### Example `led_update_kb()` Implementation
### Example `led_set_user()` Implementation
```c
bool led_update_kb(led_t led_state) {
bool res = led_update_user(led_state);
if(res) {
// writePin sets the pin high for 1 and low for 0.
// In this example the pins are inverted, setting
// it low/0 turns it on, and high/1 turns the LED off.
// This behavior depends on whether the LED is between the pin
// and VCC or the pin and GND.
writePin(B0, !led_state.num_lock);
writePin(B1, !led_state.caps_lock);
writePin(B2, !led_state.scroll_lock);
writePin(B3, !led_state.compose);
writePin(B4, !led_state.kana);
void led_set_user(uint8_t usb_led) {
if (IS_LED_ON(usb_led, USB_LED_NUM_LOCK)) {
writePinLow(B0);
} else {
writePinHigh(B0);
}
if (IS_LED_ON(usb_led, USB_LED_CAPS_LOCK)) {
writePinLow(B1);
} else {
writePinHigh(B1);
}
if (IS_LED_ON(usb_led, USB_LED_SCROLL_LOCK)) {
writePinLow(B2);
} else {
writePinHigh(B2);
}
if (IS_LED_ON(usb_led, USB_LED_COMPOSE)) {
writePinLow(B3);
} else {
writePinHigh(B3);
}
if (IS_LED_ON(usb_led, USB_LED_KANA)) {
writePinLow(B4);
} else {
writePinHigh(B4);
}
return res;
}
```
### Example `led_update_user()` Implementation
### `led_set_*` Function Documentation
This incomplete example would play a sound if Caps Lock is turned on or off. It returns `true`, because you also want the LEDs to maintain their state.
* Keyboard/Revision: `void led_set_kb(uint8_t usb_led)`
* Keymap: `void led_set_user(uint8_t usb_led)`
```c
#ifdef AUDIO_ENABLE
float caps_on[][2] = SONG(CAPS_LOCK_ON_SOUND);
float caps_off[][2] = SONG(CAPS_LOCK_OFF_SOUND);
#endif
## `host_keyboard_leds()`
bool led_update_user(led_t led_state) {
#ifdef AUDIO_ENABLE
static uint8_t caps_state = 0;
if (caps_state != led_state.caps_lock) {
led_state.caps_lock ? PLAY_SONG(caps_on) : PLAY_SONG(caps_off);
caps_state = led_state.caps_lock;
}
#endif
return true;
}
```
### `led_update_*` Function Documentation
* Keyboard/Revision: `bool led_update_kb(led_t led_state)`
* Keymap: `bool led_update_user(led_t led_state)`
## `host_keyboard_led_state()`
Call this function to get the last received LED state as a `led_t`. This is useful for reading the LED state outside `led_update_*`, e.g. in [`matrix_scan_user()`](#matrix-scanning-code).
Call this function to get the last received LED state. This is useful for reading the LED state outside `led_set_*`, e.g. in [`matrix_scan_user()`](#matrix-scanning-code).
For convenience, you can use the `IS_HOST_LED_ON(led_name)` and `IS_HOST_LED_OFF(led_name)` macros instead of calling and checking `host_keyboard_leds()` directly.
## Setting Physical LED State
@@ -394,7 +369,7 @@ void keyboard_post_init_user(void) {
// Set default layer, if enabled
if (user_config.rgb_layer_change) {
rgblight_enable_noeeprom();
rgblight_sethsv_noeeprom_cyan();
rgblight_sethsv_noeeprom_cyan();
rgblight_mode_noeeprom(1);
}
}
@@ -442,18 +417,18 @@ bool process_record_user(uint16_t keycode, keyrecord_t *record) {
}
return true; // Let QMK send the enter press/release events
case RGB_LYR: // This allows me to use underglow as layer indication, or as normal
if (record->event.pressed) {
if (record->event.pressed) {
user_config.rgb_layer_change ^= 1; // Toggles the status
eeconfig_update_user(user_config.raw); // Writes the new status to EEPROM
if (user_config.rgb_layer_change) { // if layer state indication is enabled,
if (user_config.rgb_layer_change) { // if layer state indication is enabled,
layer_state_set(layer_state); // then immediately update the layer color
}
}
return false; break;
case RGB_MODE_FORWARD ... RGB_MODE_GRADIENT: // For any of the RGB codes (see quantum_keycodes.h, L400 for reference)
if (record->event.pressed) { //This disables layer indication, as it's assumed that if you're changing this ... you want that disabled
if (user_config.rgb_layer_change) { // only if this is enabled
user_config.rgb_layer_change = false; // disable it, and
if (user_config.rgb_layer_change) { // only if this is enabled
user_config.rgb_layer_change = false; // disable it, and
eeconfig_update_user(user_config.raw); // write the setings to EEPROM
}
}
@@ -466,7 +441,7 @@ bool process_record_user(uint16_t keycode, keyrecord_t *record) {
And lastly, you want to add the `eeconfig_init_user` function, so that when the EEPROM is reset, you can specify default values, and even custom actions. To force an EEPROM reset, use the `EEP_RST` keycode or [Bootmagic](feature_bootmagic.md) functionallity. For example, if you want to set rgb layer indication by default, and save the default valued.
```c
void eeconfig_init_user(void) { // EEPROM is getting reset!
void eeconfig_init_user(void) { // EEPROM is getting reset!
user_config.raw = 0;
user_config.rgb_layer_change = true; // We want this enabled by default
eeconfig_update_user(user_config.raw); // Write default value to EEPROM now
@@ -489,24 +464,14 @@ The `val` is the value of the data that you want to write to EEPROM. And the `e
# Custom Tapping Term
By default, the tapping term and related options (such as `IGNORE_MOD_TAP_INTERRUPT`) are defined globally, and are not configurable by key. For most users, this is perfectly fine. But in some cases, dual function keys would be greatly improved by different timeout behaviors than `LT` keys, or because some keys may be easier to hold than others. Instead of using custom key codes for each, this allows for per key configurable timeout behaviors.
By default, the tapping term is defined globally, and is not configurable by key. For most users, this is perfectly fine. But in come cases, dual function keys would be greatly improved by different timeouts than `LT` keys, or because some keys may be easier to hold than others. Instead of using custom key codes for each, this allows for per key configurable `TAPPING_TERM`.
There are two configurable options to control per-key timeout behaviors:
- `TAPPING_TERM_PER_KEY`
- `IGNORE_MOD_TAP_INTERRUPT_PER_KEY`
You need to add `#define` lines to your `config.h` for each feature you want.
```
#define TAPPING_TERM_PER_KEY
#define IGNORE_MOD_TAP_INTERRUPT_PER_KEY
```
To enable this functionality, you need to add `#define TAPPING_TERM_PER_KEY` to your `config.h`, first.
## Example `get_tapping_term` Implementation
To change the `TAPPING_TERM` based on the keycode, you'd want to add something like the following to your `keymap.c` file:
To change the `TAPPING TERM` based on the keycode, you'd want to add something like the following to your `keymap.c` file:
```c
uint16_t get_tapping_term(uint16_t keycode) {
@@ -521,21 +486,6 @@ uint16_t get_tapping_term(uint16_t keycode) {
}
```
## Example `get_ignore_mod_tap_interrupt` Implementation
### `get_tapping_term` Function Documentation
To change the `IGNORE_MOD_TAP_INTERRUPT` value based on the keycode, you'd want to add something like the following to your `keymap.c` file:
```c
bool get_ignore_mod_tap_interrupt(uint16_t keycode) {
switch (keycode) {
case SFT_T(KC_SPC):
return true;
default:
return false;
}
}
```
## `get_tapping_term` / `get_ignore_mod_tap_interrupt` Function Documentation
Unlike many of the other functions here, there isn't a need (or even reason) to have a quantum or keyboard level function. Only user level functions are useful here, so no need to mark them as such.
Unlike many of the other functions here, there isn't a need (or even reason) to have a quantum or keyboard level function. Only a user level function is useful here, so no need to mark it as such.
-33
View File
@@ -1,33 +0,0 @@
# Quantum Mechanical Keyboard Firmware
[![Aktuelle Version](https://img.shields.io/github/tag/qmk/qmk_firmware.svg)](https://github.com/qmk/qmk_firmware/tags)
[![Build Status](https://travis-ci.org/qmk/qmk_firmware.svg?branch=master)](https://travis-ci.org/qmk/qmk_firmware)
[![Discord](https://img.shields.io/discord/440868230475677696.svg)](https://discord.gg/Uq7gcHh)
[![Docs Status](https://img.shields.io/badge/docs-ready-orange.svg)](https://docs.qmk.fm)
[![GitHub contributors](https://img.shields.io/github/contributors/qmk/qmk_firmware.svg)](https://github.com/qmk/qmk_firmware/pulse/monthly)
[![GitHub forks](https://img.shields.io/github/forks/qmk/qmk_firmware.svg?style=social&label=Fork)](https://github.com/qmk/qmk_firmware/)
## Was ist QMK Firmware?
QMK (*Quantum Mechanical Keyboard*) ist eine Open-Source-Community, welche die QMK-Firmware, die QMK-Toolbox, [qmk.fm](https://qmk.fm) und diese Dokumententation betreut. QMK-Firmware ist eine Weiterentwicklung der [tmk\_keyboard](http://github.com/tmk/tmk_keyboard)-Tastatur-Firmware mit vielen nützlichen Zusatzfunktionen für Atmel AVR-Prozessoren. Ursprünglich wurde sie für Produkte von [OLKB](http://olkb.com), das [ErgoDox EZ](http://www.ergodox-ez.com) und das [Clueboard](http://clueboard.co/) entwickelt. Im Laufe der Zeit wurde sie mit Hilfe von [ChibiOS](http://chibios.org) auch für die ARM-Architektur angepasst. Außerdem ist es inzwischen möglich, auch handverdrahtete Tastaturen und selbst geätzte PCBs mit QMK zu verwenden.
## Bezugsquelle für QMK
Wenn Du vorhast, deine Tastatur, Tastaturbelegung oder Features zu QMK beizusteuern, geht das am einfachsten, indem Du das [Repository auf Github](https://github.com/qmk/qmk_firmware#fork-destination-box) forkst, die Änderungen in deinem lokalen Repo vornimmst und anschließend einen [Pull Request](https://github.com/qmk/qmk_firmware/pulls) einreichst.
Ansonsten kannst Du es als [zip](https://github.com/qmk/qmk_firmware/zipball/master) oder [tar](https://github.com/qmk/qmk_firmware/tarball/master) herunterladen, oder es direkt via git klonen (`git clone git@github.com:qmk/qmk_firmware.git` bzw. `git clone https://github.com/qmk/qmk_firmware.git`).
## Anleitung fürs Kompilieren
Bevor Du in der Lage bist, die Firmware zu kompilieren, musst Du eine [Entwicklungsumgebung](de/getting_started_build_tools.md) für AVR und/oder ARM aufsetzen. Danach kannst Du mit dem `make` Befehl eine Keymap für deine Tastatur erzeugen. Die Notation dafür ist:
make planck/rev4:default
Dies generiert die Revision `rev4` für eine Tastatur vom Type `planck` mit der `default` Tastaturbelegung. Nicht alle Tastaturen haben Revisionen (auch bekannt als Subprojekt oder Unterordner) weswegen dies auch ausgelassen werden kann:
make preonic:default
## Möglichkeiten der Anpassung
QMK hat viele [Features](de/features.md), die es zu entdecken gibt. In der [Dokumentation](https://docs.qmk.fmk) kannst Du Dir einen Überblick verschaffen. Die meisten Features basieren darauf, die [Tastaturbelegung](de/keymap.md) anzupassen und das Verhalten der [Keycodes](de/keycodes.md) zu verändern.
-121
View File
@@ -1,121 +0,0 @@
* [Anleitung für Anfänger](de/newbs.md)
* [Erste Schritte](de/newbs_getting_started.md)
* [Die erste Firmware](de/newbs_building_firmware.md)
* [Firmware flashen](de/newbs_flashing.md)
* [Testen und Debuggen](de/newbs_testing_debugging.md)
* [Git Tips und Tricks](de/newbs_best_practices.md)
* [Hilfreiche Ressourcen](de/newbs_learn_more_resources.md)
* [QMK Basics](de/README.md)
* [QMK Einführung](de/getting_started_introduction.md)
* [QMK CLI](de/cli.md)
* [QMK CLI Konfiguration](de/cli_configuration.md)
* [Zu QMK beitragen](de/contributing.md)
* [Anleitung für Github](de/getting_started_github.md)
* [Nach Hilfe fragen](de/getting_started_getting_help.md)
* [Breaking Changes](de/breaking_changes.md)
* [2019 Aug 30](de/ChangeLog/20190830.md)
* [FAQ](de/faq.md)
* [Häufige Fragen](de/faq_general.md)
* [Build/Kompilieren](de/faq_build.md)
* [Debugging/Troubleshooting](de/faq_debug.md)
* [Keymap](de/faq_keymap.md)
* [Treiber Installation mit Zadig](de/driver_installation_zadig.md)
* Detailierte Guides
* [Build Tools installieren](de/getting_started_build_tools.md)
* [Vagrant Guide](de/getting_started_vagrant.md)
* [Build/Compile Anleitung](de/getting_started_make_guide.md)
* [Firmware flashen](de/flashing.md)
* [Funktionalität anpassen](de/custom_quantum_functions.md)
* [Keymap Überblick](de/keymap.md)
* [Hardware](de/hardware.md)
* [AVR Prozessoren](de/hardware_avr.md)
* [Treiber](de/hardware_drivers.md)
* Referenz
* [Tastatur Richtlinien](de/hardware_keyboard_guidelines.md)
* [Konfigurations Optionen](de/config_options.md)
* [Keycodes](de/keycodes.md)
* [Coding Konventionen - C](de/coding_conventions_c.md)
* [Coding Konventionen - Python](de/coding_conventions_python.md)
* [Dokumentations Best Practices](de/documentation_best_practices.md)
* [Dokumentations Templates](de/documentation_templates.md)
* [Glossar](de/reference_glossary.md)
* [Unit Testing](de/unit_testing.md)
* [Nützliche Funktionen](de/ref_functions.md)
* [Configurator Support](de/reference_configurator_support.md)
* [info.json Format](de/reference_info_json.md)
* [Python CLI Development](de/cli_development.md)
* [Features](de/features.md)
* [Basic Keycodes](de/keycodes_basic.md)
* [US ANSI Shifted Keys](de/keycodes_us_ansi_shifted.md)
* [Quantum Keycodes](de/quantum_keycodes.md)
* [Advanced Keycodes](de/feature_advanced_keycodes.md)
* [Audio](de/feature_audio.md)
* [Auto Shift](de/feature_auto_shift.md)
* [Backlight](de/feature_backlight.md)
* [Bluetooth](de/feature_bluetooth.md)
* [Bootmagic](de/feature_bootmagic.md)
* [Combos](de/feature_combo.md)
* [Command](de/feature_command.md)
* [Debounce API](de/feature_debounce_type.md)
* [DIP Switch](de/feature_dip_switch.md)
* [Dynamic Macros](de/feature_dynamic_macros.md)
* [Encoders](de/feature_encoders.md)
* [Grave Escape](de/feature_grave_esc.md)
* [Haptic Feedback](de/feature_haptic_feedback.md)
* [HD44780 LCD Controller](de/feature_hd44780.md)
* [Key Lock](de/feature_key_lock.md)
* [Layouts](de/feature_layouts.md)
* [Leader Key](de/feature_leader_key.md)
* [LED Matrix](de/feature_led_matrix.md)
* [Macros](de/feature_macros.md)
* [Mouse Keys](de/feature_mouse_keys.md)
* [OLED Driver](de/feature_oled_driver.md)
* [One Shot Keys](de/feature_advanced_keycodes.md#one-shot-keys)
* [Pointing Device](de/feature_pointing_device.md)
* [PS/2 Mouse](de/feature_ps2_mouse.md)
* [RGB Lighting](de/feature_rgblight.md)
* [RGB Matrix](de/feature_rgb_matrix.md)
* [Space Cadet](de/feature_space_cadet.md)
* [Split Keyboard](de/feature_split_keyboard.md)
* [Stenography](de/feature_stenography.md)
* [Swap Hands](de/feature_swap_hands.md)
* [Tap Dance](de/feature_tap_dance.md)
* [Terminal](de/feature_terminal.md)
* [Thermal Printer](de/feature_thermal_printer.md)
* [Unicode](de/feature_unicode.md)
* [Userspace](de/feature_userspace.md)
* [Velocikey](de/feature_velocikey.md)
* Für Maker und Modder
* [Hand Wiring Guide](de/hand_wire.md)
* [ISP Flashing Guide](de/isp_flashing_guide.md)
* [ARM Debugging Guide](de/arm_debugging.md)
* [I2C Driver](de/i2c_driver.md)
* [GPIO Controls](de/internals_gpio_control.md)
* [Proton C Conversion](de/proton_c_conversion.md)
* Für ein tieferes Verständnis
* [Wie Tastaturen funktionieren](de/how_keyboards_work.md)
* [QMK verstehen](de/understanding_qmk.md)
* Andere Themen
* [Eclipse mit QMK](de/other_eclipse.md)
* [VSCode mit QMK](de/other_vscode.md)
* [Support](de/support.md)
* [Übersetzungen](de/translating.md)
* QMK Internals (In Progress)
* [Defines](de/internals_defines.md)
* [Input Callback Reg](de/internals_input_callback_reg.md)
* [Midi Device](de/internals_midi_device.md)
* [Midi Device Setup Process](de/internals_midi_device_setup_process.md)
* [Midi Util](de/internals_midi_util.md)
* [Send Functions](de/internals_send_functions.md)
* [Sysex Tools](de/internals_sysex_tools.md)
-47
View File
@@ -1,47 +0,0 @@
# Bootloader Treiber Installation mit Zadig
QMK erscheint für den Host als normales HID Eingabegerät und benötigt deshalb keine zusätzlichen Treiber. Der Bootloader, den Du für das Flashen der Firmware benötigst, jedoch meistens schon.
Hierzu gibt es zwei Ausnahmen: den Caterina Bootloader, meistens auf Pro Micros, sowie den HalfKay Bootloader auf PJRC Teensys. Diese erscheinen als serieller Port und als generisches HID Gerät und benötigen keine Treiber.
Wir empfehlen deshalb [Zadig](https://zadig.akeo.ie/). Wenn Du die Entwicklungsumgebung mit MSYS2 oder WSL installiert hast, wird dich dass `qmk_install.sh` Skript gefragt haben, ob es die Treiber für dich installieren sollte.
## Installation
Versetze deine Tastatur in den Bootloader-Modus, entweder durch Betätigung des physischen `RESET` Schalters - meist auf der Unterseite der Platine - oder durch das Auslösen des Key-Codes `RESET` bzw. `KC_RESET` (sollte in der zur Tastatur gehörigen `keycode.c` zu entnehmen sein). Sollte deine Tastatur weder noch besitzen, versuche es damit die `Escape`-Taste oder `Leertaste + B` zu halten während Du die Tastatur mit dem PC verbindest (Siehe auch [Bootmagic](de/feature_bootmagic.md) für weitere Details). Ein paar Tastaturen benutzen das [Command](de/feature_command.md)-Feature an Stelle von Bootmagic; in diesem Fall kannst du mit den Tastenkombinationen `linkes Shift + rechtes Shift + B` oder `linkes Shift + rechtes Shift + Escape` zu jeder Zeit in den Bootloader wechseln solange die Tastatur verbunden ist.
Eingie Tastaturen haben u.U. spezielle Anweisungen um in den Bootloader-Modus zu gelangen. Zum Beispiel kann die [Bootmagic-Lite](de/feature_bootmagic.md#bootmagic-lite)-Taste (default: Escape) auf eine andere Taste gemappt sein; oder die magische Kombination (default: linkes Shift+rechtes Shift) verwendet anstatt Shift die STRG-Tasten. Die zur Tastatur gehörige README sollte dir Aufschluss darüber geben wie der Bootloader-Modus ausgelöst werden kann wenn Du unsicher bist.
Um ein Gerät mit USBaspLoader in den Bootloader-Modus zu versetzen, halte `BOOT` gedrückt während Du den `RESET`-Knopf drückst.
Alternativ, halte `BOOT` gedrückt während Du das USB-Kabel einsteckst.
Zadig sollte das Bootloader-Gerät automatisch erkennen. Manchmal musst Du zusätzlich noch **Options → List All Devices** auswählen.
- Tastaturen mit Atmel AVR MCUs sollten als `ATm32U4DFU` (oder ähnlich) angezeigt werden, mit der Vendor ID `03EB`.
- USBasp werden als `USBasp` angezeigt, mit VID/PID `16C0:05DC`.
- Tastaturen AVR controller und dem QMK-DFU Bootloader haben den namen `<Tastatur Name> Bootloader` und die VID `03EB`.
- Die meisten ARM Tastaturen werden als `STM32 BOOTLOADER` angezeigt, mit VID/PID `0483:DF11`.
!> Sollte Zadig ein oder mehrere Geräte mit `HidUsb`-Treiber anzeigen, dann ist deine Tastatur wahrscheinlich nicht im Bootloader-Modus. Der Pfeil wird orange eingefärbt sein und Du wirst nach einer Bestätigung gefragt um Veränderungen am System vorzunehmen. In diesem Fall **fahre nicht fort**!
Wenn der Pfeil grün angezeigt wird, wähle den Treiber aus und klicke auf **Treiber installieren**. Der `libusb-win32`-Treiber sollte gewöhnlich für AVR verwendet werden und `WinUSB` für ARM. Sollte es danach noch nicht möglich sein die Tastatur zu flashen, versuche es mit einem anderen Treiber. Für USBaspLoader Geräte, die über die Befehlszeile mit MSYS2 geflasht werden, wird der `libusbk`-Treiber empfohlen. Ansonsten sollte `libusb-win32` funktionieren wenn die QMK Toolbox verwendet wird.
![Zadig mit Bootloader-Treiber korrekt installiert](https://i.imgur.com/b8VgXzx.png)
Entferne nun deine Tastatur und verbinde sie erneut um sicherzugehen dass der neue Treiber erfolgreich installiert wurde. Wenn Du QMK Toolbox benutzt, starte die Anwendung zur Sicherheit einmal neu, da Veränderungen am Treiber manchmal nicht richtig erkannt werden. Wenn dies immer noch nicht erfolgreich war hilft es an dieser Stelle manchmal ein Neustart des Computers.
## Wiederherstellung einer Installation für ein falsches Gerät
Wenn Du feststellst dass Du anschließend auf deiner Tastatur nicht mehr tippen kannst, ist etwas bei der Installation schief gelaufen. Ein häufiger Fehler ist es dass die Tastatur nicht im Bootloader-Modus war und stattdessen der Treiber für das HID-Gerät ersetzt wurde. Dies kannst Du einfach mit Zadig überprüfen, eine funktionierende Tastatur verwendet als Treiber `HidUsb` auf allen Interfaces .
![Eine funktionierende Tastatur aus Zadigs Sicht](https://i.imgur.com/Hx0E5kC.png)
Öffne den Geräte-Manager und suche nach einem Gerät das wie deine Tastatur aussieht.
![Die Tastatur mit dem falschen Treiber installiert, im Geräte-Manager](https://i.imgur.com/L3wvX8f.png)
Rechtsklick und **Gerät deinstallieren** anklicken. Bitte gehe sicher dass in diesem Schritt auch **Treibersoftware für dieses Gerät löschen** markiert ist.
![Der "Gerät deinstallieren"-Dialog, mit "Treibersoftware für dieses Gerät entfernen" markiert](https://i.imgur.com/aEs2RuA.png)
Klick **Aktion → Suche nach veränderter Hardware**. Nun solltest Du wieder in der Lage sein normal zu tippen. Vergewissere dich mit Hilfe von Zadig dass die Tastatur nun `HidUsb` als Treiber verwendet. Wenn dies der Fall ist sollte wieder alles funktionieren.

Some files were not shown because too many files have changed in this diff Show More