* [Planck](/keyboards/planck/)
* [Preonic](/keyboards/preonic/)
* [Atomic](/keyboards/atomic/)
-* [ErgoDox EZ](/keyboards/ergodox_ez/)
+* [ErgoDox EZ](/keyboards/ergodox/)
* [Clueboard](/keyboards/clueboard/)
* [Cluepad](/keyboards/cluepad/)
This is not a tiny project. While this is the main readme, there are many other files you might want to consult. Here are some points of interest:
-* The readme for your own keyboard: This is found under `keyboards/<your keyboards's name>/`. So for the ErgoDox EZ, it's [here](keyboards/ergodox_ez/); for the Planck, it's [here](keyboards/planck/) and so on.
+* The readme for your own keyboard: This is found under `keyboards/<your keyboards's name>/`. So for the ErgoDox EZ, it's [here](keyboards/ergodox/ez/); for the Planck, it's [here](keyboards/planck/) and so on.
* The list of possible keycodes you can use in your keymap is actually spread out in a few different places:
* [doc/keycode.txt](doc/keycode.txt) - an explanation of those same keycodes.
* [quantum/keymap.h](quantum/keymap.h) - this is where the QMK-specific aliases are all set up. Things like the Hyper and Meh key, the Leader key, and all of the other QMK innovations. These are also explained and documented below, but `keymap.h` is where they're actually defined.
## Build Environment Setup
+### Windows 10
+
+It's still recommended to use the method for Vista and later below. The reason for this is that the Windows 10 Subsystem for Linux lacks [USB support](https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-ubuntu-on-windo/suggestions/13355724-unable-to-access-usb-devices-from-bash), so it's not possible to flash the firmware to the keyboard. Please add your vote to the link!
+
+That said, it's still possible to use it for compilation. And recommended, if you need to compile much, since it's much faster than at least Cygwin (which is also supported, but currently lacking documentation). I haven't tried the method below, so I'm unable to tell.
+
+Here are the steps
+
+1. Install the Windows 10 subsystem for Linux, following [these instructions](http://www.howtogeek.com/249966/how-to-install-and-use-the-linux-bash-shell-on-windows-10/).
+2. If you have previously cloned the repository using the normal Git bash, you will need to clean up the line endings. If you have cloned it after 20th of August 2016, you are likely fine. To clean up the line endings do the following
+ 1. Make sure that you have no changes you haven't committed by running `git status`, if you do commit them first
+ 2. From within the Git bash run ´git rm --cached -r .`
+ 3. Followed by `git reset --hard`
+3. Start the "Bash On Ubuntu On Windows" from the start menu
+4. With the bash open, navigate to your git checkout. The harddisk can be accessed from `/mnt` for example `/mnt/c` for the `c:\` drive.
+5. Run `sudo util/install_dependencies.sh`.
+6. After a while the installation will finish, and you are good to go
+
+**Note** From time to time, the dependencies might change, so just run `install_dependencies.sh` again if things are not working.
+
+**Warning:** If you edit Makefiles or shell scripts, make sure you are using an editor that saves the files with Unix line endings. Otherwise the compilation might not work.
+
+
### Windows (Vista and later)
1. If you have ever installed WinAVR, uninstall it.
2. Install [MHV AVR Tools](https://infernoembedded.com/sites/default/files/project/MHV_AVR_Tools_20131101.exe). Disable smatch, but **be sure to leave the option to add the tools to the PATH checked**.
3. Install [DFU-Programmer][dfu-prog].
### Linux
-Install AVR GCC, AVR libc, and dfu-progammer with your favorite package manager.
+
+To ensure you are always up to date, you can just run `sudo utils/install_dependencies.sh`. That should always install all the dependencies needed.
+
+You can also install things manually, but this documentation might not be always up to date with all requirements.
+
+The current requirements are the following, but not all might be needed depending on what you do. Also note that some systems might not have all the dependencies available as packages, or they might be named differently.
+
+```
+build-essential
+gcc
+unzip
+wget
+zip
+gcc-avr
+binutils-avr
+avr-libc
+dfu-programmer
+dfu-util
+gcc-arm-none-eabi
+binutils-arm-none-eabi
+libnewlib-arm-none-eabi
+git
+```
+
+Install the dependencies with your favorite package manager.
Debian/Ubuntu example:
sudo apt-get update
- sudo apt-get install gcc-avr avr-libc dfu-programmer
+ sudo apt-get install gcc unzip wget zip gcc-avr binutils-avr avr-libc dfu-programmer dfu-util gcc-arm-none-eabi binutils-arm-none-eabi libnewlib-arm-none-eabi
### Docker
## The `make` command
-The `make` command is how you compile the firmware into a .hex file, which can be loaded by a dfu programmer (like dfu-progammer via `make dfu`) or the [Teensy loader](https://www.pjrc.com/teensy/loader.html) (only used with Teensys). You can run `make` from the root (`/`), your keyboard folder (`/keyboards/<keyboard>/`), or your keymap folder (`/keyboards/<keyboard>/keymaps/<keymap>/`) if you have a `Makefile` there (see the example [here](/doc/keymap_makefile_example.mk)).
+The `make` command is how you compile the firmware into a .hex file, which can be loaded by a dfu programmer (like dfu-progammer via `make dfu`) or the [Teensy loader](https://www.pjrc.com/teensy/loader.html) (only used with Teensys).
+
+**NOTE:** To abort a make command press `Ctrl-c`
+
+The following instruction refers to these folders.
+
+* The `root` (`/`) folder is the qmk_firmware folder, in which are `doc`, `keyboard`, `quantum`, etc.
+* The `keyboard` folder is any keyboard project's folder, like `/keyboards/planck`.
+* The `keymap` folder is any keymap's folder, like `/keyboards/planck/keymaps/default`.
+* The `subproject` folder is the subproject folder of a keyboard, like `/keyboards/ergodox/ez`
+
+### Simple instructions for building and uploading a keyboard
+
+**Most keyboards have more specific instructions in the keyboard specific readme.md file, so please check that first**
+
+If the `keymap` folder contains a file name `Makefile`
+
+1. Change the directory to the `keymap` folder
+2. Run `make <subproject>-<programmer>`
+
+Otherwise, if there's no `Makefile` in the `keymap` folder
+
+1. Enter the `keyboard` folder
+2. Run `make <subproject>-<keymap>-<programmer>`
+
+In the above commands, replace:
+
+* `<keymap>` with the name of your keymap
+* `<subproject>` with the name of the subproject (revision or sub-model of your keyboard). For example, for Ergodox it can be `ez` or `infinity`, and for Planck `rev3` or `rev4`.
+ * If the keyboard doesn't have a subproject, or if you are happy with the default (defined in `rules.mk` file of the `keyboard` folder), you can leave it out. But remember to also remove the dash (`-`) from the command.
+* `<programmer>` The programmer to use. Most keyboards use `dfu`, but some use `teensy`. Infinity keyboards use `dfu-util`. Check the readme file in the keyboard folder to find out which programmer to use.
+ * If you don't add `-<programmer` to the command line, the firmware will be still be compiled into a hex file, but the upload will be skipped.
-By default, this will generate a `<keyboard>_<keymap>.hex` file in whichever folder you run `make` from. These files are ignored by git, so don't worry about deleting them when committing/creating pull requests.
+**NOTE:** Some operating systems will refuse to program unless you run the make command as root for example `sudo make dfu`
-Below are some definitions that will be useful:
+### More detailed make instruction
-* The "root" (`/`) folder is the qmk_firmware folder, in which are `doc`, `keyboard`, `quantum`, etc.
-* The "keyboard" folder is any keyboard project's folder, like `/keyboards/planck`.
-* The "keymap" folder is any keymap's folder, like `/keyboards/planck/keymaps/default`.
+The full syntax of the `make` command is the following, but parts of the command can be left out if you run it from other directories than the `root` (as you might already have noticed by reading the simple instructions).
-Below is a list of the useful `make` commands in QMK:
+`<keyboard>-<subproject>-<keymap>-<target>`, where:
-* `make` - builds your keyboard and keymap depending on which folder you're in. This defaults to the "default" layout (unless in a keymap folder), and Planck keyboard in the root folder
- * `make keyboard=<keyboard>` - specifies the keyboard (only to be used in root)
- * `make keymap=<keymap>` - specifies the keymap (only to be used in root and keyboard folder - not needed when in keymap folder)
-* `make clean` - cleans the `.build` folder, ensuring that everything is re-built
-* `make dfu` - (requires dfu-programmer) builds and flashes the keymap to your keyboard once placed in reset/dfu mode (button or press `KC_RESET`). This does not work for Teensy-based keyboards like the ErgoDox EZ.
- * `keyboard=` and `keymap=` are compatible with this
-* `make all-keyboards` - builds all keymaps for all keyboards and outputs status of each (use in root)
-* `make all-keyboards-default` - builds all default keymaps for all keyboards and outputs status of each (use in root)
-* `make all-keymaps [keyboard=<keyboard>]` - builds all of the keymaps for whatever keyboard folder you're in, or specified by `<keyboard>`
-* `make all-keyboards-*`, `make all-keyboards-default-*` and `make all-keymaps-* [keyboard=<keyboard>]` - like the normal "make-all-*" commands, but the last string aftter the `-` (for example clean) is passed to the keyboard make command.
-Other, less useful functionality:
+* `<keyboard>` is the name of the keyboard, for example `planck`
+ * Use `allkb` to compile all keyboards
+* `<subproject>` is the name of the subproject (revision or sub-model of the keyboard). For example, for Ergodox it can be `ez` or `infinity`, and for Planck `rev3` or `rev4`.
+ * If the keyboard doesn't have any subprojects, it can be left out
+ * To compile the default subproject, you can leave it out, or specify `defaultsp`
+ * Use `allsp` to compile all subprojects
+* `<keymap>` is the name of the keymap, for example `algernon`
+ * Use `allkm` to compile all keymaps
+* `<target>` will be explained in more detail below.
+
+**Note:** When you leave some parts of the command out, you should also remove the dash (`-`).
+
+As mentioned above, there are some shortcuts, when you are in a:
+
+* `keyboard` folder, the command will automatically fill the `<keyboard>` part. So you only need to type `<subproject>-<keymap>-<target>`
+* `subproject` folder, it will fill in both `<keyboard>` and `<subproject>`
+* `keymap` folder, then `<keyboard>` and `<keymap>` will be filled in. If you need to specify the `<subproject>` use the following syntax `<subproject>-<target>`
+ * Note in order to support this shortcut, the keymap needs its own Makefile (see the example [here](/doc/keymap_makefile_example.mk))
+* `keymap` folder of a `subproject`, then everything except the `<target>` will be filled in
+
+The `<target>` means the following
+* If no target is given, then it's the same as `all` below
+* `all` compiles the keyboard and generates a `<keyboard>_<keymap>.hex` file in whichever folder you run `make` from. These files are ignored by git, so don't worry about deleting them when committing/creating pull requests.
+* `dfu`, `teensy` or `dfu-util`, 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 Infinity 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** that some operating systems needs root access for these commands to work, so in that case you need to run for example `sudo make dfu`.
+* `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.
+
+Some other targets are supported but, but not important enough to be documented here. Check the source code of the make files for more information.
+
+You can also add extra options at the end of the make command line, after the target
* `make COLOR=false` - turns off color output
* `make SILENT=true` - turns off output besides errors/warnings
-* `make VERBOSE=true` - outputs all of the avr-gcc stuff (not interesting)
+* `make VERBOSE=true` - outputs all of the gcc stuff (not interesting, unless you need to debug)
+
+The make command itself also has some additional options, type `make --help` for more information. The most useful is probably `-jx`, which specifies that you want to compile using more than one CPU, the `x` represents the number of CPUs that you want to use. Setting that can greatly reduce the compile times, especially if you are compiling many keyboards/keymaps. I usually set it to one less than the number of CPUs that I have, so that I have some left for doing other things while it's compiling. Note that not all operating systems and make versions supports that option.
+
+Here are some examples commands
+
+* `make allkb-allsp-allkm` builds everything (all keyboards, all subprojects, all keymaps). Running just `make` from the `root` will also run this.
+* `make` from within a `keyboard` directory, is the same as `make keyboard-allsp-allkm`, which compiles all subprojects and keymaps of the keyboard. **NOTE** that this behaviour has changed. Previously it compiled just the default keymap.
+* `make ergodox-infinity-algernon-clean` will clean the build output of the Ergodox Infinity keyboard. This example uses the full syntax and can be run from any folder with a `Makefile`
+* `make dfu COLOR=false` from within a keymap folder, builds and uploads the keymap, but without color output.
## The `Makefile`
-There are 3 different `make` and `Makefile` locations:
+There are 5 different `make` and `Makefile` locations:
* root (`/`)
* keyboard (`/keyboards/<keyboard>/`)
* keymap (`/keyboards/<keyboard>/keymaps/<keymap>/`)
+* subproject (`/keyboards/<keyboard>/<subproject>`)
+* subproject keymap (`/keyboards/<keyboard>/<subproject>/keymaps/<keymap>`)
+
+The root contains the code used to automatically figure out which keymap or keymaps to compile based on your current directory and commandline arguments. It's considered stable, and shouldn't be modified. The keyboard one will contain the MCU set-up and default settings for your keyboard, and shouldn't be modified unless you are the producer of that keyboard. The keymap Makefile can be modified by users, and is optional. It is included automatically if it exists. You can see an example [here](/doc/keymap_makefile_example.mk) - the last few lines are the most important. The settings you set here will override any defaults set in the keyboard Makefile. **The file is required if you want to run `make` in the keymap folder.**
-The root contains the code used to automatically figure out which keymap or keymaps to compile based on your current directory and commandline arguments. It's considered stable, and shouldn't be modified. The keyboard one will contain the MCU set-up and default settings for your keyboard, and shouldn't be modified unless you are the producer of that keyboard. The keymap Makefile can be modified by users, and is optional. It is included automatically if it exists. You can see an example [here](/doc/keymap_makefile_example.mk) - the last few lines are the most important. The settings you set here will override any defaults set in the keyboard Makefile. **It is required if you want to run `make` in the keymap folder.**
+For keyboards and subprojects, the make files are split in two parts `Makefile` and `rules.mk`. All settings can be found in the `rules.mk` file, while the `Makefile` is just there for support and including the root `Makefile`. Keymaps contain just one `Makefile` for simplicity.
### Makefile options
};
//Tap Dance Definitions
-const qk_tap_dance_action_t tap_dance_actions[] = {
+qk_tap_dance_action_t tap_dance_actions[] = {
//Tap once for Esc, twice for Caps Lock
[TD_ESC_CAPS] = ACTION_TAP_DANCE_DOUBLE(KC_ESC, KC_CAPS)
// Other declarations would go here, separated by commas, if you have them
ergodox_right_led_3_off();
}
-const qk_tap_dance_action_t tap_dance_actions[] = {
+qk_tap_dance_action_t tap_dance_actions[] = {
[CT_SE] = ACTION_TAP_DANCE_DOUBLE (KC_SPC, KC_ENT)
,[CT_CLN] = ACTION_TAP_DANCE_FN_ADVANCED (NULL, dance_cln_finished, dance_cln_reset)
,[CT_EGG] = ACTION_TAP_DANCE_FN (dance_egg)
And then, to assign this macro to a key on your keyboard layout, you just use `M(0)` on the key you want to press for copy/paste.
+## Dynamic macros: record and replay macros in runtime
+
+In addition to the static macros described above, you may enable the dynamic macros which you may record while writing. They are forgotten as soon as the keyboard is unplugged. Only two such macros may be stored at the same time, with the total length of 128 keypresses.
+
+To enable them, first add a new element to the `planck_keycodes` enum -- `DYNAMIC_MACRO_RANGE`:
+
+ enum planck_keycodes {
+ QWERTY = SAFE_RANGE,
+ COLEMAK,
+ DVORAK,
+ PLOVER,
+ LOWER,
+ RAISE,
+ BACKLIT,
+ EXT_PLV,
+ DYNAMIC_MACRO_RANGE,
+ };
+
+Afterwards create a new layer called `_DYN`:
+
+ #define _DYN 6 /* almost any other free number should be ok */
+
+Below these two modifications include the `dynamic_macro.h` header:
+
+ #include "dynamic_macro.h"`
+
+Then define the `_DYN` layer with the following keys: `DYN_REC_START1`, `DYN_MACRO_PLAY1`,`DYN_REC_START2` and `DYN_MACRO_PLAY2`. It may also contain other keys, it doesn't matter apart from the fact that you won't be able to record these keys in the dynamic macros.
+
+ [_DYN]= {
+ {_______, DYN_REC_START1, DYN_MACRO_PLAY1, _______, _______, _______, _______, _______, _______, _______, _______, _______},
+ {_______, DYN_REC_START2, DYN_MACRO_PLAY2, _______, _______, _______, _______, _______, _______, _______, _______, _______},
+ {_______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______},
+ {_______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______}
+ },
+
+Add the following code to the very beginning of your `process_record_user()` function:
+
+ if (!process_record_dynamic_macro(keycode, record)) {
+ return false;
+ }
+
+To start recording the macro, press either `DYN_REC_START1` or `DYN_REC_START2`. To finish the recording, press the `_DYN` layer button. The handler awaits specifically for the `MO(_DYN)` keycode as the "stop signal" so please don't use any fancy ways to access this layer, use the regular `MO()` modifier. To replay the macro, press either `DYN_MACRO_PLAY1` or `DYN_MACRO_PLAY2`.
+
+If the LED-s start blinking during the recording with each keypress, it means there is no more space for the macro in the macro buffer. To fit the macro in, either make the other macro shorter (they share the same buffer) or increase the buffer size by setting the `DYNAMIC_MACRO_SIZE` preprocessor macro (default value: 256; please read the comments for it in the header).
+
+For the details about the internals of the dynamic macros, please read the comments in the `dynamic_macro.h` header.
+
## Additional keycode aliases for software-implemented layouts (Colemak, Dvorak, etc)
Everything is assuming you're in Qwerty (in software) by default, but there is built-in support for using a Colemak or Dvorak layout by including this at the top of your keymap:
projects / qmk_firmware.git / blobdiff