Compare commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
64b7cfe735 | ||
|
|
908aede957 | ||
|
|
cb3b5563e4 | ||
|
|
d624690135 | ||
|
|
f164016566 | ||
|
|
0e6f78547e | ||
|
|
476f556613 |
No files matched your search
+22
-2
@@ -112,7 +112,7 @@ ifeq ($(strip $(RGBLIGHT_ENABLE)), yes)
|
|||||||
ifeq ($(strip $(RGBLIGHT_CUSTOM_DRIVER)), yes)
|
ifeq ($(strip $(RGBLIGHT_CUSTOM_DRIVER)), yes)
|
||||||
OPT_DEFS += -DRGBLIGHT_CUSTOM_DRIVER
|
OPT_DEFS += -DRGBLIGHT_CUSTOM_DRIVER
|
||||||
else
|
else
|
||||||
SRC += ws2812.c
|
WS2812_DRIVER_REQUIRED = yes
|
||||||
endif
|
endif
|
||||||
endif
|
endif
|
||||||
|
|
||||||
@@ -176,7 +176,7 @@ endif
|
|||||||
|
|
||||||
ifeq ($(strip $(RGB_MATRIX_ENABLE)), WS2812)
|
ifeq ($(strip $(RGB_MATRIX_ENABLE)), WS2812)
|
||||||
OPT_DEFS += -DWS2812
|
OPT_DEFS += -DWS2812
|
||||||
SRC += ws2812.c
|
WS2812_DRIVER_REQUIRED = yes
|
||||||
endif
|
endif
|
||||||
|
|
||||||
ifeq ($(strip $(RGB_MATRIX_CUSTOM_KB)), yes)
|
ifeq ($(strip $(RGB_MATRIX_CUSTOM_KB)), yes)
|
||||||
@@ -262,6 +262,26 @@ ifneq ($(strip $(BACKLIGHT_ENABLE)), no)
|
|||||||
endif
|
endif
|
||||||
endif
|
endif
|
||||||
|
|
||||||
|
VALID_WS2812_DRIVER_TYPES := bitbang pwm spi i2c
|
||||||
|
|
||||||
|
WS2812_DRIVER ?= bitbang
|
||||||
|
ifeq ($(strip $(WS2812_DRIVER_REQUIRED)), yes)
|
||||||
|
ifeq ($(filter $(WS2812_DRIVER),$(VALID_WS2812_DRIVER_TYPES)),)
|
||||||
|
$(error WS2812_DRIVER="$(WS2812_DRIVER)" is not a valid WS2812 driver)
|
||||||
|
endif
|
||||||
|
|
||||||
|
ifeq ($(strip $(WS2812_DRIVER)), bitbang)
|
||||||
|
SRC += ws2812.c
|
||||||
|
else
|
||||||
|
SRC += ws2812_$(strip $(WS2812_DRIVER)).c
|
||||||
|
endif
|
||||||
|
|
||||||
|
# add extra deps
|
||||||
|
ifeq ($(strip $(WS2812_DRIVER)), i2c)
|
||||||
|
QUANTUM_LIB_SRC += i2c_master.c
|
||||||
|
endif
|
||||||
|
endif
|
||||||
|
|
||||||
ifeq ($(strip $(CIE1931_CURVE)), yes)
|
ifeq ($(strip $(CIE1931_CURVE)), yes)
|
||||||
OPT_DEFS += -DUSE_CIE1931_CURVE
|
OPT_DEFS += -DUSE_CIE1931_CURVE
|
||||||
LED_TABLES = yes
|
LED_TABLES = yes
|
||||||
|
|||||||
@@ -98,6 +98,7 @@
|
|||||||
* [ISP Flashing Guide](isp_flashing_guide.md)
|
* [ISP Flashing Guide](isp_flashing_guide.md)
|
||||||
* [ARM Debugging Guide](arm_debugging.md)
|
* [ARM Debugging Guide](arm_debugging.md)
|
||||||
* [I2C Driver](i2c_driver.md)
|
* [I2C Driver](i2c_driver.md)
|
||||||
|
* [WS2812 Driver](ws2812_driver.md)
|
||||||
* [GPIO Controls](internals_gpio_control.md)
|
* [GPIO Controls](internals_gpio_control.md)
|
||||||
* [Proton C Conversion](proton_c_conversion.md)
|
* [Proton C Conversion](proton_c_conversion.md)
|
||||||
|
|
||||||
|
|||||||
+169
@@ -0,0 +1,169 @@
|
|||||||
|
# QMK CLI (Kommandozeile)
|
||||||
|
|
||||||
|
Diese Seite beschreibt die Einrichtung und den Umgang mit dem QMK CLI (Kommandozeile).
|
||||||
|
|
||||||
|
# Übersicht
|
||||||
|
|
||||||
|
Die QMK CLI vereinfacht das Zusammenbauen und Arbeiten mit QMK Tastaturen. Hier findest Du wichtige Befehle, um beispielsweise das Herunterladen und Kompilieren der QMK Firmware oder das Erstellen von Tastaturbelegungen (und vieles mehr) zu erleichtern.
|
||||||
|
|
||||||
|
* [Globale CLI](#globale-cli)
|
||||||
|
* [Lokale CLI](#lokale-cli)
|
||||||
|
* [CLI-Befehle](#cli-befehle)
|
||||||
|
|
||||||
|
# System-Anforderungen
|
||||||
|
|
||||||
|
Die CLI benötigt Python 3.5 oder höher. Außerdem ist es nötig, die Packages laut [`requirements.txt`](https://github.com/qmk/qmk_firmware/blob/master/requirements.txt) zu installieren.
|
||||||
|
|
||||||
|
# Globale CLI
|
||||||
|
|
||||||
|
QMK bietet ein installierbares CLI, das Du zum Einrichten Deiner QMK Build-Umgebung verwenden kannst. Dieses ermöglicht Dir das Arbeiten mit QMK, und erleichtert das Arbeiten mit mehreren Kopien der `qmk_firmware`. Wir empfehlen, dieses CLI zu installieren und regelmäßig upzudaten.
|
||||||
|
|
||||||
|
## Installation mit Homebrew (macOS, manche Linux)
|
||||||
|
|
||||||
|
Solltest Du [Homebrew](https://brew.sh) installiert haben, kannst Du QMK per tap installieren:
|
||||||
|
|
||||||
|
```
|
||||||
|
brew tap qmk/qmk
|
||||||
|
brew install qmk
|
||||||
|
export QMK_HOME='~/qmk_firmware' # Optional: setzt den Installationsort für `qmk_firmware`
|
||||||
|
qmk setup # Dies klont `qmk/qmk_firmware` und richtet optional auch Deine Build-Umgebung ein
|
||||||
|
```
|
||||||
|
|
||||||
|
## Installation mit easy_install oder pip
|
||||||
|
|
||||||
|
Falls Du kein Homebrew hast, kannst Du QMK auch manuell installieren. Zuerst musst Du sicherstellen, dass Python 3.5 (oder höher) und pip installiert ist. Dann installiere QMK mit diesem Befehl:
|
||||||
|
|
||||||
|
```
|
||||||
|
pip3 install qmk
|
||||||
|
export QMK_HOME='~/qmk_firmware' # Optional: setzt den Installationsort für `qmk_firmware`
|
||||||
|
qmk setup # Dies klont `qmk/qmk_firmware` und richtet optional auch Deine Build-Umgebung ein
|
||||||
|
```
|
||||||
|
## Installation mit git Repo
|
||||||
|
|
||||||
|
`git clone https://github.com/qmk/qmk_cli.git && cd qmk_cli && python3 setup.py install`
|
||||||
|
|
||||||
|
## Packaging für andere Betriebssysteme
|
||||||
|
|
||||||
|
Wir suchen nach Freiwilligen, die ein `qmk`-Package für weitere Betriebssysteme erstellen und pflegen. Falls Du ein Package für Dein OS erstellen möchtest, bitte befolge diese Richtlinien:
|
||||||
|
|
||||||
|
* Verwende "Best Practices" für Dein OS, sollten sie mit diesen Richtlinien in Konflikt stehen.
|
||||||
|
* Dokumentiere den Grund in einem Kommentar, wenn Du abweichen musstest.
|
||||||
|
* Installiere mit einem [virtualenv](https://virtualenv.pypa.io/en/latest/).
|
||||||
|
* Weise den User an, die Umgebungs-Variable `QMK_HOME` zu setzen, um die Firmware-Quelle anders einzustellen als `~/qmk_firmware`.
|
||||||
|
|
||||||
|
# Lokale CLI
|
||||||
|
|
||||||
|
Wenn Du die globale CLI nicht verwenden möchtest, beinhaltet `qmk_firmware` auch eine lokale CLI. Du kannst sie hier finden: `qmk_firmware/bin/qmk`. Du kannst den `qmk`-Befehl aus irgendeinem Datei-Verzeichnis ausführen und es wird immer auf dieser Kopie von `qmk_firmware` arbeiten.
|
||||||
|
|
||||||
|
**Beispiel**:
|
||||||
|
|
||||||
|
```
|
||||||
|
$ ~/qmk_firmware/bin/qmk hello
|
||||||
|
Ψ Hello, World!
|
||||||
|
```
|
||||||
|
|
||||||
|
## Einschränkungen der lokalen CLI
|
||||||
|
|
||||||
|
Hier ein Vergleich mit der globalen CLI:
|
||||||
|
|
||||||
|
* Die lokale CLI unterstützt kein `qmk setup` oder `qmk clone`.
|
||||||
|
* Die lokale CLI arbeitet immer innerhalb der selben `qmk_firmware`-Verzeichnisstruktur, auch wenn Du mehrere Repositories geklont hast.
|
||||||
|
* Die lokale CLI läuft nicht in einer virtualenv. Daher ist es möglich, dass Abhängigkeiten (dependencies) miteinander in Konflikt kommen/stehen.
|
||||||
|
|
||||||
|
# CLI-Befehle
|
||||||
|
|
||||||
|
## `qmk compile`
|
||||||
|
|
||||||
|
Dieser Befehl erlaubt es dir, die Firmware - aus egal welchem Datei-Verzeichnis - zu compilen. Du kannst JSON-Exporte von <https://config.qmk.fm> oder Keymaps in der Repo kompilen.
|
||||||
|
|
||||||
|
**Anwendung für Konfigurations-Exports**:
|
||||||
|
|
||||||
|
```
|
||||||
|
qmk compile <configuratorExport.json>
|
||||||
|
```
|
||||||
|
|
||||||
|
**Anwendung für Keymaps**:
|
||||||
|
|
||||||
|
```
|
||||||
|
qmk compile -kb <keyboard_name> -km <keymap_name>
|
||||||
|
```
|
||||||
|
|
||||||
|
## `qmk cformat`
|
||||||
|
|
||||||
|
Dieser Befehl formatiert C-Code im clang-Format. Benutze ihn ohne Argumente, um den core-Code zu formatieren, oder benutze Namen von Dateien in der CLI, um den Befehl auf bestimmte Dateien anzuwenden.
|
||||||
|
|
||||||
|
**Anwendung**:
|
||||||
|
|
||||||
|
```
|
||||||
|
qmk cformat [file1] [file2] [...] [fileN]
|
||||||
|
```
|
||||||
|
|
||||||
|
## `qmk config`
|
||||||
|
|
||||||
|
Dieser Befehl konfiguriert das Verhalten von QMK. Für die volle `qmk config`-Dokumentation gehe zu [CLI-Konfiguration](cli_configuration.md).
|
||||||
|
|
||||||
|
**Anwendung**:
|
||||||
|
|
||||||
|
```
|
||||||
|
qmk config [-ro] [config_token1] [config_token2] [...] [config_tokenN]
|
||||||
|
```
|
||||||
|
|
||||||
|
## `qmk docs`
|
||||||
|
|
||||||
|
Dieser Befehl startet einen lokalen HTTP-Server, den Du zum Browsen oder Verbessern der Dokumentation verwenden kannst. Der Default-Port ist 8936.
|
||||||
|
|
||||||
|
**Anwendung**:
|
||||||
|
|
||||||
|
```
|
||||||
|
qmk docs [-p PORT]
|
||||||
|
```
|
||||||
|
|
||||||
|
## `qmk doctor`
|
||||||
|
|
||||||
|
Dieser Befehl untersucht Deine Umgebung und warnt Dich vor potentiellen Build- oder Flash-Problemen.
|
||||||
|
|
||||||
|
**Anwendung**:
|
||||||
|
|
||||||
|
```
|
||||||
|
qmk doctor
|
||||||
|
```
|
||||||
|
|
||||||
|
## `qmk list-keyboards`
|
||||||
|
|
||||||
|
Dieser Befehl listet alle zurzeit in `qmk_firmware` definierten Tastaturen/Keyboards auf.
|
||||||
|
|
||||||
|
**Anwendung**:
|
||||||
|
|
||||||
|
```
|
||||||
|
qmk list-keyboards
|
||||||
|
```
|
||||||
|
|
||||||
|
## `qmk new-keymap`
|
||||||
|
|
||||||
|
Dieser Befehl erstellt eine neue Keymap basierend auf einer existierenden Standard-Keymap eines bestimmten Keyboards.
|
||||||
|
|
||||||
|
**Anwendung**:
|
||||||
|
|
||||||
|
```
|
||||||
|
qmk new-keymap [-kb KEYBOARD] [-km KEYMAP]
|
||||||
|
```
|
||||||
|
|
||||||
|
## `qmk pyformat`
|
||||||
|
|
||||||
|
Dieser Befehl formatiert Python-Code in `qmk_firmware`.
|
||||||
|
|
||||||
|
**Anwendung**:
|
||||||
|
|
||||||
|
```
|
||||||
|
qmk pyformat
|
||||||
|
```
|
||||||
|
|
||||||
|
## `qmk pytest`
|
||||||
|
|
||||||
|
Dieser Befehl führt die Python Test Suite aus. Wenn Du Python-Code veränderst, solltest Du sicherstellen, dass der Test erfolgreich ausgeführt wurde.
|
||||||
|
|
||||||
|
**Anwendung**:
|
||||||
|
|
||||||
|
```
|
||||||
|
qmk pytest
|
||||||
|
```
|
||||||
@@ -2,18 +2,18 @@
|
|||||||
|
|
||||||
## Bluetooth Known Supported Hardware
|
## Bluetooth Known Supported Hardware
|
||||||
|
|
||||||
Currently Bluetooth support is limited to AVR based chips. For Bluetooth 2.1 Qmk has support for RN-42 HID Firmware and Bluefruit EZ Key the later of which is not produced anymore. For more recent BLE protocols currently only the Adafruit Bluefruit SPI friend is directly supported. BLE is needed to connect to iOS devices. Note iOS does not support Mouse Input.
|
Currently Bluetooth support is limited to AVR based chips. For Bluetooth 2.1, QMK has support for RN-42 modules and the Bluefruit EZ-Key, the latter of which is not produced anymore. For more recent BLE protocols, currently only the Adafruit Bluefruit SPI Friend is directly supported. BLE is needed to connect to iOS devices. Note iOS does not support mouse input.
|
||||||
|
|
||||||
|Board |Bluetooth Protocol |Connection Type |Rules.mk |Bluetooth Chip|
|
|Board |Bluetooth Protocol |Connection Type |rules.mk |Bluetooth Chip|
|
||||||
|----------------------------------------------------------------|----------------------------|----------------|---------------------------|--------------|
|
|----------------------------------------------------------------|----------------------------|----------------|---------------------------|--------------|
|
||||||
|[Adafruit EzKey HID]("https://www.adafruit.com/product/1535") |Bluetooth Classic | UART | BLUETOOTH = AdafruitEZKey | |
|
|[Adafruit EZ-Key HID](https://www.adafruit.com/product/1535) |Bluetooth Classic | UART |`BLUETOOTH = AdafruitEZKey` | |
|
||||||
|Rover Networks RN-42 (Sparkfun Bluesmirf) |Bluetooth Classic | UART | BLUETOOTH = RN42 | RN-42 |
|
|Roving Networks RN-42 (Sparkfun Bluesmirf) |Bluetooth Classic | UART |`BLUETOOTH = RN42` | RN-42 |
|
||||||
|[Bluefruit LE SPI Friend](https://www.adafruit.com/product/2633)|Bluetooth Low Energy | SPI | BLUETOOTH = AdafruitBLE | nRF5182 |
|
|[Bluefruit LE SPI Friend](https://www.adafruit.com/product/2633)|Bluetooth Low Energy | SPI |`BLUETOOTH = AdafruitBLE` | nRF51822 |
|
||||||
|
|
||||||
Not Supported Yet but possible:
|
Not Supported Yet but possible:
|
||||||
* [Bluefruit LE UART Friend](https://www.adafruit.com/product/2479). [Possible tmk implementation found in](https://github.com/tmk/tmk_keyboard/issues/514)
|
* [Bluefruit LE UART Friend](https://www.adafruit.com/product/2479). [Possible tmk implementation found in](https://github.com/tmk/tmk_keyboard/issues/514)
|
||||||
* HC-05 boards flashed with RN-42 firmware. They apparently both use the CSR BC417 Chip. Flashing it with RN-42 firmware gives it HID capability.
|
* HC-05 boards flashed with RN-42 firmware. They apparently both use the CSR BC417 Chip. Flashing it with RN-42 firmware gives it HID capability.
|
||||||
* [Sparkfun Bluetooth mate](https://www.sparkfun.com/products/14839)
|
* Sparkfun Bluetooth Mate
|
||||||
* HM-13 based boards
|
* HM-13 based boards
|
||||||
|
|
||||||
### Adafruit BLE SPI Friend
|
### Adafruit BLE SPI Friend
|
||||||
|
|||||||
@@ -211,15 +211,7 @@ bool process_record_user(uint16_t keycode, keyrecord_t *record) {
|
|||||||
if ( (temp_mod | temp_osm) & MOD_MASK_SHIFT )
|
if ( (temp_mod | temp_osm) & MOD_MASK_SHIFT )
|
||||||
#endif
|
#endif
|
||||||
{ //
|
{ //
|
||||||
#if defined(__arm__) // only run for ARM boards
|
SEND_STRING(":flash");
|
||||||
SEND_STRING(":dfu-util");
|
|
||||||
#elif defined(BOOTLOADER_DFU) // only run for DFU boards
|
|
||||||
SEND_STRING(":dfu");
|
|
||||||
#elif defined(BOOTLOADER_HALFKAY) // only run for teensy boards
|
|
||||||
SEND_STRING(":teensy");
|
|
||||||
#elif defined(BOOTLOADER_CATERINA) // only run for Pro Micros
|
|
||||||
SEND_STRING(":avrdude");
|
|
||||||
#endif // bootloader options
|
|
||||||
}
|
}
|
||||||
if ( (temp_mod | temp_osm) & MOD_MASK_CTRL) {
|
if ( (temp_mod | temp_osm) & MOD_MASK_CTRL) {
|
||||||
SEND_STRING(" -j8 --output-sync");
|
SEND_STRING(" -j8 --output-sync");
|
||||||
@@ -244,7 +236,7 @@ endif
|
|||||||
|
|
||||||
This will add a new `KC_MAKE` keycode that can be used in any of your keymaps. And this keycode will output `make <keyboard>:<keymap>`, making frequent compiling easier. And this will work with any keyboard and any keymap as it will output the current boards info, so that you don't have to type this out every time.
|
This will add a new `KC_MAKE` keycode that can be used in any of your keymaps. And this keycode will output `make <keyboard>:<keymap>`, making frequent compiling easier. And this will work with any keyboard and any keymap as it will output the current boards info, so that you don't have to type this out every time.
|
||||||
|
|
||||||
Also, holding `shift` will add the appropriate flashing command (`:dfu`, `:teensy`, `:avrdude`, `:dfu-util`) for a majority of keyboards. Holding `control` will add some commands that will speed up compiling time by processing multiple files at once.
|
Also, holding Shift will add the flash target (`:flash`) to the command. Holding Control will add some commands that will speed up compiling time by processing multiple files at once.
|
||||||
|
|
||||||
And for the boards that lack a shift key, or that you want to always attempt the flashing part, you can add `FLASH_BOOTLOADER = yes` to the `rules.mk` of that keymap.
|
And for the boards that lack a shift key, or that you want to always attempt the flashing part, you can add `FLASH_BOOTLOADER = yes` to the `rules.mk` of that keymap.
|
||||||
|
|
||||||
|
|||||||
+9
-4
@@ -99,11 +99,16 @@ or
|
|||||||
|
|
||||||
make <keyboard>:<keymap>:avrdude
|
make <keyboard>:<keymap>:avrdude
|
||||||
|
|
||||||
or if you want to flash multiple boards, use the following command
|
|
||||||
|
|
||||||
make <keyboard>:<keymap>:avrdude-loop
|
#### Caterina commands
|
||||||
|
|
||||||
|
There are a number of DFU commands that you can use to flash firmware to a DFU device:
|
||||||
|
|
||||||
|
* `:avrdude` - This is the normal option which waits until a Caterina device is available (by detecting a new COM port), and then flashes the firmware.
|
||||||
|
* `:avrdude-loop` - This runs the same command as `:avrdude`, but after each device is flashed, it will attempt to flash again. This is useful for bulk flashing. _This requires you to manually escape the loop by hitting Ctrl+C._
|
||||||
|
* `:avrdude-split-left` - This flashes the normal firmware, just like the default option (`:avrdude`). However, this also flashes the "Left Side" EEPROM file for split keyboards. _This is ideal for Pro Micro based split keyboards._
|
||||||
|
* `:avrdude-split-right` - This flashes the normal firmware, just like the default option (`:avrdude`). However, this also flashes the "Right Side" EEPROM file for split keyboards. _This is ideal for Pro Micro based split keyboards._
|
||||||
|
|
||||||
When you're done flashing boards, you'll need to hit Ctrl + C or whatever the correct keystroke is for your operating system to break the loop.
|
|
||||||
|
|
||||||
|
|
||||||
## Halfkay
|
## Halfkay
|
||||||
@@ -231,7 +236,7 @@ Flashing sequence:
|
|||||||
|
|
||||||
There are a number of DFU commands that you can use to flash firmware to a STM32 device:
|
There are a number of DFU commands that you can use to flash firmware to a STM32 device:
|
||||||
|
|
||||||
* `:dfu-util` - The default command for flashing to STM32 devices.
|
* `:dfu-util` - The default command for flashing to STM32 devices, and will wait until an STM32 bootloader device is present.
|
||||||
* `:dfu-util-split-left` - This flashes the normal firmware, just like the default option (`:dfu-util`). However, this also configures the "Left Side" EEPROM setting for split keyboards.
|
* `:dfu-util-split-left` - This flashes the normal firmware, just like the default option (`:dfu-util`). However, this also configures the "Left Side" EEPROM setting for split keyboards.
|
||||||
* `:dfu-util-split-right` - This flashes the normal firmware, just like the default option (`:dfu-util`). However, this also configures the "Right Side" EEPROM setting for split keyboards.
|
* `:dfu-util-split-right` - This flashes the normal firmware, just like the default option (`:dfu-util`). However, this also configures the "Right Side" EEPROM setting for split keyboards.
|
||||||
* `:st-link-cli` - This allows you to flash the firmware via ST-LINK's CLI utility, rather than dfu-util.
|
* `:st-link-cli` - This allows you to flash the firmware via ST-LINK's CLI utility, rather than dfu-util.
|
||||||
@@ -6,9 +6,9 @@ Ce document présente les fusions de Breaking Change. Voici la liste des changem
|
|||||||
|
|
||||||
## Formattage de code Core avec clang-format
|
## Formattage de code Core avec clang-format
|
||||||
|
|
||||||
* Tous les fichiers core (`drivers/`, `quantum/`, `tests/`, et `tmk_core/`) seront formattés avec clang-format
|
* Tous les fichiers core (`drivers/`, `quantum/`, `tests/`, et `tmk_core/`) seront formatés avec clang-format
|
||||||
* Un processus travis pour reformatter les PRs lors de la fusion a été mis en place
|
* Un processus travis pour reformatter les PRs lors de la fusion a été mis en place
|
||||||
* Vous pouvez utiliser la nouvelle commande CLI `qmk cformat` afin de formatter avant de soumettre votre PR si vous le souhaitez.
|
* Vous pouvez utiliser la nouvelle commande CLI `qmk cformat` afin de formater avant de soumettre votre PR si vous le souhaitez.
|
||||||
|
|
||||||
## Nettoyage des descripteurs LUFA USB
|
## Nettoyage des descripteurs LUFA USB
|
||||||
|
|
||||||
|
|||||||
@@ -7,7 +7,7 @@
|
|||||||
[](https://github.com/qmk/qmk_firmware/pulse/monthly)
|
[](https://github.com/qmk/qmk_firmware/pulse/monthly)
|
||||||
[](https://github.com/qmk/qmk_firmware/)
|
[](https://github.com/qmk/qmk_firmware/)
|
||||||
|
|
||||||
## Qu'est ce que QMK Firmware ?
|
## Qu'est-ce que QMK Firmware ?
|
||||||
|
|
||||||
QMK (*Quantum Mechanical Keyboard*) est une communauté open source qui maintient le firmware QMK, la QMK Toolbox (*Boite à outil*), qmk.fm et leurs documentations. QMK Firmware est un firmware dédié aux claviers qui est basé sur [tmk\_keyboard](http://github.com/tmk/tmk_keyboard). Il offre des fonctionnalités très utiles pour les contrôleurs Atmel AVR, et, plus spécifiquement pour [les produits d'OLKB](http://olkb.com), le clavier [ErgoDox EZ](http://www.ergodox-ez.com), et pour les [produits Clueboard](http://clueboard.co/). Il prend désormais aussi en charge les processeurs ARM qui utilisent ChibiOS. Vous pouvez l'utiliser pour contrôler un clavier personnalisé soudé à la main ou alors sur un clavier avec un PCB personnalisé.
|
QMK (*Quantum Mechanical Keyboard*) est une communauté open source qui maintient le firmware QMK, la QMK Toolbox (*Boite à outil*), qmk.fm et leurs documentations. QMK Firmware est un firmware dédié aux claviers qui est basé sur [tmk\_keyboard](http://github.com/tmk/tmk_keyboard). Il offre des fonctionnalités très utiles pour les contrôleurs Atmel AVR, et, plus spécifiquement pour [les produits d'OLKB](http://olkb.com), le clavier [ErgoDox EZ](http://www.ergodox-ez.com), et pour les [produits Clueboard](http://clueboard.co/). Il prend désormais aussi en charge les processeurs ARM qui utilisent ChibiOS. Vous pouvez l'utiliser pour contrôler un clavier personnalisé soudé à la main ou alors sur un clavier avec un PCB personnalisé.
|
||||||
|
|
||||||
@@ -23,7 +23,7 @@ Avant d'être prêt à compiler vous allez devoir [installer un environnement](g
|
|||||||
|
|
||||||
make planck/rev4:default
|
make planck/rev4:default
|
||||||
|
|
||||||
Cette commande compilera la révision `rev4` du clavier `planck` avec la disposition `default`. Notez que tous les claviers n'ont pas forcément de révisions (aussi appelées sous-projects ou dossiers, ou en en Anglais « subprojects » ou « folder »). Cette option peut donc être omise :
|
Cette commande compilera la révision `rev4` du clavier `planck` avec la disposition `default`. Notez que tous les claviers n'ont pas forcément de révisions (aussi appelées sous-projects ou dossiers, ou en anglais « subprojects » ou « folder »). Cette option peut donc être omise :
|
||||||
|
|
||||||
make preonic:default
|
make preonic:default
|
||||||
|
|
||||||
|
|||||||
@@ -23,7 +23,7 @@ Le prochain Breaking Change est planifié pour le 29 novembre.
|
|||||||
|
|
||||||
## Quels changements seront inclus?
|
## Quels changements seront inclus?
|
||||||
|
|
||||||
Pour voir une liste de candidats de breaking changes, vous pouvez regardez la liste des [labels `breaking_change`](https://github.com/qmk/qmk_firmware/pulls?q=is%3Aopen+label%3Abreaking_change+is%3Apr). De nouveaux changements peuvent être ajoutés entre maintenant et lorsque `future` est fermée, et un PR avec ce label n'est pas garanti d'être fusionné.
|
Pour voir une liste de candidats de breaking changes, vous pouvez regarder la liste des [labels `breaking_change`](https://github.com/qmk/qmk_firmware/pulls?q=is%3Aopen+label%3Abreaking_change+is%3Apr). De nouveaux changements peuvent être ajoutés entre maintenant et lorsque `future` est fermée, et un PR avec ce label n'est pas garanti d'être fusionné.
|
||||||
|
|
||||||
Si vous souhaitez que votre breaking change soit inclus dans ce tour, vous devez créer un PR avec le label `breaking_change` et faire en sorte qu'il soit accepté avant que `future` ne soit fermé. Une fois `future` fermé, aucun nouveau breaking change sera accepté.
|
Si vous souhaitez que votre breaking change soit inclus dans ce tour, vous devez créer un PR avec le label `breaking_change` et faire en sorte qu'il soit accepté avant que `future` ne soit fermé. Une fois `future` fermé, aucun nouveau breaking change sera accepté.
|
||||||
|
|
||||||
|
|||||||
+3
-3
@@ -4,7 +4,7 @@ Cette page décrit comment configurer et utiliser la CLI QMK.
|
|||||||
|
|
||||||
# Vue d'ensemble
|
# Vue d'ensemble
|
||||||
|
|
||||||
La CLI de QMK permet de simplifier la compilation et l'intéraction avec les clavier QMK. Nous avons définis plusieurs commandes pour simplifier et rationaliser les tâches telles qu'obtenir et compiler le firmware QMK, créer de nouvelles keymaps, et plus.
|
La CLI de QMK permet de simplifier la compilation et l'interaction avec les claviers QMK. Nous avons défini plusieurs commandes pour simplifier et rationaliser les tâches telles qu'obtenir et compiler le firmware QMK, créer de nouvelles keymaps, et plus.
|
||||||
|
|
||||||
* [CLI globale](#global-cli)
|
* [CLI globale](#global-cli)
|
||||||
* [CLI locale](#local-cli)
|
* [CLI locale](#local-cli)
|
||||||
@@ -127,7 +127,7 @@ qmk new-keymap [-kb KEYBOARD] [-km KEYMAP]
|
|||||||
|
|
||||||
## `qmk pyformat`
|
## `qmk pyformat`
|
||||||
|
|
||||||
Cette commande formatte le code python dans `qmk_firmware`.
|
Cette commande formate le code python dans `qmk_firmware`.
|
||||||
|
|
||||||
**Utilisation**:
|
**Utilisation**:
|
||||||
|
|
||||||
@@ -137,7 +137,7 @@ qmk pyformat
|
|||||||
|
|
||||||
## `qmk pytest`
|
## `qmk pytest`
|
||||||
|
|
||||||
Cette commande démarre la suite de test python. Si vous faites des changements dans le code Python, assurez vous que les tests se lancent avec succès.
|
Cette commande démarre la suite de test python. Si vous faites des changements dans le code Python, assurez-vous que les tests se lancent avec succès.
|
||||||
|
|
||||||
**Utilisation**:
|
**Utilisation**:
|
||||||
|
|
||||||
|
|||||||
@@ -41,7 +41,7 @@ user.keymap: None -> default
|
|||||||
|
|
||||||
# CLI Documentation (`qmk config`)
|
# CLI Documentation (`qmk config`)
|
||||||
|
|
||||||
La commande `qmk config` est utilisée pour intéragir avec la configuration sous-jacente. Lancée sans argument, elle affiche la configuration courante. Lorsque des arguments sont définis, ils sont considérés comme étant des jetons de configuration, qui sont des chaînes de caractère ne contenant aucun espace avec le format suivant:
|
La commande `qmk config` est utilisée pour interagir avec la configuration sous-jacente. Lancée sans argument, elle affiche la configuration courante. Lorsque des arguments sont définis, ils sont considérés comme étant des jetons de configuration, qui sont des chaînes de caractère ne contenant aucun espace avec le format suivant:
|
||||||
|
|
||||||
<subcommand|general|default>[.<key>][=<value>]
|
<subcommand|general|default>[.<key>][=<value>]
|
||||||
|
|
||||||
@@ -91,7 +91,7 @@ default.keymap: default -> None
|
|||||||
|
|
||||||
## Plusieurs opérations
|
## Plusieurs opérations
|
||||||
|
|
||||||
Vous pouvez combiner plusieures opérations d'écriture et de lecture en une seule commande. Elle seront exécutées et affichées dans l'ordre:
|
Vous pouvez combiner plusieurs opérations d'écriture et de lecture en une seule commande. Elles seront exécutées et affichées dans l'ordre:
|
||||||
|
|
||||||
```
|
```
|
||||||
$ qmk config compile default.keymap=default compile.keymap=None
|
$ qmk config compile default.keymap=default compile.keymap=None
|
||||||
|
|||||||
@@ -2,7 +2,7 @@
|
|||||||
|
|
||||||
👍🎉 Premièrement, merci de prendre le temps de lire ceci et de contribuer! 🎉👍
|
👍🎉 Premièrement, merci de prendre le temps de lire ceci et de contribuer! 🎉👍
|
||||||
|
|
||||||
Les contributions de tiers nous aide à améliorer et faire grandir QMK. Nous voulons rendre les pull requests et le processus de contribution utile et simple à la fois pour les contributeurs et les mainteneurs. C'est pourquoi nous avons mis en places des directives pour les contibuteurs afin que votre pull request puisse être accepté sans changement majeur.
|
Les contributions de tiers nous aide à améliorer et faire grandir QMK. Nous voulons rendre les pull requests et le processus de contribution utile et simple à la fois pour les contributeurs et les mainteneurs. C'est pourquoi nous avons mis en places des directives pour les contributeurs afin que votre pull request puisse être accepté sans changement majeur.
|
||||||
|
|
||||||
* [Aperçu du projet](#project-overview)
|
* [Aperçu du projet](#project-overview)
|
||||||
* [Conventions de codage](#coding-conventions)
|
* [Conventions de codage](#coding-conventions)
|
||||||
@@ -38,7 +38,7 @@ Vous n'avez encore jamais contribué à un projet open source? Vous vous demande
|
|||||||
0. Enregistrez-vous sur [GitHub](https://github.com).
|
0. Enregistrez-vous sur [GitHub](https://github.com).
|
||||||
1. Définissez une keymap à contribuer, [trouvez une issue](https://github.com/qmk/qmk_firmware/issues) que vous souhaitez corriger, ou [une fonction](https://github.com/qmk/qmk_firmware/issues?q=is%3Aopen+is%3Aissue+label%3Afeature) que vous voulez ajouter.
|
1. Définissez une keymap à contribuer, [trouvez une issue](https://github.com/qmk/qmk_firmware/issues) que vous souhaitez corriger, ou [une fonction](https://github.com/qmk/qmk_firmware/issues?q=is%3Aopen+is%3Aissue+label%3Afeature) que vous voulez ajouter.
|
||||||
2. Créez un fork sur le dépôt associé avec une issue sur votre compte GitHub. Cela veut dire que vous allez avoir une copie du dépôt sous `votre-login-GitHub/qmk_firmware`.
|
2. Créez un fork sur le dépôt associé avec une issue sur votre compte GitHub. Cela veut dire que vous allez avoir une copie du dépôt sous `votre-login-GitHub/qmk_firmware`.
|
||||||
3. Clonez le dépôt sur votre macine locale en utilisant `git clone https://github.com/login-github/repository-name.git`.
|
3. Clonez le dépôt sur votre machine locale en utilisant `git clone https://github.com/login-github/repository-name.git`.
|
||||||
4. Si vous travaillez sur une nouvelle fonctionnalité, pensez à ouvrir une issue pour parler avec nous du travail que vous souhaitez démarrer.
|
4. Si vous travaillez sur une nouvelle fonctionnalité, pensez à ouvrir une issue pour parler avec nous du travail que vous souhaitez démarrer.
|
||||||
5. Créez une nouvelle branche pour votre correctif en utilisant `git checkout -b nom-de-branche`.
|
5. Créez une nouvelle branche pour votre correctif en utilisant `git checkout -b nom-de-branche`.
|
||||||
6. Faites les changements nécessaires pour corriger le problème ou ajouter la fonctionnalité.
|
6. Faites les changements nécessaires pour corriger le problème ou ajouter la fonctionnalité.
|
||||||
@@ -69,7 +69,7 @@ Nous avons un certain nombre de type de changements dans QMK, chacun nécessitan
|
|||||||
* Keymaps: Assurez-vous que `make keyboard:your_new_keymap` ne renvoie pas d'erreur.
|
* Keymaps: Assurez-vous que `make keyboard:your_new_keymap` ne renvoie pas d'erreur.
|
||||||
* Claviers: Assurez-vous que `make keyboard:all` ne renvoie pas d'erreur.
|
* Claviers: Assurez-vous que `make keyboard:all` ne renvoie pas d'erreur.
|
||||||
* Core: Assurez-vous que `make all` ne renvoie pas d'erreur.
|
* Core: Assurez-vous que `make all` ne renvoie pas d'erreur.
|
||||||
* Assurez-vous que les messages de commit soient compréhensibles d'eux-même. Vous devriez écrire une description simple (pas plus de 70 caractères) sur la première ligne, suivi d'une ligne vide, suivi d'un détail de votre commit, si nécessaire. Exemple:
|
* Assurez-vous que les messages de commit soient compréhensibles d'eux-mêmes. Vous devriez écrire une description simple (pas plus de 70 caractères) sur la première ligne, suivi d'une ligne vide, suivi d'un détail de votre commit, si nécessaire. Exemple:
|
||||||
|
|
||||||
```
|
```
|
||||||
Adjust the fronzlebop for the kerpleplork
|
Adjust the fronzlebop for the kerpleplork
|
||||||
@@ -81,11 +81,11 @@ Limited experimentation on the devices I have available shows that 7 is high eno
|
|||||||
|
|
||||||
## Documentation
|
## Documentation
|
||||||
|
|
||||||
La documentation est l'une des manière les plus simples de démarrer la contribution sur QMK. Il est simple de trouver des endroits où la documentation est fausse ou incomplète, et il est tout aussi simple de la corriger! Nous avons aussi grandement besoin de quelqu'un pour éditer notre documentation, donc si vous avez des compétences en édition mais que vous n'êtes pas sûr de savoir où aller, n'hésitez pas [demandez de l'aide](#where-can-i-go-for-help)!
|
La documentation est l'une des manières les plus simples de démarrer la contribution sur QMK. Il est simple de trouver des endroits où la documentation est fausse ou incomplète, et il est tout aussi simple de la corriger! Nous avons aussi grandement besoin de quelqu'un pour éditer notre documentation, donc si vous avez des compétences en édition mais que vous n'êtes pas sûr de savoir où aller, n'hésitez pas [demandez de l'aide](#where-can-i-go-for-help)!
|
||||||
|
|
||||||
Vous trouverez toute notre documentation dans le répertoire `qmk_firmware/docs`, ou si vous préférez utiliser des outils web, vous pouvez cliquer sur le bouton "Suggest An Edit" en haut de chaque page sur http://docs.qmk.fm/.
|
Vous trouverez toute notre documentation dans le répertoire `qmk_firmware/docs`, ou si vous préférez utiliser des outils web, vous pouvez cliquer sur le bouton "Suggest An Edit" en haut de chaque page sur http://docs.qmk.fm/.
|
||||||
|
|
||||||
Lorsque vous donnez des exemples de code dans la documentation, essayez de suivre les conventions de nommage utilisées ailleurs dnas la documentation. Par exemple, standardisez les enums en utilisant `my_layers` ou `my_keycodes` afin de garder une consistance:
|
Lorsque vous donnez des exemples de code dans la documentation, essayez de suivre les conventions de nommage utilisées ailleurs dans la documentation. Par exemple, standardisez les enums en utilisant `my_layers` ou `my_keycodes` afin de garder une consistance:
|
||||||
|
|
||||||
```c
|
```c
|
||||||
enum my_layers {
|
enum my_layers {
|
||||||
@@ -129,16 +129,16 @@ Faites attention d'être sûr d'implémenter votre nouvelle fonctionnalité de l
|
|||||||
* [Chat sur Discord](https://discord.gg/Uq7gcHh)
|
* [Chat sur Discord](https://discord.gg/Uq7gcHh)
|
||||||
* [Ouvrir une Issue](https://github.com/qmk/qmk_firmware/issues/new)
|
* [Ouvrir une Issue](https://github.com/qmk/qmk_firmware/issues/new)
|
||||||
|
|
||||||
Les PR de nouvelles fonctionnalités de de correction de bug affectent tous les claviers. Nous sommes aussi dans un processus de restructuration de QMK. Pour cette raison, il est absolument nécessaire que tout changement important ou significatif soit discuté avant que l'implémentation soit faite. Si vous ouvrez un PR sans nous avoir parlé, préparez vous à faire des refontes significatives si vous changements ne sont pas compatibles avec ce que nous avons planifié.
|
Les PR de nouvelles fonctionnalités de de correction de bug affectent tous les claviers. Nous sommes aussi dans un processus de restructuration de QMK. Pour cette raison, il est absolument nécessaire que tout changement important ou significatif soit discuté avant que l'implémentation soit faite. Si vous ouvrez un PR sans nous avoir parlé, préparez-vous à faire des refontes significatives si vos changements ne sont pas compatibles avec ce que nous avons planifié.
|
||||||
|
|
||||||
Voici quelques choses à garder en tête lorsque vous travaillez sur une fonctionnalité ou un bug fix.
|
Voici quelques choses à garder en tête lorsque vous travaillez sur une fonctionnalité ou un bug fix.
|
||||||
|
|
||||||
* **Désactivé par défaut** - la mémoire est plutôt limitée sur la plupart des puces que QMK supporte, et il est important que les keymaps courantes ne soient pas cassées. S'il vous plaît faites que vos features doivent être **activées** plutôt que désactivées. Si vous pensez qu'elle devrait être activée par défaut, ou que cela réduit la taille du code, parlez-nous en.
|
* **Désactivé par défaut** - la mémoire est plutôt limitée sur la plupart des puces que QMK supporte, et il est important que les keymaps courantes ne soient pas cassées. S'il vous plaît faites que vos features doivent être **activées** plutôt que désactivées. Si vous pensez qu'elle devrait être activée par défaut, ou que cela réduit la taille du code, parlez-nous-en.
|
||||||
* **Compilez localement avant de soumettre** - Cela devrait aller sans dire, mais votre code doit compiler! Notre système Travis devrait relever les problèmes, mais il est généralement plus rapide de compiler quelques claviers en local plutôt que d'attendre le retour des résultats
|
* **Compilez localement avant de soumettre** - Cela devrait aller sans dire, mais votre code doit compiler! Notre système Travis devrait relever les problèmes, mais il est généralement plus rapide de compiler quelques claviers en local plutôt que d'attendre le retour des résultats
|
||||||
* **Faites attention aux révisions et différentes bases de puces** - beaucoup de claviers ont des révisions qui permettent des changements de configuration mineurs, voir des bases de chip différentes. Essayez de faire que votre fonctionnalité soit supportée à la fois sur ARM et AVR, ou désactivez-là automatiquement sur les plateformes non supportées.
|
* **Faites attention aux révisions et différentes bases de puces** - beaucoup de claviers ont des révisions qui permettent des changements de configuration mineurs, voir des bases de chip différentes. Essayez de faire que votre fonctionnalité soit supportée à la fois sur ARM et AVR, ou désactivez-là automatiquement sur les plateformes non supportées.
|
||||||
* **Expliquez votre fonctionnalité** - Documentez-là dans `docs/`, soit dans un nouveau fichier, ou dans une partie d'un fichier existant. Si vous ne la documentez pas, personne ne pourra bénéficier de votre dur labeur.
|
* **Expliquez votre fonctionnalité** - Documentez-là dans `docs/`, soit dans un nouveau fichier, ou dans une partie d'un fichier existant. Si vous ne la documentez pas, personne ne pourra bénéficier de votre dur labeur.
|
||||||
|
|
||||||
Nous vous demandons aussi de suivre ces ces directives:
|
Nous vous demandons aussi de suivre ces directives:
|
||||||
|
|
||||||
* Gardez un nombre de commits raisonnable, ou nous squasherons votre PR.
|
* Gardez un nombre de commits raisonnable, ou nous squasherons votre PR.
|
||||||
* Ne regroupez pas des claviers ou des keymaps avec des changements core. Soumettez vos changements core en premier.
|
* Ne regroupez pas des claviers ou des keymaps avec des changements core. Soumettez vos changements core en premier.
|
||||||
@@ -151,4 +151,4 @@ Afin de maintenir une vision claire sur comment les choses sont architectuées d
|
|||||||
|
|
||||||
# Que veut dire le code de conduite pour moi?
|
# Que veut dire le code de conduite pour moi?
|
||||||
|
|
||||||
Note [Code De Conduite](https://github.com/qmk/qmk_firmware/blob/master/CODE_OF_CONDUCT.md) veut dire que vous avez la responsabilité de traiter tout le monde dans le projet avec respect et courtoisie, peut importe leur identité. Si vous êtes victime d'une attitude ou de commentaires inapropriés, tels que décrit dans notre Code de Conduite, nous sommes là pour vous et nous ferons de notre mieux pour nous assurer que le fautif soit réprimandé, tel que décrit dans notre code.
|
Note [Code De Conduite](https://github.com/qmk/qmk_firmware/blob/master/CODE_OF_CONDUCT.md) veut dire que vous avez la responsabilité de traiter tout le monde dans le projet avec respect et courtoisie, peu importe leur identité. Si vous êtes victime d'une attitude ou de commentaires inappropriés, tels que décrit dans notre Code de Conduite, nous sommes là pour vous et nous ferons de notre mieux pour nous assurer que le fautif soit réprimandé, tel que décrit dans notre code.
|
||||||
+17
-14
@@ -1,6 +1,6 @@
|
|||||||
# Instructions pour flasher et informations sur les bootloader
|
# Instructions pour flasher et informations sur les bootloader
|
||||||
|
|
||||||
Les claviers utilisent différents types de bootloaders et certains doivent être flashés différement. Heureusement, certains projets comme la [QMK Toolbox](https://github.com/qmk/qmk_toolbox/releases) ont pour objectifs de permettre de flasher les différents bootloader sans trop se faire de soucis et ça peut importe les manières de les flasher.
|
Les claviers utilisent différents types de bootloaders et certains doivent être flashés différement. Heureusement, certains projets comme la [QMK Toolbox](https://github.com/qmk/qmk_toolbox/releases) ont pour objectifs de permettre de flasher les différents bootloader sans trop se faire de soucis et ça peu importe les manières de les flasher.
|
||||||
|
|
||||||
Si vous avez un bootloader sélectionné avec la variable `BOOTLOADER` dans votre fichier `rules.mk` alors QMK vas automatiquement calculer si votre fichier .hex n'est pas trop grand pour être flashé sur votre appareil, et il affichera la taille finale du firmware. Pour vérifier la taille manuellement, vous pouvez aussi compiler le firmware avec l'option `check-size`. Exemple : `make planck/rev4:default:check-size`.
|
Si vous avez un bootloader sélectionné avec la variable `BOOTLOADER` dans votre fichier `rules.mk` alors QMK vas automatiquement calculer si votre fichier .hex n'est pas trop grand pour être flashé sur votre appareil, et il affichera la taille finale du firmware. Pour vérifier la taille manuellement, vous pouvez aussi compiler le firmware avec l'option `check-size`. Exemple : `make planck/rev4:default:check-size`.
|
||||||
|
|
||||||
@@ -49,7 +49,7 @@ QMK a un fork du bootloader LUFA DFU qui vous permet de faire un simple scan de
|
|||||||
#define QMK_LED E6
|
#define QMK_LED E6
|
||||||
#define QMK_SPEAKER C6
|
#define QMK_SPEAKER C6
|
||||||
|
|
||||||
Le fabriquant et le nom du produit proviennent de vos définitions dans fichier `config.h`, et la chaîne de caractère « bootloader » est ajoutée au nom du prodruit.
|
Le fabricant et le nom du produit proviennent de vos définitions dans fichier `config.h`, et la chaîne de caractère « bootloader » est ajoutée au nom du produit.
|
||||||
|
|
||||||
Pour génerer le bootloader, utilisez la cible `bootloader`. Exemple : `make planck/rev4:default:bootloader`.
|
Pour génerer le bootloader, utilisez la cible `bootloader`. Exemple : `make planck/rev4:default:bootloader`.
|
||||||
|
|
||||||
@@ -66,7 +66,7 @@ Il y a plusieurs commandes DFU que vous pouvez utiliser pour flasher le firmware
|
|||||||
|
|
||||||
## Caterina
|
## Caterina
|
||||||
|
|
||||||
Les cartes arduinos et leurs clones utilisent le [bootloader Caterina](https://github.com/arduino/ArduinoCore-avr/tree/master/bootloaders/caterina) (tous les claviers utilisant un Pro Micro, ou un clone). Ils utilisent aussi le protocole avr109 pour communiquer en virtuellement en série (serial en Anglais). Les bootloaders comme le [A-Star](https://www.pololu.com/docs/0J61/9) sont basés sur Caterina.
|
Les cartes arduinos et leurs clones utilisent le [bootloader Caterina](https://github.com/arduino/ArduinoCore-avr/tree/master/bootloaders/caterina) (tous les claviers utilisant un Pro Micro, ou un clone). Ils utilisent aussi le protocole avr109 pour communiquer en virtuellement en série (serial en anglais). Les bootloaders comme le [A-Star](https://www.pololu.com/docs/0J61/9) sont basés sur Caterina.
|
||||||
|
|
||||||
Pour vérifier la compatibilité avec un bootloader Caterina, vérifiez que ce bloc est présent dans votre fichier `rules.mk` :
|
Pour vérifier la compatibilité avec un bootloader Caterina, vérifiez que ce bloc est présent dans votre fichier `rules.mk` :
|
||||||
|
|
||||||
@@ -84,8 +84,8 @@ BOOTLOADER = caterina
|
|||||||
|
|
||||||
Flashers compatibles :
|
Flashers compatibles :
|
||||||
|
|
||||||
* [QMK Toolbox](https://github.com/qmk/qmk_toolbox/releases) (Interface graphique recomandée)
|
* [QMK Toolbox](https://github.com/qmk/qmk_toolbox/releases) (Interface graphique recommandée)
|
||||||
* [avrdude](http://www.nongnu.org/avrdude/) avec avr109 / `:avrdude` (Outil en ligne de commande recomandé)
|
* [avrdude](http://www.nongnu.org/avrdude/) avec avr109 / `:avrdude` (Outil en ligne de commande recommandé)
|
||||||
* [AVRDUDESS](https://github.com/zkemble/AVRDUDESS)
|
* [AVRDUDESS](https://github.com/zkemble/AVRDUDESS)
|
||||||
|
|
||||||
Séquence de flash :
|
Séquence de flash :
|
||||||
@@ -99,11 +99,14 @@ ou, utilisez :
|
|||||||
|
|
||||||
make <keyboard>:<keymap>:avrdude
|
make <keyboard>:<keymap>:avrdude
|
||||||
|
|
||||||
ou, si vous vous voulez flasher plusieurs claviers, utilisez la commande suivante :
|
#### Commandes Caterina
|
||||||
|
|
||||||
make <keyboard>:<keymap>:avrdude-loop
|
Il existe un certain nombre de commandes DFU que vous pouvez utiliser pour mettre à jour le firmware sur un périphérique DFU:
|
||||||
|
|
||||||
Quand vous avez fini de flasher vos claviers, vous aurez besoin d'utiliser Ctrl + C ou alors la touche ayant la fonction similaire sur votre OS pour sortir de la boucle.
|
* `: avrdude` - Il s’agit de l’option normale. Le script va attendre qu’un appareil Caterina soit disponible. Dès que c’est le cas, il flash le firmware. Il attendra de détecter un nouveau port COM pour le flasher.
|
||||||
|
* `: avrdude-loop` - Cela fonctionne de la même manière que`: avrdude`, mais une fois que chaque périphérique est flashé, il tentera de flasher à nouveau. Cela peut être utile pour flasher plusieurs claviers à la suite. _Cela implique de sortir manuellement de la boucle en appuyant sur Ctrl + C, Cmd + C ou un raccourci équivalent selon votre OS_
|
||||||
|
* `: avrdude-split-left` - Cela fonctionne de la même manière que la fonction (`: avrdude`). Toutefois, cela permet aussi de flasher le coté gauche de l'EEPROM des claviers splittés / divisés. C'est donc la méthode recommandée pour les claviers splittés avec Pro Micro.
|
||||||
|
* `: avrdude-split-right` - Cela fonctionne de la même manière que la fonction (`: avrdude`). Toutefois, cela permet aussi de flasher le coté droite de l'EEPROM des claviers splittés / divisés. C'est donc la méthode recommandée pour les claviers splittés avec Pro Micro.
|
||||||
|
|
||||||
## Halfkay
|
## Halfkay
|
||||||
|
|
||||||
@@ -169,7 +172,7 @@ Séquence de flash :
|
|||||||
|
|
||||||
## BootloadHID
|
## BootloadHID
|
||||||
|
|
||||||
BootloadHID est un bootloader pour les microcontroleurs AVR. L'utilitaire de téleversement ne demande pas de drivers au niveau du kernel et peut être lancé sans installer aucune DLLs.
|
BootloadHID est un bootloader pour les microcontrôleurs AVR. L'utilitaire de téleversement ne demande pas de drivers au niveau du kernel et peut être lancé sans installer aucune DLLs.
|
||||||
|
|
||||||
Pour vérifier la compatibilité avec le bootloader bootloadHID, vérifiez que ce bloc existe dans votre fichier `rules.mk` :
|
Pour vérifier la compatibilité avec le bootloader bootloadHID, vérifiez que ce bloc existe dans votre fichier `rules.mk` :
|
||||||
|
|
||||||
@@ -194,7 +197,7 @@ Séquence de flash
|
|||||||
|
|
||||||
1. Entrez dans le bootloader en utilisant l'une de ces méthodes :
|
1. Entrez dans le bootloader en utilisant l'une de ces méthodes :
|
||||||
* Pressez la touche du keycode `RESET` (Cela ne fonctionnera pas sur certains appareils).
|
* Pressez la touche du keycode `RESET` (Cela ne fonctionnera pas sur certains appareils).
|
||||||
* Verouillez la touche « Salt » tout en branchant le clavier (Géneralement ce principe est documenté dans le fichier readme du clavier)
|
* Verrouillez la touche « Salt » tout en branchant le clavier (Généralement ce principe est documenté dans le fichier readme du clavier)
|
||||||
2. Attendez que l'OS détecte l'appareil.
|
2. Attendez que l'OS détecte l'appareil.
|
||||||
3. Flasher le fichier .hex.
|
3. Flasher le fichier .hex.
|
||||||
4. Redémarrez l'appareil en mode « application ». Cela peut être fait automatiquement.
|
4. Redémarrez l'appareil en mode « application ». Cela peut être fait automatiquement.
|
||||||
@@ -224,13 +227,13 @@ Séquence pour flasher:
|
|||||||
3. Flasher un fichier `.bin`.h
|
3. Flasher un fichier `.bin`.h
|
||||||
* Vous allez recevoir un avertissement à propos de la signature DFU. Ignorez-la.
|
* Vous allez recevoir un avertissement à propos de la signature DFU. Ignorez-la.
|
||||||
4. Réinitialisez l'appareil en mode « application ». Cela peut être fait automatiquement.
|
4. Réinitialisez l'appareil en mode « application ». Cela peut être fait automatiquement.
|
||||||
* Si vous êtes en train de travailler en ligne de commande, par exemple avec un `make planck/rev6:default:dfu-util` alors soyez bien sur que l'argument `:leave` est passé aux argument DFU grâce à la variable `DFU_ARGS` à l'intérieur de votre fichier `rules.mk` (Ex : `DFU_ARGS = -d 0483:df11 -a 0 -s 0x08000000:leave`) afin que votre appareil redémarre après avoir été flashé.
|
* Si vous êtes en train de travailler en ligne de commande, par exemple avec un `make planck/rev6:default:dfu-util` alors soyez bien sur que l'argument `:leave` est passé aux arguments DFU grâce à la variable `DFU_ARGS` à l'intérieur de votre fichier `rules.mk` (Ex : `DFU_ARGS = -d 0483:df11 -a 0 -s 0x08000000:leave`) afin que votre appareil redémarre après avoir été flashé.
|
||||||
|
|
||||||
### Commandes STM32
|
### Commandes STM32
|
||||||
|
|
||||||
Il y a différentes commandes que vous pouvez utiliser pour flasher un firmware dans un appareil STM32 :
|
Il y a différentes commandes que vous pouvez utiliser pour flasher un firmware dans un appareil STM32 :
|
||||||
|
|
||||||
* `:dfu-util` - La commande par défaut pour flasher un appareil STM32.
|
* `:dfu-util` - C'est l'option standard pour flasher un appareil STM32. Le script attendra qu'un bootloader STM32 soit présent.
|
||||||
* `:dfu-util-split-left` - Permet de flasher un firmware normalement, tout comme l'option précedente mais permet de configurer le coté gauche des paramètres EEPROM sur un clavier scindé.
|
* `:dfu-util-split-left` - Permet de flasher un firmware normalement, tout comme l'option précédente mais permet de configurer le côté gauche des paramètres EEPROM sur un clavier scindé.
|
||||||
* `:dfu-util-split-right` - Permet de flasher un firmware normalement, tout comme l'option précedente mais permet de configurer le coté droit des paramètres EEPROM sur un clavier scindé.
|
* `:dfu-util-split-right` - Permet de flasher un firmware normalement, tout comme l'option précédente mais permet de configurer le côté droit des paramètres EEPROM sur un clavier scindé.
|
||||||
* `:st-link-cli` - Cela permet de flasher le firmware avec l'utilitaire en ligne de commande ST-LINK's plutôt que d'utiliser dfu-util.
|
* `:st-link-cli` - Cela permet de flasher le firmware avec l'utilitaire en ligne de commande ST-LINK's plutôt que d'utiliser dfu-util.
|
||||||
@@ -4,7 +4,7 @@ Il y a beaucoup de ressources pour trouver de l'aide avec QMK.
|
|||||||
|
|
||||||
## Chat temps-réel
|
## Chat temps-réel
|
||||||
|
|
||||||
Vous trouverez des développeurs QMK et des utilisateurs sur notre [Serveur Discord](https://discord.gg/Uq7gcHh) principal. Il y a des canaux spécifiques dans le serveurs pour discuter des firmware, toolbox, hardware et configurateurs.
|
Vous trouverez des développeurs QMK et des utilisateurs sur notre [Serveur Discord](https://discord.gg/Uq7gcHh) principal. Il y a des canaux spécifiques dans le serveur pour discuter des firmwares, toolbox, hardware et configurateurs.
|
||||||
|
|
||||||
## Sous-Reddit OLKB
|
## Sous-Reddit OLKB
|
||||||
|
|
||||||
@@ -12,4 +12,4 @@ Le forum officiel de QMK est [/r/olkb](https://reddit.com/r/olkb) sur [reddit.co
|
|||||||
|
|
||||||
## Tickets GitHub
|
## Tickets GitHub
|
||||||
|
|
||||||
Vous pouvez ouvrir un [ticket sur GitHub](https://github.com/qmk/qmk_firmware/issues). Ceci est spécialement pratique lorsque votre problème demande une discussion long terme ou un débugage.
|
Vous pouvez ouvrir un [ticket sur GitHub](https://github.com/qmk/qmk_firmware/issues). Ceci est spécialement pratique lorsque votre problème demande une discussion sur le long terme ou un débugage.
|
||||||
@@ -8,11 +8,11 @@ Commencez par la [page GitHub de QMK](https://github.com/qmk/qmk_firmware), et v
|
|||||||
|
|
||||||

|

|
||||||
|
|
||||||
Si vous faites partie d'une organisation, vous aurez besoin de savoir quel compte utiliser pour le fork. Dans la plupart des cas, vous voudrez créer le fork dans votre compte personnel. Une fois le fork complet (cela peut quelque fois prendre un peu de temps), appuyez sur le bouton "Clone or download":
|
Si vous faites partie d'une organisation, vous aurez besoin de savoir quel compte utiliser pour le fork. Dans la plupart des cas, vous voudrez créer le fork dans votre compte personnel. Une fois le fork complet (cela peut quelques fois prendre un peu de temps), appuyez sur le bouton "Clone or download":
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
Faites attention à sélectionner "HTTPS", et sélectionnez le liens et copiez-le:
|
Faites attention à sélectionner "HTTPS", et sélectionnez le lien et copiez-le:
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
@@ -48,7 +48,7 @@ To https://github.com/whoeveryouare/qmk_firmware.git
|
|||||||
+ 20043e64...7da94ac5 master -> master
|
+ 20043e64...7da94ac5 master -> master
|
||||||
```
|
```
|
||||||
|
|
||||||
Vos changements existent maintenant dans votre fork sur GitHub. Si vous allez à cete adresse (`https://github.com/<whoeveryouare>/qmk_firmware`), vous pouvez créer un nouveau "Pull Request" en cliquant sur ce bouton:
|
Vos changements existent maintenant dans votre fork sur GitHub. Si vous allez à cette adresse (`https://github.com/<whoeveryouare>/qmk_firmware`), vous pouvez créer un nouveau "Pull Request" en cliquant sur ce bouton:
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
|
|||||||
@@ -43,7 +43,7 @@ Le fichier `config.h` peut être mis à 3 endroits:
|
|||||||
* userspace (`/users/<user>/config.h`)
|
* userspace (`/users/<user>/config.h`)
|
||||||
* keymap (`/keyboards/<keyboard>/keymaps/<keymap>/config.h`)
|
* keymap (`/keyboards/<keyboard>/keymaps/<keymap>/config.h`)
|
||||||
|
|
||||||
Le système de compilation cherche automatiquement les fichiers de configuration dans l'ordre au dessus. Si vous souhaitez surcharger une configuration définie par un `config.h` précédent, vous devrez d'abord ajouter le code suivant.
|
Le système de compilation cherche automatiquement les fichiers de configuration dans l'ordre au-dessus. Si vous souhaitez surcharger une configuration définie par un `config.h` précédent, vous devrez d'abord ajouter le code suivant.
|
||||||
|
|
||||||
```
|
```
|
||||||
#pragma once
|
#pragma once
|
||||||
@@ -51,7 +51,7 @@ Le système de compilation cherche automatiquement les fichiers de configuration
|
|||||||
|
|
||||||
Ensuite, pour surcharger l'option du fichier `config.h` précédent, vous devez `#undef` puis `#define` l'option à nouveau.
|
Ensuite, pour surcharger l'option du fichier `config.h` précédent, vous devez `#undef` puis `#define` l'option à nouveau.
|
||||||
|
|
||||||
Voici à quoi l'ensemble du code resemble une fois regroupé:
|
Voici à quoi l'ensemble du code ressemble une fois regroupé:
|
||||||
|
|
||||||
```
|
```
|
||||||
#pragma once
|
#pragma once
|
||||||
|
|||||||
@@ -11,7 +11,7 @@ Ce document suppose les choses suivantes:
|
|||||||
|
|
||||||
## La branche master de votre fork: Mettre à jour souvent, ne jamais commit
|
## La branche master de votre fork: Mettre à jour souvent, ne jamais commit
|
||||||
|
|
||||||
Il est hautement recommandé pour le développement de QMK, peu importe ce qui est fait ou où, de garder votre branche `master` à jour, mais de ne ***jamais*** commit dessus. A la place, faites tous vos changement dans une branche de développement et crééz des "pull requests" de votre branche lorsque vous développez.
|
Il est hautement recommandé pour le développement de QMK, peu importe ce qui est fait ou où, de garder votre branche `master` à jour, mais de ne ***jamais*** commit dessus. A la place, faites tous vos changements dans une branche de développement et crééz des "pull requests" de votre branche lorsque vous développez.
|
||||||
|
|
||||||
Pour réduire les chances de conflits de fusion (merge) — des cas où deux ou plus d'utilisateurs ont édité la même section d'un fichier en parallèle — gardez votre branche `master` relativement à jour et démarrez chaque nouveau développement en créant une nouvelle branche.
|
Pour réduire les chances de conflits de fusion (merge) — des cas où deux ou plus d'utilisateurs ont édité la même section d'un fichier en parallèle — gardez votre branche `master` relativement à jour et démarrez chaque nouveau développement en créant une nouvelle branche.
|
||||||
|
|
||||||
@@ -44,7 +44,7 @@ git pull upstream master
|
|||||||
git push origin master
|
git push origin master
|
||||||
```
|
```
|
||||||
|
|
||||||
Cela vous change la branche courante en master, synchronise les données de réferences du dépôt QMK vers votre ordinateur. La commande pull tire les données de réferences vers votre branche courante puis les y téleverse. La commande push permet de pousser la branche courante (master) vers votre fork github.
|
Cela vous change la branche courante en master, synchronise les données de références du dépôt QMK vers votre ordinateur. La commande pull tire les données de références vers votre branche courante puis les y téleverse. La commande push permet de pousser la branche courante (master) vers votre fork github.
|
||||||
|
|
||||||
### Faire des changements
|
### Faire des changements
|
||||||
|
|
||||||
@@ -55,11 +55,11 @@ git checkout -b dev_branch
|
|||||||
git push --set-upstream origin dev_branch
|
git push --set-upstream origin dev_branch
|
||||||
```
|
```
|
||||||
|
|
||||||
Ceci crée une branche nommée `dev_branch`, bascule vers cette branche, et ensuite sauvegarde cette nouvelle branche vers votre fork. L'argument `--set-upstream` demande à git d'utiliser votre fork et la branche `dev_branch` à chaque fois que vous utilisez `git push` ou `git pull` depuis cette branche. Vous ne devez l'utiliser que pour le premier "push", après celà, vous pouvez utiliser simplement `git push` ou `git pull`, sans le reste des arguments.
|
Ceci crée une branche nommée `dev_branch`, bascule vers cette branche, et ensuite sauvegarde cette nouvelle branche vers votre fork. L'argument `--set-upstream` demande à git d'utiliser votre fork et la branche `dev_branch` à chaque fois que vous utilisez `git push` ou `git pull` depuis cette branche. Vous ne devez l'utiliser que pour le premier "push", après cela, vous pouvez utiliser simplement `git push` ou `git pull`, sans le reste des arguments.
|
||||||
|
|
||||||
!> Avec `git push`, vous pouvez utiliser `-u` à la place de `--set-upstream` — `-u` est un alias pour `--set-upstream`.
|
!> Avec `git push`, vous pouvez utiliser `-u` à la place de `--set-upstream` — `-u` est un alias pour `--set-upstream`.
|
||||||
|
|
||||||
Vous pouvez appeler votre branche à peu prêt comme vous voulez, toutefois il est recommandé d'utiliser un nom qui est lié aux changements que vous allez faire.
|
Vous pouvez appeler votre branche à peu près comme vous voulez, toutefois il est recommandé d'utiliser un nom qui est lié aux changements que vous allez faire.
|
||||||
|
|
||||||
Par défaut, `git checkout -b` va faire de la branche actuelle la branche de base de votre nouvelle branche. Vous pouvez définir la base de votre nouvelle branche comme étant n'importe quelle branche existante qui n'est pas la courante en utilisant la commande:
|
Par défaut, `git checkout -b` va faire de la branche actuelle la branche de base de votre nouvelle branche. Vous pouvez définir la base de votre nouvelle branche comme étant n'importe quelle branche existante qui n'est pas la courante en utilisant la commande:
|
||||||
|
|
||||||
@@ -76,11 +76,11 @@ git commit -m "My commit message."
|
|||||||
|
|
||||||
`git add` ajoute les fichiers qui ont été changés dans la *zone de staging* de Git, qui est sa "zone de chargement". Elle contient tous les changements qui vont être *validés* (committed) par `git commit`, qui sauvegarde les changements vers le dépôt. Utilisez des messages de validation descriptifs afin que vous puissiez savoir ce qui a changé d'un coup d'oeil.
|
`git add` ajoute les fichiers qui ont été changés dans la *zone de staging* de Git, qui est sa "zone de chargement". Elle contient tous les changements qui vont être *validés* (committed) par `git commit`, qui sauvegarde les changements vers le dépôt. Utilisez des messages de validation descriptifs afin que vous puissiez savoir ce qui a changé d'un coup d'oeil.
|
||||||
|
|
||||||
!> Si vous changez beaucoup de fichiers, mais tous les fichiers font partie du même changement, vous pouvez utiliser `git add .` pour ajouter tous les fichiers changés dans le répertoire courant, plutôt que d'avoir à ajouter chaque fichiers individuellement.
|
!> Si vous changez beaucoup de fichiers, mais tous les fichiers font partie du même changement, vous pouvez utiliser `git add .` pour ajouter tous les fichiers changés dans le répertoire courant, plutôt que d'avoir à ajouter chaque fichier individuellement.
|
||||||
|
|
||||||
### Publier Vos Changements
|
### Publier Vos Changements
|
||||||
|
|
||||||
La dernière étape est de pousser vos changements vers votre fork. pour se faire, entrez `git push`. Git publie maintenant l'état courant de `dev_branch` vers votre fork.
|
La dernière étape est de pousser vos changements vers votre fork. Pour ce faire, entrez `git push`. Git publie maintenant l'état courant de `dev_branch` vers votre fork.
|
||||||
|
|
||||||
## Résoudre Les Conflits De Merge
|
## Résoudre Les Conflits De Merge
|
||||||
|
|
||||||
@@ -112,7 +112,7 @@ Maintenant que l'état actuel de la branche courante et la branche upstream sont
|
|||||||
git rebase upstream/master
|
git rebase upstream/master
|
||||||
```
|
```
|
||||||
|
|
||||||
Ceci dit à Git d'annuler les commits de la branche courrante puis de les réappliquer sur la branche master de QMK.
|
Ceci dit à Git d'annuler les commits de la branche courante puis de les réappliquer sur la branche master de QMK.
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
$ git rebase upstream/master
|
$ git rebase upstream/master
|
||||||
@@ -133,7 +133,7 @@ You can instead skip this commit: run "git rebase --skip".
|
|||||||
To abort and get back to the state before "git rebase", run "git rebase --abort".
|
To abort and get back to the state before "git rebase", run "git rebase --abort".
|
||||||
```
|
```
|
||||||
|
|
||||||
Ceci nous dit que nous avons un conflit de merge, et nous donne le nom du fichier en conflit. Ouvez le fichier conflictuel dans votre éditeur de texte et, quelque part dans le fichier, vous trouverez quelque chose comme ça:
|
Ceci nous dit que nous avons un conflit de merge, et nous donne le nom du fichier en conflit. Ouvrez le fichier conflictuel dans votre éditeur de texte et, quelque part dans le fichier, vous trouverez quelque chose comme ça:
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
<<<<<<< HEAD
|
<<<<<<< HEAD
|
||||||
|
|||||||
@@ -20,11 +20,11 @@ Je vais le répéter, parce que c'est important
|
|||||||
|
|
||||||
!> **FAITES ATTENTION A UTILISER LA BONNE VERSION !**
|
!> **FAITES ATTENTION A UTILISER LA BONNE VERSION !**
|
||||||
|
|
||||||
Si votre clavier est annoncé comme fonctionnant grâce à QMK mais n'est pas dans la liste, il y a des chances que le développeur ne l'ait pas encore fait, ou que nous n'avons pas encore eu le temps de le merger. Ajoutez un problème (issue) sur [qmk_firmware](https://github.com/qmk/qmk_firmware/issues) demandant le support de votre clavier, s'il n'y a pas de [Pull Request](https://github.com/qmk/qmk_firmware/pulls?q=is%3Aopen+is%3Apr+label%3Akeyboard) ouvert pour lui. Il y a aussi des clavier alimentés par QMK qui sont sur le compte GitHub du fabriquant, il est bon de le vérifier aussi.
|
Si votre clavier est annoncé comme fonctionnant grâce à QMK mais n'est pas dans la liste, il y a des chances que le développeur ne l'ait pas encore fait, ou que nous n'avons pas encore eu le temps de le merger. Ajoutez un problème (issue) sur [qmk_firmware](https://github.com/qmk/qmk_firmware/issues) demandant le support de votre clavier, s'il n'y a pas de [Pull Request](https://github.com/qmk/qmk_firmware/pulls?q=is%3Aopen+is%3Apr+label%3Akeyboard) ouvert pour lui. Il y a aussi des claviers alimentés par QMK qui sont sur le compte GitHub du fabricant, il est bon de le vérifier aussi.
|
||||||
|
|
||||||
## Sélectionner la disposition de votre clavier
|
## Sélectionner la disposition de votre clavier
|
||||||
|
|
||||||
Choisissez la disposition (layout) qui représente le mieux la keymap que vous voulez créer. Certains clavier n'ont pas encore assez de dispositions ou des dispositions incorrectes. Ils seront supportés dans le future.
|
Choisissez la disposition (layout) qui représente le mieux la keymap que vous voulez créer. Certains claviers n'ont pas encore assez de dispositions ou des dispositions incorrectes. Ils seront supportés dans le future.
|
||||||
|
|
||||||
## Nom de la Keymap
|
## Nom de la Keymap
|
||||||
|
|
||||||
|
|||||||
@@ -78,7 +78,23 @@ Appuyez sur le boutton `Flash` dans QMK Toolbox. Vous verrez un résultat simila
|
|||||||
|
|
||||||
## Flashez votre clavier à l'aide de la ligne de commande
|
## Flashez votre clavier à l'aide de la ligne de commande
|
||||||
|
|
||||||
La première chose que vous devez savoir c'est quel bootloader utilise votre clavier. Il y a quatre bootloaders principaux. Pro-Micro et les clones, utilisent CATERINA, les Teensy utilisent Halfkay, les OLKB utilisent QMK-DFU et les autres chips atmega32u4 utilisent DFU.
|
C'est désormais relativement simple. Lorsque vous êtes prêt à compiler et à flasher votre firmware, ouvrez la fenêtre de votre terminal et exécutez la commande de build :
|
||||||
|
|
||||||
|
make <my_keyboard>:<my_keymap>:flash
|
||||||
|
|
||||||
|
Par exemple, si votre keymap s'appelle "xyverz" et que vous fabriquez une keymap pour un clavier `planck` de version `rev5` vous devrez utiliser cette commande:
|
||||||
|
|
||||||
|
make planck/rev5:xyverz:flash
|
||||||
|
|
||||||
|
La commande va vérifier la configuration du clavier, puis tentera de le flasher en fonction du bootloader (chargeur d’amorçage) spécifié. Cela signifie que vous n'avez pas besoin de savoir quel bootloader votre clavier utilise. Exécutez simplement la commande et laissez-le faire le gros du travail.
|
||||||
|
|
||||||
|
Cependant, tout dépend du bootloader qui est installé sur le clavier. Si cette information n’est pas configurée ou si vous tentez de flasher un clavier qui ne permet pas d’être flashé alors vous obtiendrez cette erreur :
|
||||||
|
|
||||||
|
WARNING: This board's bootloader is not specified or is not supported by the ":flash" target at this time.
|
||||||
|
|
||||||
|
Dans ce cas, vous devrez choisir le bootloader.
|
||||||
|
|
||||||
|
Il y a cinq bootloaders principaux. Les Pro-Micro et les clones utilisent Caterina, les Teensy utilisent Halfkay, les claviers AVR d’OLKB utilisent QMK-DFU, certains controleurs atmega32u4 utilisent DFU et la plupart des controlleurs ARM utilisent ARM DFU.
|
||||||
|
|
||||||
Vous pouvez trouver plus d'information à propos des bootloaders sur la page [Instructions de flash et information sur le Bootloader](flashing.md).
|
Vous pouvez trouver plus d'information à propos des bootloaders sur la page [Instructions de flash et information sur le Bootloader](flashing.md).
|
||||||
|
|
||||||
@@ -104,7 +120,7 @@ Checking file size of planck_rev5_xyverz.hex
|
|||||||
* File size is fine - 18574/28672
|
* File size is fine - 18574/28672
|
||||||
```
|
```
|
||||||
|
|
||||||
Une fois arrivé à ce stade, le script de compilation va checher le bootloader DFU toutes les 5 secondes. Il va répéter les messages suivants jusqu'à ce que l'appareil soit trouvé ou que vous l'annuliez.
|
Une fois arrivé à ce stade, le script de compilation va chercher le bootloader DFU toutes les 5 secondes. Il va répéter les messages suivants jusqu'à ce que l'appareil soit trouvé ou que vous l'annuliez.
|
||||||
|
|
||||||
dfu-programmer: no device present.
|
dfu-programmer: no device present.
|
||||||
Error: Bootloader not found. Trying again in 5s.
|
Error: Bootloader not found. Trying again in 5s.
|
||||||
@@ -127,7 +143,7 @@ Une fois terminé, vous devrez mettre à zéro le contrôleur. Vous allez voir u
|
|||||||
>>> dfu-programmer atmega32u4 reset
|
>>> dfu-programmer atmega32u4 reset
|
||||||
```
|
```
|
||||||
|
|
||||||
?> Si vous avez des soucis concerant ceci - comme par exemple `dfu-programmer: no device present` - merci de regarder [Foires Aux Questions de Compilation](faq_build.md).
|
?> Si vous avez des soucis concernant ceci - par exemple `dfu-programmer: no device present` - merci de regarder [Foires Aux Questions de Compilation](faq_build.md).
|
||||||
|
|
||||||
#### Commandes DFU
|
#### Commandes DFU
|
||||||
|
|
||||||
@@ -158,7 +174,7 @@ Checking file size of lets_split_rev2_xyverz.hex
|
|||||||
Detecting USB port, reset your controller now..............
|
Detecting USB port, reset your controller now..............
|
||||||
```
|
```
|
||||||
|
|
||||||
Une fois ceci fait, réinitialisez votre board et le script va détecter et flasher le firmware. La sortie devrait ressember à quelque chose comme ça:
|
Une fois ceci fait, réinitialisez votre board et le script va détecter et flasher le firmware. La sortie devrait ressembler à quelque chose comme ça:
|
||||||
|
|
||||||
```
|
```
|
||||||
Detected controller on USB port at /dev/ttyS15
|
Detected controller on USB port at /dev/ttyS15
|
||||||
@@ -203,15 +219,18 @@ avrdude.exe: safemode: Fuses OK (E:CB, H:D8, L:FF)
|
|||||||
avrdude.exe done. Thank you.
|
avrdude.exe done. Thank you.
|
||||||
```
|
```
|
||||||
|
|
||||||
Si vous avez un soucis, essayez de faire ceci:
|
Si vous avez un souci, essayez de faire ceci:
|
||||||
|
|
||||||
sudo make <my_keyboard>:<my_keymap>:avrdude
|
sudo make <my_keyboard>:<my_keymap>:avrdude
|
||||||
|
|
||||||
En addition, si vous voulez flasher plusieurs boards, utilisez la commande suivante:
|
#### Commandes Caterina
|
||||||
|
|
||||||
make <keyboard>:<keymap>:avrdude-loop
|
Il existe un certain nombre de commandes DFU que vous pouvez utiliser pour mettre à jour le firmware sur un périphérique DFU:
|
||||||
|
|
||||||
Une fois que vous avez terminé de flasher des boards, vous devrez appuyer sur Ctrl + C, ou les touches correspondantes pour votre système d'exploitation pour arrêter la boucle.
|
* `: avrdude` - Il s’agit de l’option normale. Elle attend qu’un appareil Caterina soit disponible, puis tente de flasher le firmware. Il attendra de détecter un autre port COM, puis il flashera à nouveau.
|
||||||
|
* `: avrdude-loop` - Cela fonctionne de la même manière que `: avrdude`, mais une fois que chaque périphérique est flashé, il tentera de flasher à nouveau. Cela peut être utile pour flasher plusieurs claviers à la suite. _Cela implique de sortir manuellement de la boucle en appuyant sur Ctrl + C, Cmd + C ou un raccourci équivalent selon votre OS_
|
||||||
|
* `: avrdude-split-left` - Cela fonctionne de la même manière que la fonction (`: avrdude`). Toutefois, cela permet aussi de flasher le coté gauche de l'EEPROM des claviers splittés / divisés. C'est donc la méthode recommandée pour les claviers splittés avec Pro Micro.
|
||||||
|
* `: avrdude-split-right` - Cela fonctionne de la même manière que la fonction (`: avrdude`). Toutefois, cela permet aussi de flasher le coté droite de l'EEPROM des claviers splittés / divisés. C'est donc la méthode recommandée pour les claviers splittés avec Pro Micro.
|
||||||
|
|
||||||
### HalfKay
|
### HalfKay
|
||||||
|
|
||||||
@@ -246,45 +265,9 @@ Programming.....................................................................
|
|||||||
Booting
|
Booting
|
||||||
```
|
```
|
||||||
|
|
||||||
### BootloadHID
|
|
||||||
|
|
||||||
Pour les boards basée sur Bootmapper Client(BMC)/bootloadHID/ATmega32A, une fois prêt à compiler et flasher le firmware, ouvrez votre fenêtre de terminal et lancez la commande suivante:
|
|
||||||
|
|
||||||
make <my_keyboard>:<my_keymap>:bootloaderHID
|
|
||||||
|
|
||||||
Par exemple, si votre keymap s'appelle "xyverz" et que vous compilez une keymap pour un jj40, vous utilisez cette commande:
|
|
||||||
|
|
||||||
make jj40:xyverz:bootloaderHID
|
|
||||||
|
|
||||||
Une fois le firmware compilé, vous aurez cette sortie:
|
|
||||||
|
|
||||||
```
|
|
||||||
Linking: .build/jj40_default.elf [OK]
|
|
||||||
Creating load file for flashing: .build/jj40_default.hex [OK]
|
|
||||||
Copying jj40_default.hex to qmk_firmware folder [OK]
|
|
||||||
Checking file size of jj40_default.hex [OK]
|
|
||||||
* The firmware size is fine - 21920/28672 (6752 bytes free)
|
|
||||||
```
|
|
||||||
|
|
||||||
A ce stade, le script de build va chercher le bootloader DFU toutes les 5 secondes. Il va répéter la sortie suivante jusqu'à ce que le dispositif soit trouvé ou que vous l'annuliez.
|
|
||||||
|
|
||||||
```
|
|
||||||
Error opening HIDBoot device: The specified device was not found
|
|
||||||
Trying again in 5s.
|
|
||||||
```
|
|
||||||
|
|
||||||
Une fois ce résultat atteint, réinitialisez le contrôleur. Il devrait afficher le résultat suivant:
|
|
||||||
|
|
||||||
```
|
|
||||||
Page size = 128 (0x80)
|
|
||||||
Device size = 32768 (0x8000); 30720 bytes remaining
|
|
||||||
Uploading 22016 (0x5600) bytes starting at 0 (0x0)
|
|
||||||
0x05580 ... 0x05600
|
|
||||||
```
|
|
||||||
|
|
||||||
### STM32 (ARM)
|
### STM32 (ARM)
|
||||||
|
|
||||||
Pour la majorité des boards ARM (incluant les Proton C, Planck Rev 6, et Preonic Rev 3), lorsque vous êtes prêt à compiler et flasher votre firmware,ouvrez la fenêtre de terminal et lancez la commande de compilation:
|
Pour la majorité des boards ARM (incluant les Proton C, Planck Rev 6, et Preonic Rev 3), lorsque vous êtes prêt à compiler et flasher votre firmware, ouvrez la fenêtre de terminal et lancez la commande de compilation:
|
||||||
|
|
||||||
make <my_keyboard>:<my_keymap>:dfu-util
|
make <my_keyboard>:<my_keymap>:dfu-util
|
||||||
|
|
||||||
@@ -336,10 +319,46 @@ Transitioning to dfuMANIFEST state
|
|||||||
|
|
||||||
Il y aun certain nombre de commandes du DFU que vous pouvez utiliser pour flasher un firmware sur un device STM32:
|
Il y aun certain nombre de commandes du DFU que vous pouvez utiliser pour flasher un firmware sur un device STM32:
|
||||||
|
|
||||||
* `:dfu-util` - C'est l'option standard pour flasher un appareil STM32.
|
* `:dfu-util` - C'est l'option standard pour flasher un appareil STM32. Elle attendra qu'un bootloader STM32 soit présent et tentera de l’utiliser.
|
||||||
* `:dfu-util-wait` - Ceci fonctionne comme la commande standard, mais permet de d'avoir une pause (configurable( de 10 secondes avant de flasher le fimrware. Vous pouvez utiliser `TIME_DELAY=20` à la ligne de commande pour changer le délai.
|
|
||||||
* `:dfu-util-left` - Ceci flasher le firmware standard, comme la commande standard (`:dfu-util`). Toutefois, elle flasher aussi les fichiers EEPROM du "côté gauche" pour les claviers scindés.
|
* `:dfu-util-left` - Ceci flasher le firmware standard, comme la commande standard (`:dfu-util`). Toutefois, elle flasher aussi les fichiers EEPROM du "côté gauche" pour les claviers scindés.
|
||||||
* `:dfu-util-right` - Ceci flash le firmware standard, comme la commande standard (`:dfu-util`). Toutefois, elle flash aussi les fichiers EEPROM du "côté droit" pour les claviers scindés.
|
* `:dfu-util-right` - Ceci flash le firmware standard, comme la commande standard (`:dfu-util`). Toutefois, elle flash aussi les fichiers EEPROM du "côté droit" pour les claviers scindés.
|
||||||
|
* `:st-link-cli` - Cela permet de flasher le firmware avec l'utilitaire en ligne de commande ST-LINK's plutôt que d'utiliser dfu-util.
|
||||||
|
|
||||||
|
### BootloadHID
|
||||||
|
|
||||||
|
Pour les claviers basés sur Bootmapper Client(BMC)/bootloadHID/ATmega32A, si vous êtes prêts à compiler et flasher le firmware, ouvrez votre fenêtre de terminal et lancez la commande suivante :
|
||||||
|
|
||||||
|
make <my_keyboard>:<my_keymap>:bootloaderHID
|
||||||
|
|
||||||
|
Par exemple, si votre keymap s'appelle "xyverz" et que vous compilez une keymap pour un jj40, utilisez cette commande:
|
||||||
|
|
||||||
|
make jj40:xyverz:bootloaderHID
|
||||||
|
|
||||||
|
Une fois le firmware compilé, vous aurez cette sortie:
|
||||||
|
|
||||||
|
```
|
||||||
|
Linking: .build/jj40_default.elf [OK]
|
||||||
|
Creating load file for flashing: .build/jj40_default.hex [OK]
|
||||||
|
Copying jj40_default.hex to qmk_firmware folder [OK]
|
||||||
|
Checking file size of jj40_default.hex [OK]
|
||||||
|
* The firmware size is fine - 21920/28672 (6752 bytes free)
|
||||||
|
```
|
||||||
|
|
||||||
|
A ce stade, le script de build va chercher le bootloader DFU toutes les 5 secondes. Il répétera l ’affichage de ce message jusqu'à ce que l’appareil soit trouvé ou que vous annuliez l'opération```
|
||||||
|
|
||||||
|
```
|
||||||
|
Error opening HIDBoot device: The specified device was not found
|
||||||
|
Trying again in 5s.
|
||||||
|
```
|
||||||
|
|
||||||
|
Une fois ce résultat obtenu, réinitialisez le contrôleur. Le résultat suivant devrait s’afficher :
|
||||||
|
|
||||||
|
```
|
||||||
|
Page size = 128 (0x80)
|
||||||
|
Device size = 32768 (0x8000); 30720 bytes remaining
|
||||||
|
Uploading 22016 (0x5600) bytes starting at 0 (0x0)
|
||||||
|
0x05580 ... 0x05600
|
||||||
|
```
|
||||||
|
|
||||||
## Faites l'essai!
|
## Faites l'essai!
|
||||||
|
|
||||||
|
|||||||
@@ -2,19 +2,19 @@
|
|||||||
|
|
||||||
Votre clavier d'ordinateur contient un processeur, proche de celui dans votre ordinateur. Ce processeur exécute un logiciel responsable de détecter les touches appuyées et envoie des rapports à propos de l'état du clavier lorsque les touches sont appuyées et relâchées. QMK prend le rôle de ce logiciel, détectant les appuis des boutons et passant cette information à l'ordinateur hôte. Lorsque vous construisez votre keymap customisée, vous créez l'équivalent d'un programme exécutable pour votre clavier.
|
Votre clavier d'ordinateur contient un processeur, proche de celui dans votre ordinateur. Ce processeur exécute un logiciel responsable de détecter les touches appuyées et envoie des rapports à propos de l'état du clavier lorsque les touches sont appuyées et relâchées. QMK prend le rôle de ce logiciel, détectant les appuis des boutons et passant cette information à l'ordinateur hôte. Lorsque vous construisez votre keymap customisée, vous créez l'équivalent d'un programme exécutable pour votre clavier.
|
||||||
|
|
||||||
QMK essaie de rendre les choses simples faciles, et les choses difficiles possibles. Vous n'avez pas à savoir programmer pour créer des keymaps puissantes - vous devez seulement suivre quelques rêgles de syntaxe simples.
|
QMK essaie de rendre les choses simples faciles, et les choses difficiles possibles. Vous n'avez pas à savoir programmer pour créer des keymaps puissantes - vous devez seulement suivre quelques règles de syntaxe simples.
|
||||||
|
|
||||||
# Guide de démarrage
|
# Guide de démarrage
|
||||||
|
|
||||||
Avant de pouvoir construire des keymaps, vous devez installer quelques logiciels et configurer votre environnement de compilation. Ceci n'a besoin d'être fait seulement une fois, peu importe le nombre de clavier pour lesquels vous compter compiler un firmware.
|
Avant de pouvoir construire des keymaps, vous devez installer quelques logiciels et configurer votre environnement de compilation. Ceci n'a besoin d'être fait seulement une fois, peu importe le nombre de clavier pour lesquels vous compter compiler un firmware.
|
||||||
|
|
||||||
Si vous préférez une approche plus proche d'une interface graphique, considérez utiliser l'outil en ligne [QMK Configurator](https://config.qmk.fm). Référez vous à [Construire votre premier firmware en utilisant l'interface graphique en ligne](newbs_building_firmware_configurator.md).
|
Si vous préférez une approche plus proche d'une interface graphique, considérez utiliser l'outil en ligne [QMK Configurator](https://config.qmk.fm). Référez-vous à [Construire votre premier firmware en utilisant l'interface graphique en ligne](newbs_building_firmware_configurator.md).
|
||||||
|
|
||||||
## Logiciels à télécharger
|
## Logiciels à télécharger
|
||||||
|
|
||||||
### Editeur de texte
|
### Editeur de texte
|
||||||
|
|
||||||
Vous allez avoir besoin d'un programme qui peut éditer et sauvegarder des fichier **plain text**. Si vous êtes sur Windows, vous pouvez utiliser notepad et sur Linux vous pouvez utiliser gedit. Ces deux options sont des éditeurs de texte simples mais fonctionnels. Sur macOS, faites attention avec l'application par défaut TextEdit: elle ne sauvegardera pas les fichiers en mode "plain text" sauf si vous sélectionnez explicitement _Make Plain Text_ à partir du menu _Format_.
|
Vous allez avoir besoin d'un programme qui peut éditer et sauvegarder des fichiers **plain text**. Si vous êtes sur Windows, vous pouvez utiliser notepad et sur Linux vous pouvez utiliser gedit. Ces deux options sont des éditeurs de texte simples mais fonctionnels. Sur macOS, faites attention avec l'application par défaut TextEdit: elle ne sauvegardera pas les fichiers en mode "plain text" sauf si vous sélectionnez explicitement _Make Plain Text_ à partir du menu _Format_.
|
||||||
|
|
||||||
Vous pouvez aussi télécharger et installer un éditeur de texte dédié comme [Sublime Text](https://www.sublimetext.com/) ou [VS Code](https://code.visualstudio.com/). C'est probablement la meilleure solution peu importe la plateforme car ce sont des programmes conçus spécifiquement pour éditer du code.
|
Vous pouvez aussi télécharger et installer un éditeur de texte dédié comme [Sublime Text](https://www.sublimetext.com/) ou [VS Code](https://code.visualstudio.com/). C'est probablement la meilleure solution peu importe la plateforme car ce sont des programmes conçus spécifiquement pour éditer du code.
|
||||||
|
|
||||||
@@ -33,7 +33,7 @@ QMK Toolbox est un programme graphique optionnel pour Windows et macOS qui perme
|
|||||||
|
|
||||||
Nous avons essayé de rendre QMK aussi simple que possible à configurer. Vous avez uniquement à préparer votre environnment Linux ou Unix et laisser QMK installer le reste.
|
Nous avons essayé de rendre QMK aussi simple que possible à configurer. Vous avez uniquement à préparer votre environnment Linux ou Unix et laisser QMK installer le reste.
|
||||||
|
|
||||||
?> Si vous n'avez jamais travailé avec la lignde commande Linux/Unix, il y a un certain nombre de concepts basiques et de commandes que vous devriez apprendre. Ces ressources vous apprendrons suffisemment pour travailler avec QMK:<br>
|
?> Si vous n'avez jamais travaillé avec la ligne de commande Linux/Unix, il y a un certain nombre de concepts basiques et de commandes que vous devriez apprendre. Ces ressources vous apprendrons suffisemment pour travailler avec QMK:<br>
|
||||||
[Commandes Linux à savoir](https://www.guru99.com/must-know-linux-commands.html)<br>
|
[Commandes Linux à savoir](https://www.guru99.com/must-know-linux-commands.html)<br>
|
||||||
[Commandes Unix de base](https://www.tjhsst.edu/~dhyatt/superap/unixcmd.html)
|
[Commandes Unix de base](https://www.tjhsst.edu/~dhyatt/superap/unixcmd.html)
|
||||||
|
|
||||||
@@ -49,7 +49,7 @@ Vous devez installer MSYS2 et Git.
|
|||||||
|
|
||||||
Vous devez installer Homebew. Suivez les instructions sur la [page de Homebrew](https://brew.sh).
|
Vous devez installer Homebew. Suivez les instructions sur la [page de Homebrew](https://brew.sh).
|
||||||
|
|
||||||
Une fois Homebrew installé, continuez avec _Configurer QMK_. Dans cete étape, nous lancerons un script qui va installer d'autres paquets.
|
Une fois Homebrew installé, continuez avec _Configurer QMK_. Dans cette étape, nous lancerons un script qui va installer d'autres paquets.
|
||||||
|
|
||||||
### Linux
|
### Linux
|
||||||
|
|
||||||
|
|||||||
@@ -4,7 +4,7 @@ Une fois votre clavier configuré avec un firmware custom, vous êtes prêt à l
|
|||||||
|
|
||||||
## Tester
|
## Tester
|
||||||
|
|
||||||
Tester votre clavier est normalement assez simple. Appuyez chaque touche de votre clavier et assurez vous qu'il envoie les touches auquel vous vous attendiez. Il existe même des programmes qui vous aideront à vérifier qu'aucune touche ne soit oubliée.
|
Tester votre clavier est normalement assez simple. Appuyez chaque touche de votre clavier et assurez-vous qu'il envoie les touches auquel vous vous attendiez. Il existe même des programmes qui vous aideront à vérifier qu'aucune touche ne soit oubliée.
|
||||||
|
|
||||||
Note: ces programmes ne sont ni fournis ni approuvés par QMK.
|
Note: ces programmes ne sont ni fournis ni approuvés par QMK.
|
||||||
|
|
||||||
@@ -30,7 +30,7 @@ void keyboard_post_init_user(void) {
|
|||||||
|
|
||||||
### Débuguer avec QMK Toolbox
|
### Débuguer avec QMK Toolbox
|
||||||
|
|
||||||
Pour les plateformes compatibles, [QMK Toolbox](https://github.com/qmk/qmk_toolbox) peut être utilisé pour afficher les message de débugage pour votre clavier.
|
Pour les plateformes compatibles, [QMK Toolbox](https://github.com/qmk/qmk_toolbox) peut être utilisé pour afficher les messages de débugage pour votre clavier.
|
||||||
|
|
||||||
### Débuguer avec hid_listen
|
### Débuguer avec hid_listen
|
||||||
|
|
||||||
@@ -47,9 +47,9 @@ Parfois, il est utile d'afficher des messages de débugage depuis votre [code cu
|
|||||||
Une fois fait, vous pouvez utiliser les fonctions print suivantes:
|
Une fois fait, vous pouvez utiliser les fonctions print suivantes:
|
||||||
|
|
||||||
* `print("string")`: Affiche une simple chaîne de caractères.
|
* `print("string")`: Affiche une simple chaîne de caractères.
|
||||||
* `uprintf("%s string", var)`: Affiche une chaîne de caractères formattée.
|
* `uprintf("%s string", var)`: Affiche une chaîne de caractères formatée.
|
||||||
* `dprint("string")` Affiche une chaîne de caractère simple, mais uniquement lorsque le mode debug est activé.
|
* `dprint("string")` Affiche une chaîne de caractère simple, mais uniquement lorsque le mode debug est activé.
|
||||||
* `dprintf("%s string", var)`: Affiche une chaîne de caractère formattée, mais uniquement lorsque le mode debug est activé.
|
* `dprintf("%s string", var)`: Affiche une chaîne de caractère formatée, mais uniquement lorsque le mode debug est activé.
|
||||||
|
|
||||||
## Exemples de debugage
|
## Exemples de debugage
|
||||||
|
|
||||||
|
|||||||
@@ -145,7 +145,7 @@ util/docker_build.sh
|
|||||||
There is also support for building _and_ flashing the keyboard straight from Docker by specifying the `target` as well:
|
There is also support for building _and_ flashing the keyboard straight from Docker by specifying the `target` as well:
|
||||||
```bash
|
```bash
|
||||||
util/docker_build.sh keyboard:keymap:target
|
util/docker_build.sh keyboard:keymap:target
|
||||||
# For example: util/docker_build.sh planck/rev6:default:dfu-util
|
# For example: util/docker_build.sh planck/rev6:default:flash
|
||||||
```
|
```
|
||||||
If you're on Linux, this should work out of the box. On Windows and macOS, it requires [Docker Machine](http://gw.tnode.com/docker/docker-machine-with-usb-support-on-windows-macos/) to be running. This is tedious to set up, so it's not recommended; use [QMK Toolbox](https://github.com/qmk/qmk_toolbox) instead.
|
If you're on Linux, this should work out of the box. On Windows and macOS, it requires [Docker Machine](http://gw.tnode.com/docker/docker-machine-with-usb-support-on-windows-macos/) to be running. This is tedious to set up, so it's not recommended; use [QMK Toolbox](https://github.com/qmk/qmk_toolbox) instead.
|
||||||
|
|
||||||
|
|||||||
@@ -14,8 +14,8 @@ The full syntax of the `make` command is `<keyboard_folder>:<keymap>:<target>`,
|
|||||||
The `<target>` means the following
|
The `<target>` means the following
|
||||||
* If no target is given, then it's the same as `all` below
|
* If no target is given, then it's the same as `all` below
|
||||||
* `all` compiles as many keyboard/revision/keymap combinations as specified. For example, `make planck/rev4:default` will generate a single .hex, while `make planck/rev4:all` will generate a hex for every keymap available to the planck.
|
* `all` compiles as many keyboard/revision/keymap combinations as specified. For example, `make planck/rev4:default` will generate a single .hex, while `make planck/rev4:all` will generate a hex for every keymap available to the planck.
|
||||||
* `dfu`, `teensy`, `avrdude`, `dfu-util` or `bootloadHID`, compile and upload the firmware to the keyboard. If the compilation fails, then nothing will be uploaded. The programmer to use depends on the keyboard. For most keyboards it's `dfu`, but for ChibiOS keyboards you should use `dfu-util`, and `teensy` for standard Teensys. To find out which command you should use for your keyboard, check the keyboard specific readme.
|
* `flash`, `dfu`, `teensy`, `avrdude`, `dfu-util`, or `bootloadHID` compile and upload the firmware to the keyboard. If the compilation fails, then nothing will be uploaded. The programmer to use depends on the keyboard. For most keyboards it's `dfu`, but for ChibiOS keyboards you should use `dfu-util`, and `teensy` for standard Teensys. To find out which command you should use for your keyboard, check the keyboard specific readme.
|
||||||
* **Note**: some operating systems need root access for these commands to work, so in that case you need to run for example `sudo make planck/rev4:default:dfu`.
|
* **Note**: some operating systems need root access for these commands to work, so in that case you need to run for example `sudo make planck/rev4:default:flash`.
|
||||||
* `clean`, cleans the build output folders to make sure that everything is built from scratch. Run this before normal compilation if you have some unexplainable problems.
|
* `clean`, cleans the build output folders to make sure that everything is built from scratch. Run this before normal compilation if you have some unexplainable problems.
|
||||||
|
|
||||||
You can also add extra options at the end of the make command line, after the target
|
You can also add extra options at the end of the make command line, after the target
|
||||||
@@ -31,7 +31,7 @@ Here are some examples commands
|
|||||||
|
|
||||||
* `make all:all` builds everything (all keyboard folders, all keymaps). Running just `make` from the `root` will also run this.
|
* `make all:all` builds everything (all keyboard folders, all keymaps). Running just `make` from the `root` will also run this.
|
||||||
* `make ergodox_infinity:algernon:clean` will clean the build output of the Ergodox Infinity keyboard.
|
* `make ergodox_infinity:algernon:clean` will clean the build output of the Ergodox Infinity keyboard.
|
||||||
* `make planck/rev4:default:dfu COLOR=false` builds and uploads the keymap without color output.
|
* `make planck/rev4:default:flash COLOR=false` builds and uploads the keymap without color output.
|
||||||
|
|
||||||
## `rules.mk` Options
|
## `rules.mk` Options
|
||||||
|
|
||||||
|
|||||||
+62
-43
@@ -86,7 +86,23 @@ Click the `Flash` button in QMK Toolbox. You will see output similar to the foll
|
|||||||
|
|
||||||
## Flash your Keyboard from the Command Line
|
## Flash your Keyboard from the Command Line
|
||||||
|
|
||||||
First thing you'll need to know is which bootloader that your keyboard uses. There are four main bootloaders that are used, usually. Pro-Micro and clones use CATERINA, and Teensy's use Halfkay, OLKB boards use QMK-DFU, and other atmega32u4 chips use DFU.
|
This has been made pretty simple compared to what it used to be. When you are ready to compile and flash your firmware, open up your terminal window and run the build command:
|
||||||
|
|
||||||
|
make <my_keyboard>:<my_keymap>:flash
|
||||||
|
|
||||||
|
For example, if your keymap is named "xyverz" and you're building a keymap for a rev5 planck, you'll use this command:
|
||||||
|
|
||||||
|
make planck/rev5:xyverz:flash
|
||||||
|
|
||||||
|
This will check the keyboard's configuration, and then attempt to flash it based on the specified bootloader. This means that you don't need to know which bootloader that your keyboard uses. Just run the command, and let the command do the heavy lifting.
|
||||||
|
|
||||||
|
However, this does rely on the bootloader being set by the keyboard. If this information is not configured, or you're using a board that doesn't have a supported target to flash it, you will see this error:
|
||||||
|
|
||||||
|
WARNING: This board's bootloader is not specified or is not supported by the ":flash" target at this time.
|
||||||
|
|
||||||
|
In this case, you'll have to fall back on specifying the bootloader.
|
||||||
|
|
||||||
|
There are five main bootloaders that are used. Pro Micro and clones use Caterina, Teensys use HalfKay, OLKB's AVR boards use QMK-DFU, other ATmega32U4 boards use DFU, and most ARM boards use ARM DFU.
|
||||||
|
|
||||||
You can find more information about the bootloaders in the [Flashing Instructions and Bootloader Information](flashing.md) page.
|
You can find more information about the bootloaders in the [Flashing Instructions and Bootloader Information](flashing.md) page.
|
||||||
|
|
||||||
@@ -216,11 +232,14 @@ If you have any issues with this, you may need to this:
|
|||||||
sudo make <my_keyboard>:<my_keymap>:avrdude
|
sudo make <my_keyboard>:<my_keymap>:avrdude
|
||||||
|
|
||||||
|
|
||||||
Additionally, if you want to flash multiple boards, use the following command:
|
#### Caterina commands
|
||||||
|
|
||||||
make <keyboard>:<keymap>:avrdude-loop
|
There are a number of DFU commands that you can use to flash firmware to a DFU device:
|
||||||
|
|
||||||
When you're done flashing boards, you'll need to hit Ctrl + C or whatever the correct keystroke is for your operating system to break the loop.
|
* `:avrdude` - This is the normal option which waits until a Caterina device is available (by detecting a new COM port), and then flashes the firmware.
|
||||||
|
* `:avrdude-loop` - This runs the same command as `:avrdude`, but after each device is flashed, it will attempt to flash again. This is useful for bulk flashing. _This requires you to manually escape the loop by hitting Control+C._
|
||||||
|
* `:avrdude-split-left` - This flashes the normal firmware, just like the default option (`:avrdude`). However, this also flashes the "Left Side" EEPROM file for split keyboards. _This is ideal for Pro Micro based split keyboards._
|
||||||
|
* `:avrdude-split-right` - This flashes the normal firmware, just like the default option (`:avrdude`). However, this also flashes the "Right Side" EEPROM file for split keyboards. _This is ideal for Pro Micro based split keyboards._
|
||||||
|
|
||||||
|
|
||||||
### HalfKay
|
### HalfKay
|
||||||
@@ -256,42 +275,6 @@ Programming.....................................................................
|
|||||||
Booting
|
Booting
|
||||||
```
|
```
|
||||||
|
|
||||||
### BootloadHID
|
|
||||||
|
|
||||||
For Bootmapper Client(BMC)/bootloadHID/ATmega32A based boards, when you're ready to compile and flash your firmware, open up your terminal window and run the build command:
|
|
||||||
|
|
||||||
make <my_keyboard>:<my_keymap>:bootloaderHID
|
|
||||||
|
|
||||||
For example, if your keymap is named "xyverz" and you're building a keymap for a jj40, you'll use this command:
|
|
||||||
|
|
||||||
make jj40:xyverz:bootloaderHID
|
|
||||||
|
|
||||||
Once the firmware finishes compiling, it will output something like this:
|
|
||||||
|
|
||||||
```
|
|
||||||
Linking: .build/jj40_default.elf [OK]
|
|
||||||
Creating load file for flashing: .build/jj40_default.hex [OK]
|
|
||||||
Copying jj40_default.hex to qmk_firmware folder [OK]
|
|
||||||
Checking file size of jj40_default.hex [OK]
|
|
||||||
* The firmware size is fine - 21920/28672 (6752 bytes free)
|
|
||||||
```
|
|
||||||
|
|
||||||
After it gets to this point, the build script will look for the DFU bootloader every 5 seconds. It will repeat the following until the device is found or you cancel it.
|
|
||||||
|
|
||||||
```
|
|
||||||
Error opening HIDBoot device: The specified device was not found
|
|
||||||
Trying again in 5s.
|
|
||||||
```
|
|
||||||
|
|
||||||
Once it does this, you'll want to reset the controller. It should then show output similar to this:
|
|
||||||
|
|
||||||
```
|
|
||||||
Page size = 128 (0x80)
|
|
||||||
Device size = 32768 (0x8000); 30720 bytes remaining
|
|
||||||
Uploading 22016 (0x5600) bytes starting at 0 (0x0)
|
|
||||||
0x05580 ... 0x05600
|
|
||||||
```
|
|
||||||
|
|
||||||
### STM32 (ARM)
|
### STM32 (ARM)
|
||||||
|
|
||||||
For a majority of ARM boards (including the Proton C, Planck Rev 6, and Preonic Rev 3), when you're ready to compile and flash your firmware, open up your terminal window and run the build command:
|
For a majority of ARM boards (including the Proton C, Planck Rev 6, and Preonic Rev 3), when you're ready to compile and flash your firmware, open up your terminal window and run the build command:
|
||||||
@@ -346,11 +329,47 @@ Transitioning to dfuMANIFEST state
|
|||||||
|
|
||||||
There are a number of DFU commands that you can use to flash firmware to a STM32 device:
|
There are a number of DFU commands that you can use to flash firmware to a STM32 device:
|
||||||
|
|
||||||
* `:dfu-util` - The default command for flashing to STM32 devices.
|
* `:dfu-util` - The default command for flashing to STM32 devices, and will wait until an STM32 bootloader is present. .
|
||||||
* `:dfu-util-wait` - This works like the default command, but it gives you a (configurable) 10 second timeout before it attempts to flash the firmware. You can use `TIME_DELAY=20` from the command line to change the timeout.
|
|
||||||
* Eg: `make <keyboard>:<keymap>:dfu-util TIME_DELAY=5`
|
|
||||||
* `:dfu-util-split-left` - This flashes the normal firmware, just like the default option (`:dfu-util`). However, this also configures the "Left Side" EEPROM setting for split keyboards.
|
* `:dfu-util-split-left` - This flashes the normal firmware, just like the default option (`:dfu-util`). However, this also configures the "Left Side" EEPROM setting for split keyboards.
|
||||||
* `:dfu-util-split-right` - This flashes the normal firmware, just like the default option (`:dfu-util`). However, this also configures the "Right Side" EEPROM setting for split keyboards.
|
* `:dfu-util-split-right` - This flashes the normal firmware, just like the default option (`:dfu-util`). However, this also configures the "Right Side" EEPROM setting for split keyboards.
|
||||||
|
* `:st-link-cli` - This allows you to flash the firmware via ST-LINK's CLI utility, rather than dfu-util.
|
||||||
|
|
||||||
|
|
||||||
|
### BootloadHID
|
||||||
|
|
||||||
|
For Bootmapper Client(BMC)/bootloadHID/ATmega32A based boards, when you're ready to compile and flash your firmware, open up your terminal window and run the build command:
|
||||||
|
|
||||||
|
make <my_keyboard>:<my_keymap>:bootloaderHID
|
||||||
|
|
||||||
|
For example, if your keymap is named "xyverz" and you're building a keymap for a jj40, you'll use this command:
|
||||||
|
|
||||||
|
make jj40:xyverz:bootloaderHID
|
||||||
|
|
||||||
|
Once the firmware finishes compiling, it will output something like this:
|
||||||
|
|
||||||
|
```
|
||||||
|
Linking: .build/jj40_default.elf [OK]
|
||||||
|
Creating load file for flashing: .build/jj40_default.hex [OK]
|
||||||
|
Copying jj40_default.hex to qmk_firmware folder [OK]
|
||||||
|
Checking file size of jj40_default.hex [OK]
|
||||||
|
* The firmware size is fine - 21920/28672 (6752 bytes free)
|
||||||
|
```
|
||||||
|
|
||||||
|
After it gets to this point, the build script will look for the DFU bootloader every 5 seconds. It will repeat the following until the device is found or you cancel it.
|
||||||
|
|
||||||
|
```
|
||||||
|
Error opening HIDBoot device: The specified device was not found
|
||||||
|
Trying again in 5s.
|
||||||
|
```
|
||||||
|
|
||||||
|
Once it does this, you'll want to reset the controller. It should then show output similar to this:
|
||||||
|
|
||||||
|
```
|
||||||
|
Page size = 128 (0x80)
|
||||||
|
Device size = 32768 (0x8000); 30720 bytes remaining
|
||||||
|
Uploading 22016 (0x5600) bytes starting at 0 (0x0)
|
||||||
|
0x05580 ... 0x05600
|
||||||
|
```
|
||||||
|
|
||||||
## Test It Out!
|
## Test It Out!
|
||||||
|
|
||||||
|
|||||||
@@ -0,0 +1,33 @@
|
|||||||
|
# WS2812 Driver
|
||||||
|
This driver powers the [RGB Lighting](feature_rgblight.md) and [RGB Matrix](feature_rgb_matrix.md) features.
|
||||||
|
|
||||||
|
Currently QMK supports the following addressable LEDs on AVR microcontrollers (however, the white LED in RGBW variants is not supported):
|
||||||
|
|
||||||
|
WS2811, WS2812, WS2812B, WS2812C, etc.
|
||||||
|
SK6812, SK6812MINI, SK6805
|
||||||
|
|
||||||
|
These LEDs are called "addressable" because instead of using a wire per color, each LED contains a small microchip that understands a special protocol sent over a single wire. The chip passes on the remaining data to the next LED, allowing them to be chained together. In this way, you can easily control the color of the individual LEDs.
|
||||||
|
|
||||||
|
## Driver configuration
|
||||||
|
|
||||||
|
### Bitbang
|
||||||
|
Default driver, the absence of configuration assumes this driver. To configure it, add this to your rules.mk:
|
||||||
|
|
||||||
|
```make
|
||||||
|
WS2812_DRIVER = bitbang
|
||||||
|
```
|
||||||
|
|
||||||
|
!> ARM does not yet support WS2182. Progress is being made, but we are not quite there, yet.
|
||||||
|
|
||||||
|
### I2C
|
||||||
|
Targeting boards where WS2812 support is offloaded to a 2nd MCU. Currently the driver is limited to AVR given the known consumers are ps2avrGB/BMC. To configure it, add this to your rules.mk:
|
||||||
|
|
||||||
|
```make
|
||||||
|
WS2812_DRIVER = i2c
|
||||||
|
```
|
||||||
|
|
||||||
|
Configure the hardware via your config.h:
|
||||||
|
```c
|
||||||
|
#define WS2812_ADDRESS 0xb0 // default: 0xb0
|
||||||
|
#define WS2812_TIMEOUT 100 // default: 100
|
||||||
|
```
|
||||||
@@ -0,0 +1 @@
|
|||||||
|
#error("NOT SUPPORTED")
|
||||||
@@ -0,0 +1 @@
|
|||||||
|
#error("NOT SUPPORTED")
|
||||||
@@ -0,0 +1 @@
|
|||||||
|
#error("NOT SUPPORTED")
|
||||||
@@ -0,0 +1,31 @@
|
|||||||
|
#include "ws2812.h"
|
||||||
|
#include "i2c_master.h"
|
||||||
|
|
||||||
|
#ifndef WS2812_ADDRESS
|
||||||
|
# define WS2812_ADDRESS 0xb0
|
||||||
|
#endif
|
||||||
|
|
||||||
|
#ifndef WS2812_TIMEOUT
|
||||||
|
# define WS2812_TIMEOUT 100
|
||||||
|
#endif
|
||||||
|
|
||||||
|
void ws2812_init(void) { i2c_init(); }
|
||||||
|
|
||||||
|
// Setleds for standard RGB
|
||||||
|
void ws2812_setleds(LED_TYPE *ledarray, uint16_t leds) {
|
||||||
|
static bool s_init = false;
|
||||||
|
if (!s_init) {
|
||||||
|
ws2812_init();
|
||||||
|
s_init = true;
|
||||||
|
}
|
||||||
|
|
||||||
|
i2c_transmit(WS2812_ADDRESS, (uint8_t *)ledarray, sizeof(LED_TYPE) * leds, WS2812_TIMEOUT);
|
||||||
|
}
|
||||||
|
|
||||||
|
// Setleds for SK6812RGBW
|
||||||
|
void ws2812_setleds_rgbw(LED_TYPE *ledarray, uint16_t leds) {
|
||||||
|
// not supported - for now error out if its enabled
|
||||||
|
#ifdef RGBW
|
||||||
|
# error "RGBW not supported"
|
||||||
|
#endif
|
||||||
|
}
|
||||||
@@ -17,40 +17,3 @@ along with this program. If not, see <http://www.gnu.org/licenses/>.
|
|||||||
*/
|
*/
|
||||||
|
|
||||||
#include "jj40.h"
|
#include "jj40.h"
|
||||||
|
|
||||||
#ifdef RGBLIGHT_ENABLE
|
|
||||||
|
|
||||||
#include <string.h>
|
|
||||||
#include "i2c_master.h"
|
|
||||||
#include "rgblight.h"
|
|
||||||
|
|
||||||
extern rgblight_config_t rgblight_config;
|
|
||||||
|
|
||||||
void matrix_init_kb(void) {
|
|
||||||
i2c_init();
|
|
||||||
// call user level keymaps, if any
|
|
||||||
matrix_init_user();
|
|
||||||
}
|
|
||||||
// custom RGB driver
|
|
||||||
void rgblight_set(void) {
|
|
||||||
if (!rgblight_config.enable) {
|
|
||||||
memset(led, 0, 3 * RGBLED_NUM);
|
|
||||||
}
|
|
||||||
|
|
||||||
i2c_transmit(0xb0, (uint8_t*)led, 3 * RGBLED_NUM, 100);
|
|
||||||
}
|
|
||||||
|
|
||||||
bool rgb_init = false;
|
|
||||||
|
|
||||||
void matrix_scan_kb(void) {
|
|
||||||
// if LEDs were previously on before poweroff, turn them back on
|
|
||||||
if (rgb_init == false && rgblight_config.enable) {
|
|
||||||
i2c_transmit(0xb0, (uint8_t*)led, 3 * RGBLED_NUM, 100);
|
|
||||||
rgb_init = true;
|
|
||||||
}
|
|
||||||
|
|
||||||
rgblight_task();
|
|
||||||
matrix_scan_user();
|
|
||||||
}
|
|
||||||
|
|
||||||
#endif
|
|
||||||
@@ -40,7 +40,7 @@ SLEEP_LED_ENABLE = no # Breathing sleep LED during USB suspend
|
|||||||
NKRO_ENABLE = no # USB Nkey Rollover
|
NKRO_ENABLE = no # USB Nkey Rollover
|
||||||
BACKLIGHT_ENABLE = yes # Enable keyboard backlight functionality on B7 by default
|
BACKLIGHT_ENABLE = yes # Enable keyboard backlight functionality on B7 by default
|
||||||
RGBLIGHT_ENABLE = yes # Enable keyboard RGB underglow
|
RGBLIGHT_ENABLE = yes # Enable keyboard RGB underglow
|
||||||
RGBLIGHT_CUSTOM_DRIVER = yes
|
WS2812_DRIVER = i2c
|
||||||
MIDI_ENABLE = no # MIDI support (+2400 to 4200, depending on config)
|
MIDI_ENABLE = no # MIDI support (+2400 to 4200, depending on config)
|
||||||
UNICODE_ENABLE = no # Unicode
|
UNICODE_ENABLE = no # Unicode
|
||||||
BLUETOOTH_ENABLE = no # Enable Bluetooth with the Adafruit EZ-Key HID
|
BLUETOOTH_ENABLE = no # Enable Bluetooth with the Adafruit EZ-Key HID
|
||||||
@@ -48,6 +48,4 @@ AUDIO_ENABLE = no # Audio output on port C6
|
|||||||
FAUXCLICKY_ENABLE = no # Use buzzer to emulate clicky switches
|
FAUXCLICKY_ENABLE = no # Use buzzer to emulate clicky switches
|
||||||
HD44780_ENABLE = no # Enable support for HD44780 based LCDs (+400)
|
HD44780_ENABLE = no # Enable support for HD44780 based LCDs (+400)
|
||||||
|
|
||||||
SRC += i2c_master.c
|
|
||||||
|
|
||||||
LAYOUTS = ortho_4x12 planck_mit
|
LAYOUTS = ortho_4x12 planck_mit
|
||||||
@@ -19,16 +19,6 @@
|
|||||||
|
|
||||||
extern keymap_config_t keymap_config;
|
extern keymap_config_t keymap_config;
|
||||||
|
|
||||||
// Each layer gets a name for readability, which is then used in the keymap matrix below.
|
|
||||||
// The underscores don't mean anything - you can have a layer called STUFF or any other name.
|
|
||||||
// Layer names don't all need to be of the same length, obviously, and you can also skip them
|
|
||||||
// entirely and just use numbers.
|
|
||||||
#define BASE 0
|
|
||||||
#define SYMB 1
|
|
||||||
#define MDIA 2
|
|
||||||
#define ARRW 3
|
|
||||||
#define _ADJUST 16
|
|
||||||
|
|
||||||
#define CT_APOS CTL_T(SE_APOS)
|
#define CT_APOS CTL_T(SE_APOS)
|
||||||
#define CT_TILD CTL_T(SE_TILD)
|
#define CT_TILD CTL_T(SE_TILD)
|
||||||
#define MD_OSLH LT(MDIA, SE_OSLH)
|
#define MD_OSLH LT(MDIA, SE_OSLH)
|
||||||
@@ -36,6 +26,15 @@ extern keymap_config_t keymap_config;
|
|||||||
#define SE_LT SE_LESS
|
#define SE_LT SE_LESS
|
||||||
#define SE_GT LSFT(SE_LESS)
|
#define SE_GT LSFT(SE_LESS)
|
||||||
|
|
||||||
|
enum layer_names {
|
||||||
|
BASE,
|
||||||
|
GAME,
|
||||||
|
SYMB,
|
||||||
|
MDIA,
|
||||||
|
ARRW,
|
||||||
|
_ADJUST,
|
||||||
|
};
|
||||||
|
|
||||||
enum custom_keycodes {
|
enum custom_keycodes {
|
||||||
PLACEHOLDER = SAFE_RANGE,
|
PLACEHOLDER = SAFE_RANGE,
|
||||||
ADJUST,
|
ADJUST,
|
||||||
@@ -68,6 +67,28 @@ const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
|
|||||||
CT_APOS, SE_ACUT, KC_LALT, KC_BSPC, KC_SPC, KC_LGUI, KC_ENT, KC_SPC, KC_BSPC, KC_ALGR, SE_ASTR, CT_TILD \
|
CT_APOS, SE_ACUT, KC_LALT, KC_BSPC, KC_SPC, KC_LGUI, KC_ENT, KC_SPC, KC_BSPC, KC_ALGR, SE_ASTR, CT_TILD \
|
||||||
),
|
),
|
||||||
|
|
||||||
|
/* Gaming layer
|
||||||
|
* ,-----------------------------------------. .-----------------------------------------.
|
||||||
|
* | Esc | 1 | 2 | 3 | 4 | 5 | | 6 | 7 | 8 | 9 | 0 | + |
|
||||||
|
* |------+------+------+------+------+------+ +------+------+------+------+------+------|
|
||||||
|
* | Tab | Q | W | E | R | T | | Y | U | I | O | P | Å |
|
||||||
|
* |------+------+------+------+------+------| |------+------+------+------+------+------|
|
||||||
|
* | ARRW | A | S | D | F | G | | H | J | K | L | Ö | Ä |
|
||||||
|
* |------+------+------+------+------+------| |------+------+------+------+------+------|
|
||||||
|
* |Shift | Z | X | C | V | B | | N | M | , | . | - | Shift|
|
||||||
|
* |------+------+------+------+------+------+ +------+------+------+------+------+------|
|
||||||
|
* | Ctrl | ´ | Alt | Bsp |Space | Win | | Entr | Space| Bsb | AlGr | * | Ctrl |
|
||||||
|
* `-----------------------------------------' '-----------------------------------------'
|
||||||
|
*/
|
||||||
|
[GAME] = LAYOUT( \
|
||||||
|
// LEFT HAND RIGHT HAND
|
||||||
|
KC_ESC, KC_1, KC_2, KC_3, KC_4, KC_5, KC_6, KC_7, KC_8, KC_9, KC_0, SE_PLUS, \
|
||||||
|
KC_TAB, KC_Q, KC_W, KC_E, KC_R, KC_T, KC_Y, KC_U, KC_I, KC_O, KC_P, SE_AA, \
|
||||||
|
MO(ARRW), KC_A, KC_S, KC_D, KC_F, KC_G, KC_H, KC_J, KC_K, KC_L, MD_OSLH, SM_AE, \
|
||||||
|
KC_LSFT, KC_Z, KC_X, KC_C, KC_V, KC_B, KC_N, KC_M, KC_COMM, KC_DOT, SE_MINS, KC_RSFT, \
|
||||||
|
KC_LCTL, SE_ACUT, KC_LALT, KC_BSPC, KC_SPC, KC_LGUI, KC_ENT, KC_SPC, KC_BSPC, KC_ALGR, SE_ASTR, KC_RCTL \
|
||||||
|
),
|
||||||
|
|
||||||
/* Symbols layer
|
/* Symbols layer
|
||||||
* ,-----------------------------------------. .-----------------------------------------.
|
* ,-----------------------------------------. .-----------------------------------------.
|
||||||
* | | F1 | F2 | F3 | F4 | F5 | | F6 | F7 | F8 | F9 | F10 | F11 |
|
* | | F1 | F2 | F3 | F4 | F5 | | F6 | F7 | F8 | F9 | F10 | F11 |
|
||||||
@@ -112,9 +133,9 @@ const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
|
|||||||
|
|
||||||
/* Arrow layer
|
/* Arrow layer
|
||||||
* ,-----------------------------------------. .-----------------------------------------.
|
* ,-----------------------------------------. .-----------------------------------------.
|
||||||
* | §/½ | | | | | | | | | | Ins | Home | PgUp |
|
* | §/½ | | | | | | | | | BASE | Ins | Home | PgUp |
|
||||||
* |------+------+------+------+------+------+ +------+------+------+------+------+------|
|
* |------+------+------+------+------+------+ +------+------+------+------+------+------|
|
||||||
* | | | Up | | | | | | | | Del | End | PgDn |
|
* | | | Up | | | | | | | GAME | Del | End | PgDn |
|
||||||
* |------+------+------+------+------+------| |------+------+------+------+------+------|
|
* |------+------+------+------+------+------| |------+------+------+------+------+------|
|
||||||
* | | Left | Down | Right| | Back | | Fwd | | | | | |
|
* | | Left | Down | Right| | Back | | Fwd | | | | | |
|
||||||
* |------+------+------+------+------+------| |------+------+------+------+------+------|
|
* |------+------+------+------+------+------| |------+------+------+------+------+------|
|
||||||
@@ -124,8 +145,8 @@ const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
|
|||||||
* `-----------------------------------------' '-----------------------------------------'
|
* `-----------------------------------------' '-----------------------------------------'
|
||||||
*/
|
*/
|
||||||
[ARRW] = LAYOUT( \
|
[ARRW] = LAYOUT( \
|
||||||
SE_HALF, _______, _______, _______ , _______, _______, _______, _______, _______, KC_INS , KC_HOME, KC_PGUP, \
|
SE_HALF, _______, _______, _______ , _______, _______, _______, _______, DF(BASE), KC_INS , KC_HOME, KC_PGUP, \
|
||||||
_______, _______, KC_UP , _______ , _______, _______, _______, _______, _______, KC_DEL , KC_END , KC_PGDN, \
|
_______, _______, KC_UP , _______ , _______, _______, _______, _______, DF(GAME), KC_DEL , KC_END , KC_PGDN, \
|
||||||
_______, KC_LEFT, KC_DOWN, KC_RIGHT, _______, KC_WBAK, KC_WFWD, _______, _______, _______, _______, _______, \
|
_______, KC_LEFT, KC_DOWN, KC_RIGHT, _______, KC_WBAK, KC_WFWD, _______, _______, _______, _______, _______, \
|
||||||
_______, _______, _______, _______ , _______, _______, _______, _______, _______, _______, _______, _______, \
|
_______, _______, _______, _______ , _______, _______, _______, _______, _______, _______, _______, _______, \
|
||||||
_______, _______, _______, KC_DEL , _______, _______, _______, _______, _______, _______, _______, _______ \
|
_______, _______, _______, KC_DEL , _______, _______, _______, _______, _______, _______, _______, _______ \
|
||||||
|
|||||||
@@ -0,0 +1,47 @@
|
|||||||
|
/* Copyright 2019 gtips
|
||||||
|
*
|
||||||
|
* This program is free software: you can redistribute it and/or modify
|
||||||
|
* it under the terms of the GNU General Public License as published by
|
||||||
|
* the Free Software Foundation, either version 2 of the License, or
|
||||||
|
* (at your option) any later version.
|
||||||
|
*
|
||||||
|
* This program is distributed in the hope that it will be useful,
|
||||||
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||||
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||||
|
* GNU General Public License for more details.
|
||||||
|
*
|
||||||
|
* You should have received a copy of the GNU General Public License
|
||||||
|
* along with this program. If not, see <http://www.gnu.org/licenses/>.
|
||||||
|
*/
|
||||||
|
|
||||||
|
#pragma once
|
||||||
|
|
||||||
|
// place overrides here
|
||||||
|
|
||||||
|
#define RGB_DI_PIN D3
|
||||||
|
#ifdef RGB_DI_PIN
|
||||||
|
#define RGBLED_NUM 11
|
||||||
|
#define RGBLIGHT_HUE_STEP 16
|
||||||
|
#define RGBLIGHT_SAT_STEP 16
|
||||||
|
#define RGBLIGHT_VAL_STEP 16
|
||||||
|
#define RGBLIGHT_LIMIT_VAL 255 /* The maximum brightness level */
|
||||||
|
#define RGBLIGHT_SLEEP /* If defined, the RGB lighting will be switched off when the host goes to sleep */
|
||||||
|
// /*== all animations enable ==*/
|
||||||
|
#define RGBLIGHT_ANIMATIONS
|
||||||
|
// /*== or choose animations ==*/
|
||||||
|
// #define RGBLIGHT_EFFECT_BREATHING
|
||||||
|
// #define RGBLIGHT_EFFECT_RAINBOW_MOOD
|
||||||
|
// #define RGBLIGHT_EFFECT_RAINBOW_SWIRL
|
||||||
|
// #define RGBLIGHT_EFFECT_SNAKE
|
||||||
|
// #define RGBLIGHT_EFFECT_KNIGHT
|
||||||
|
// #define RGBLIGHT_EFFECT_CHRISTMAS
|
||||||
|
// #define RGBLIGHT_EFFECT_STATIC_GRADIENT
|
||||||
|
// #define RGBLIGHT_EFFECT_RGB_TEST
|
||||||
|
// #define RGBLIGHT_EFFECT_ALTERNATING
|
||||||
|
// /*== customize breathing effect ==*/
|
||||||
|
// /*==== (DEFAULT) use fixed table instead of exp() and sin() ====*/
|
||||||
|
// #define RGBLIGHT_BREATHE_TABLE_SIZE 256 // 256(default) or 128 or 64
|
||||||
|
// /*==== use exp() and sin() ====*/
|
||||||
|
// #define RGBLIGHT_EFFECT_BREATHE_CENTER 1.85 // 1 to 2.7
|
||||||
|
// #define RGBLIGHT_EFFECT_BREATHE_MAX 255 // 0 to 255
|
||||||
|
#endif
|
||||||
@@ -0,0 +1,57 @@
|
|||||||
|
/* Copyright 2019 gtips
|
||||||
|
*
|
||||||
|
* This program is free software: you can redistribute it and/or modify
|
||||||
|
* it under the terms of the GNU General Public License as published by
|
||||||
|
* the Free Software Foundation, either version 2 of the License, or
|
||||||
|
* (at your option) any later version.
|
||||||
|
*
|
||||||
|
* This program is distributed in the hope that it will be useful,
|
||||||
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||||
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||||
|
* GNU General Public License for more details.
|
||||||
|
*
|
||||||
|
* You should have received a copy of the GNU General Public License
|
||||||
|
* along with this program. If not, see <http://www.gnu.org/licenses/>.
|
||||||
|
*/
|
||||||
|
#include QMK_KEYBOARD_H
|
||||||
|
|
||||||
|
enum layer_names {
|
||||||
|
_BASE,
|
||||||
|
_LOWER,
|
||||||
|
_RAISE,
|
||||||
|
_ADJUST
|
||||||
|
};
|
||||||
|
|
||||||
|
#define LOWER MO(_LOWER)
|
||||||
|
#define RAISE MO(_RAISE)
|
||||||
|
#define ADJUST MO(_ADJUST)
|
||||||
|
|
||||||
|
const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
|
||||||
|
[_BASE] = LAYOUT_reviung39(
|
||||||
|
KC_ESC, KC_Q, KC_W, KC_E, KC_R, KC_T, KC_Y, KC_U, KC_I, KC_O, KC_P, KC_BSPACE,
|
||||||
|
KC_TAB, KC_A, KC_S, KC_D, KC_F, KC_G, KC_H, KC_J, KC_K, KC_L, KC_RGUI, KC_RSFT,
|
||||||
|
KC_SPC, KC_Z, KC_X, KC_C, KC_V, KC_B, KC_N, KC_M, KC_RCTL, KC_RGUI, KC_RALT, RGUI(KC_RSFT),
|
||||||
|
LOWER, KC_ENT, RAISE
|
||||||
|
),
|
||||||
|
|
||||||
|
[_LOWER] = LAYOUT_reviung39(
|
||||||
|
KC_TILD, KC_EXLM, KC_AT, KC_HASH, KC_DLR, KC_PERC, KC_CIRC, KC_AMPR, KC_ASTR, _______, _______, _______,
|
||||||
|
_______, KC_LT, KC_GT, KC_LPRN, KC_RPRN, KC_GRV, KC_MINS, KC_LCBR, KC_RCBR, KC_LBRC, KC_RBRC, KC_PIPE,
|
||||||
|
_______, _______, _______, _______, KC_EQL, KC_QUES, KC_UNDS, KC_PLUS, KC_COMM, KC_DOT, KC_SLSH, _______,
|
||||||
|
_______, KC_ENT, KC_RGUI
|
||||||
|
),
|
||||||
|
|
||||||
|
[_RAISE] = LAYOUT_reviung39(
|
||||||
|
_______, KC_1, KC_2, KC_3, KC_4, KC_5, KC_6, KC_7, KC_8, KC_9, KC_0, _______,
|
||||||
|
_______, KC_COLN, KC_SCLN, KC_DQT, KC_QUOT, KC_BSLS, KC_LEFT, KC_DOWN, KC_UP, KC_RGHT, _______, _______,
|
||||||
|
_______, _______, _______, _______, _______, _______, ADJUST, _______, _______, _______, _______, _______,
|
||||||
|
KC_LGUI, KC_ENT, _______
|
||||||
|
),
|
||||||
|
|
||||||
|
[_ADJUST] = LAYOUT_reviung39(
|
||||||
|
RGB_VAI, RGB_SAI, RGB_HUI, RGB_MOD, XXXXXXX, RGB_TOG, KC_Y, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX,
|
||||||
|
RGB_VAD, RGB_SAD, RGB_HUD, RGB_RMOD, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX,
|
||||||
|
XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, RESET, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX,
|
||||||
|
_______, XXXXXXX, _______
|
||||||
|
),
|
||||||
|
};
|
||||||
@@ -0,0 +1,3 @@
|
|||||||
|
# toshi0383's keymap for REVIUNG39
|
||||||
|
|
||||||
|
__REVIUNG39 is regular version__
|
||||||
@@ -0,0 +1 @@
|
|||||||
|
RGBLIGHT_ENABLE = yes
|
||||||
@@ -0,0 +1,39 @@
|
|||||||
|
/*
|
||||||
|
This is the c configuration file for the keymap
|
||||||
|
|
||||||
|
Copyright 2019 Toshihiro Suzuki
|
||||||
|
Copyright 2018 monksoffunk
|
||||||
|
Copyright 2012 Jun Wako <[email protected]>
|
||||||
|
Copyright 2015 Jack Humbert
|
||||||
|
|
||||||
|
This program is free software: you can redistribute it and/or modify
|
||||||
|
it under the terms of the GNU General Public License as published by
|
||||||
|
the Free Software Foundation, either version 2 of the License, or
|
||||||
|
(at your option) any later version.
|
||||||
|
|
||||||
|
This program is distributed in the hope that it will be useful,
|
||||||
|
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||||
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||||
|
GNU General Public License for more details.
|
||||||
|
|
||||||
|
You should have received a copy of the GNU General Public License
|
||||||
|
along with this program. If not, see <http://www.gnu.org/licenses/>.
|
||||||
|
*/
|
||||||
|
|
||||||
|
#pragma once
|
||||||
|
// if you need more program area, try uncomment follow line
|
||||||
|
#include "serial_config_simpleapi.h"
|
||||||
|
|
||||||
|
// place overrides here
|
||||||
|
// Selection of RGBLIGHT MODE to use.
|
||||||
|
#if defined(LED_ANIMATIONS)
|
||||||
|
#define RGBLIGHT_EFFECT_BREATHING
|
||||||
|
#define RGBLIGHT_EFFECT_RAINBOW_MOOD
|
||||||
|
#define RGBLIGHT_EFFECT_RAINBOW_SWIRL
|
||||||
|
#define RGBLIGHT_EFFECT_SNAKE
|
||||||
|
#define RGBLIGHT_EFFECT_KNIGHT
|
||||||
|
#define RGBLIGHT_EFFECT_CHRISTMAS
|
||||||
|
#define RGBLIGHT_EFFECT_STATIC_GRADIENT
|
||||||
|
//#define RGBLIGHT_EFFECT_RGB_TEST
|
||||||
|
//#define RGBLIGHT_EFFECT_ALTERNATING
|
||||||
|
#endif
|
||||||
@@ -0,0 +1,89 @@
|
|||||||
|
#include QMK_KEYBOARD_H
|
||||||
|
|
||||||
|
extern uint8_t is_master;
|
||||||
|
|
||||||
|
enum layer_names {
|
||||||
|
_BASE,
|
||||||
|
_LOWER,
|
||||||
|
_RAISE,
|
||||||
|
_ADJUST
|
||||||
|
};
|
||||||
|
|
||||||
|
#define LOWER MO(_LOWER)
|
||||||
|
#define RAISE MO(_RAISE)
|
||||||
|
#define ADJUST MO(_ADJUST)
|
||||||
|
|
||||||
|
const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = { \
|
||||||
|
/* Qwerty
|
||||||
|
* ,-----------------------------------------. ,-----------------------------------------.
|
||||||
|
* | Esc | Q | W | E | R | T | | Y | U | I | O | P |BSpace|
|
||||||
|
* |------+------+------+------+------+------| |------+------+------+------+------+------|
|
||||||
|
* | Tab | A | S | D | F | G | | H | J | K | L | : |Shift |
|
||||||
|
* |------+------+------+------+------+------| |------+------+------+------+------+------|
|
||||||
|
* |Space | Z | X | C | V | B | | N | M | Ctrl | GUI | Alt | SCMD |
|
||||||
|
* |------+------+------+------+------+------| |------+------+------+------+------+------|
|
||||||
|
* | | | | |Lower |Enter | |Enter |Raise | | | | |
|
||||||
|
* `-----------------------------------------' `-----------------------------------------'
|
||||||
|
*/
|
||||||
|
[_BASE] = LAYOUT_ortho_4x12(
|
||||||
|
KC_ESC, KC_Q, KC_W, KC_E, KC_R, KC_T, KC_Y, KC_U, KC_I, KC_O, KC_P, KC_BSPACE, \
|
||||||
|
KC_TAB, KC_A, KC_S, KC_D, KC_F, KC_G, KC_H, KC_J, KC_K, KC_L, KC_RGUI, KC_RSFT, \
|
||||||
|
KC_SPC, KC_Z, KC_X, KC_C, KC_V, KC_B, KC_N, KC_M, KC_RCTL, KC_RGUI, KC_RALT, RGUI(KC_RSFT), \
|
||||||
|
_______, _______, _______, _______, LOWER, KC_ENT, KC_ENT, RAISE, _______, _______, _______, _______ \
|
||||||
|
),
|
||||||
|
|
||||||
|
/* Lower
|
||||||
|
* ,-----------------------------------------. ,-----------------------------------------.
|
||||||
|
* | ~ | ! | @ | # | $ | % | | ^ | & | * | | | |
|
||||||
|
* |------+------+------+------+------+------| |------+------+------+------+------+------|
|
||||||
|
* | | < | > | ( | ) | ` | | - | { | } | [ | ] | | |
|
||||||
|
* |------+------+------+------+------+------| |------+------+------+------+------+------|
|
||||||
|
* | | | | | = | ? | | _ | + | , | . | / | |
|
||||||
|
* |------+------+------+------+------+------| |------+------+------+------+------+------|
|
||||||
|
* | | | | |------| TRSP | | TRSP | GUI | | | | |
|
||||||
|
* `-----------------------------------------' `-----------------------------------------'
|
||||||
|
*/
|
||||||
|
[_LOWER] = LAYOUT_ortho_4x12( \
|
||||||
|
KC_TILD, KC_EXLM, KC_AT, KC_HASH, KC_DLR, KC_PERC, KC_CIRC, KC_AMPR, KC_ASTR, _______, _______, _______,\
|
||||||
|
_______, KC_LT, KC_GT, KC_LPRN, KC_RPRN, KC_GRV, KC_MINS, KC_LCBR, KC_RCBR, KC_LBRC, KC_RBRC, KC_PIPE, \
|
||||||
|
_______, _______, _______, _______, KC_EQL, KC_QUES, KC_UNDS, KC_PLUS, KC_COMM, KC_DOT, KC_SLSH, _______, \
|
||||||
|
_______, _______, _______, _______, _______, KC_TRNS, ADJUST, KC_RGUI, _______, _______, _______, _______ \
|
||||||
|
),
|
||||||
|
|
||||||
|
/* Raise
|
||||||
|
* ,-----------------------------------------. ,-----------------------------------------.
|
||||||
|
* | | 1 | 2 | 3 | 4 | 5 | | 6 | 7 | 8 | 9 | 0 | |
|
||||||
|
* |------+------+------+------+------+------| |------+------+------+------+------+------|
|
||||||
|
* | | : | ; | " | ' | \ | | Left | Down | Up |Right | | |
|
||||||
|
* |------+------+------+------+------+------| |------+------+------+------+------+------|
|
||||||
|
* | | | | | | | |ADJUST| | | | | |
|
||||||
|
* |------+------+------+------+------+------| |------+------+------+------+------+------|
|
||||||
|
* | | | | | GUI |Shift | |Shift |------| | | | |
|
||||||
|
* `-----------------------------------------' `-----------------------------------------'
|
||||||
|
*/
|
||||||
|
[_RAISE] = LAYOUT_ortho_4x12( \
|
||||||
|
_______, KC_1, KC_2, KC_3, KC_4, KC_5, KC_6, KC_7, KC_8, KC_9, KC_0, _______, \
|
||||||
|
_______, KC_COLN, KC_SCLN, KC_DQT, KC_QUOT, KC_BSLS, KC_LEFT, KC_DOWN, KC_UP, KC_RGHT, _______, _______, \
|
||||||
|
_______, _______, _______, _______, _______, _______, ADJUST, _______, _______, _______, _______, _______, \
|
||||||
|
_______, _______, _______, _______, KC_LGUI, KC_LSFT, KC_LSFT, _______, _______, _______, _______, _______ \
|
||||||
|
),
|
||||||
|
|
||||||
|
/* Adjust (Lower + Raise)
|
||||||
|
* ,-----------------------------------------. ,-----------------------------------------.
|
||||||
|
* | | | | | | | | | | | | | |
|
||||||
|
* |------+------+------+------+------+------| |------+------+------+------+------+------|
|
||||||
|
* | | | | | | | | | | | | | |
|
||||||
|
* |------+------+------+------+------+------| |------+------+------+------+------+------|
|
||||||
|
* | | | | | | | | | | | | | |
|
||||||
|
* |------+------+------+------+------+------| |------+------+------+------+------+------|
|
||||||
|
* | | | | | |RESET | |------| | | | | |
|
||||||
|
* `-----------------------------------------' `-----------------------------------------'
|
||||||
|
*/
|
||||||
|
[_ADJUST] = LAYOUT_ortho_4x12( \
|
||||||
|
_______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______, \
|
||||||
|
_______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______, \
|
||||||
|
_______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______, \
|
||||||
|
_______, _______, _______, _______, _______, RESET, _______, _______, _______, _______, _______, _______ \
|
||||||
|
),
|
||||||
|
|
||||||
|
};
|
||||||
@@ -0,0 +1,95 @@
|
|||||||
|
# Build Options
|
||||||
|
# change yes to no to disable
|
||||||
|
#
|
||||||
|
BOOTMAGIC_ENABLE = no # Virtual DIP switch configuration
|
||||||
|
MOUSEKEY_ENABLE = no # Mouse keys
|
||||||
|
EXTRAKEY_ENABLE = yes # Audio control and System control
|
||||||
|
CONSOLE_ENABLE = no # Console for debug
|
||||||
|
COMMAND_ENABLE = no # Commands for debug and configuration
|
||||||
|
NKRO_ENABLE = no # Nkey Rollover - if this doesn't work, see here: https://github.com/tmk/tmk_keyboard/wiki/FAQ#nkro-doesnt-work
|
||||||
|
BACKLIGHT_ENABLE = no # Enable keyboard backlight functionality
|
||||||
|
MIDI_ENABLE = no # MIDI controls
|
||||||
|
AUDIO_ENABLE = no # Audio output on port C6
|
||||||
|
UNICODE_ENABLE = no # Unicode
|
||||||
|
BLUETOOTH_ENABLE = no # Enable Bluetooth with the Adafruit EZ-Key HID
|
||||||
|
RGBLIGHT_ENABLE = no # Enable WS2812 RGB underlight. Do not enable this with audio at the same time.
|
||||||
|
SWAP_HANDS_ENABLE = no # Enable one-hand typing
|
||||||
|
|
||||||
|
define ZINC_CUSTOMISE_MSG
|
||||||
|
$(info Zinc customize)
|
||||||
|
$(info - LED_BACK_ENABLE=$(LED_BACK_ENABLE))
|
||||||
|
$(info - LED_UNDERGLOW_ENABLE=$(LED_UNDERGLOW_ENABLE))
|
||||||
|
$(info - LED_ANIMATION=$(LED_ANIMATIONS))
|
||||||
|
$(info - IOS_DEVICE_ENABLE=$(IOS_DEVICE_ENABLE))
|
||||||
|
endef
|
||||||
|
|
||||||
|
# Zinc keyboard customize
|
||||||
|
LED_BACK_ENABLE = no # LED backlight (Enable SK6812mini backlight)
|
||||||
|
LED_UNDERGLOW_ENABLE = no # LED underglow (Enable WS2812 RGB underlight)
|
||||||
|
LED_ANIMATIONS = yes # LED animations
|
||||||
|
IOS_DEVICE_ENABLE = no # connect to IOS device (iPad,iPhone)
|
||||||
|
Link_Time_Optimization = no # if firmware size over limit, try this option
|
||||||
|
|
||||||
|
#### LED_BACK_ENABLE and LED_UNDERGLOW_ENABLE.
|
||||||
|
#### Do not enable these with audio at the same time.
|
||||||
|
|
||||||
|
### Zinc keyboard 'default' keymap: convenient command line option
|
||||||
|
## make ZINC=<options> zinc:defualt
|
||||||
|
## option= back | under | na | ios
|
||||||
|
## ex.
|
||||||
|
## make ZINC=under zinc:defualt
|
||||||
|
## make ZINC=under,ios zinc:defualt
|
||||||
|
## make ZINC=back zinc:default
|
||||||
|
## make ZINC=back,na zinc:default
|
||||||
|
## make ZINC=back,ios zinc:default
|
||||||
|
|
||||||
|
ifneq ($(strip $(ZINC)),)
|
||||||
|
ifeq ($(findstring back,$(ZINC)), back)
|
||||||
|
LED_BACK_ENABLE = yes
|
||||||
|
else ifeq ($(findstring under,$(ZINC)), under)
|
||||||
|
LED_UNDERGLOW_ENABLE = yes
|
||||||
|
endif
|
||||||
|
ifeq ($(findstring na,$(ZINC)), na)
|
||||||
|
LED_ANIMATIONS = no
|
||||||
|
endif
|
||||||
|
ifeq ($(findstring ios,$(ZINC)), ios)
|
||||||
|
IOS_DEVICE_ENABLE = yes
|
||||||
|
endif
|
||||||
|
$(eval $(call ZINC_CUSTOMISE_MSG))
|
||||||
|
$(info )
|
||||||
|
endif
|
||||||
|
|
||||||
|
ifeq ($(strip $(LED_BACK_ENABLE)), yes)
|
||||||
|
RGBLIGHT_ENABLE = yes
|
||||||
|
OPT_DEFS += -DRGBLED_BACK
|
||||||
|
ifeq ($(strip $(LED_UNDERGLOW_ENABLE)), yes)
|
||||||
|
$(eval $(call ZINC_CUSTOMISE_MSG))
|
||||||
|
$(error LED_BACK_ENABLE and LED_UNDERGLOW_ENABLE both 'yes')
|
||||||
|
endif
|
||||||
|
else ifeq ($(strip $(LED_UNDERGLOW_ENABLE)), yes)
|
||||||
|
RGBLIGHT_ENABLE = yes
|
||||||
|
else
|
||||||
|
RGBLIGHT_ENABLE = no
|
||||||
|
endif
|
||||||
|
|
||||||
|
ifeq ($(strip $(IOS_DEVICE_ENABLE)), yes)
|
||||||
|
OPT_DEFS += -DIOS_DEVICE_ENABLE
|
||||||
|
endif
|
||||||
|
|
||||||
|
ifeq ($(strip $(LED_ANIMATIONS)), yes)
|
||||||
|
# OPT_DEFS += -DRGBLIGHT_ANIMATIONS
|
||||||
|
OPT_DEFS += -DLED_ANIMATIONS
|
||||||
|
endif
|
||||||
|
|
||||||
|
ifeq ($(strip $(Link_Time_Optimization)),yes)
|
||||||
|
EXTRAFLAGS += -flto -DUSE_Link_Time_Optimization
|
||||||
|
endif
|
||||||
|
|
||||||
|
# Do not enable SLEEP_LED_ENABLE. it uses the same timer as BACKLIGHT_ENABLE
|
||||||
|
SLEEP_LED_ENABLE = no # Breathing sleep LED during USB suspend
|
||||||
|
|
||||||
|
# Uncomment these for debugging
|
||||||
|
# $(info -- RGBLIGHT_ENABLE=$(RGBLIGHT_ENABLE))
|
||||||
|
# $(info -- OPT_DEFS=$(OPT_DEFS))
|
||||||
|
# $(info )
|
||||||
|
|
||||||
@@ -16,44 +16,6 @@
|
|||||||
|
|
||||||
#include "%KEYBOARD%.h"
|
#include "%KEYBOARD%.h"
|
||||||
|
|
||||||
#ifdef RGBLIGHT_ENABLE
|
|
||||||
|
|
||||||
# include <string.h>
|
|
||||||
# include "i2c_master.h"
|
|
||||||
# include "rgblight.h"
|
|
||||||
|
|
||||||
extern rgblight_config_t rgblight_config;
|
|
||||||
|
|
||||||
void matrix_init_kb(void) {
|
|
||||||
i2c_init();
|
|
||||||
// call user level keymaps, if any
|
|
||||||
matrix_init_user();
|
|
||||||
}
|
|
||||||
|
|
||||||
// custom RGB driver
|
|
||||||
void rgblight_set(void) {
|
|
||||||
if (!rgblight_config.enable) {
|
|
||||||
memset(led, 0, 3 * RGBLED_NUM);
|
|
||||||
}
|
|
||||||
|
|
||||||
i2c_transmit(0xb0, (uint8_t*)led, 3 * RGBLED_NUM, 100);
|
|
||||||
}
|
|
||||||
|
|
||||||
bool rgb_init = false;
|
|
||||||
|
|
||||||
void matrix_scan_kb(void) {
|
|
||||||
// if LEDs were previously on before poweroff, turn them back on
|
|
||||||
if (rgb_init == false && rgblight_config.enable) {
|
|
||||||
i2c_transmit(0xb0, (uint8_t*)led, 3 * RGBLED_NUM, 100);
|
|
||||||
rgb_init = true;
|
|
||||||
}
|
|
||||||
|
|
||||||
rgblight_task();
|
|
||||||
matrix_scan_user();
|
|
||||||
}
|
|
||||||
|
|
||||||
#endif
|
|
||||||
|
|
||||||
// Optional override functions below.
|
// Optional override functions below.
|
||||||
// You can leave any or all of these undefined.
|
// You can leave any or all of these undefined.
|
||||||
// These are only required if you want to perform custom actions.
|
// These are only required if you want to perform custom actions.
|
||||||
|
|||||||
@@ -19,8 +19,6 @@ CONSOLE_ENABLE = yes
|
|||||||
COMMAND_ENABLE = yes
|
COMMAND_ENABLE = yes
|
||||||
BACKLIGHT_ENABLE = no
|
BACKLIGHT_ENABLE = no
|
||||||
RGBLIGHT_ENABLE = yes
|
RGBLIGHT_ENABLE = yes
|
||||||
RGBLIGHT_CUSTOM_DRIVER = yes
|
WS2812_DRIVER = i2c
|
||||||
|
|
||||||
OPT_DEFS = -DDEBUG_LEVEL=0
|
OPT_DEFS = -DDEBUG_LEVEL=0
|
||||||
|
|
||||||
SRC += i2c_master.c
|
|
||||||
@@ -20,6 +20,11 @@
|
|||||||
#include "timer.h"
|
#include "timer.h"
|
||||||
#include "uart.h"
|
#include "uart.h"
|
||||||
#include "debug.h"
|
#include "debug.h"
|
||||||
|
#include "rgblight_reconfig.h"
|
||||||
|
|
||||||
|
#if (defined(RGB_MIDI) | defined(RGBLIGHT_ANIMATIONS)) & defined(RGBLIGHT_ENABLE)
|
||||||
|
# include "rgblight.h"
|
||||||
|
#endif
|
||||||
|
|
||||||
#define UART_BAUD_RATE 115200
|
#define UART_BAUD_RATE 115200
|
||||||
|
|
||||||
@@ -94,6 +99,10 @@ int main(void) {
|
|||||||
// To prevent failing to configure NOT scan keyboard during configuration
|
// To prevent failing to configure NOT scan keyboard during configuration
|
||||||
if (usbConfiguration && usbInterruptIsReady()) {
|
if (usbConfiguration && usbInterruptIsReady()) {
|
||||||
keyboard_task();
|
keyboard_task();
|
||||||
|
|
||||||
|
#if defined(RGBLIGHT_ANIMATIONS) && defined(RGBLIGHT_ENABLE)
|
||||||
|
rgblight_task();
|
||||||
|
#endif
|
||||||
}
|
}
|
||||||
vusb_transfer_keyboard();
|
vusb_transfer_keyboard();
|
||||||
}
|
}
|
||||||
|
|||||||
Reference in new issue
Block a user