X-Git-Url: https://git.donarmstrong.com/?a=blobdiff_plain;f=docs%2Fgetting_started_make_guide.md;h=75eafd42ccca52cdb1f2c1c7b017f54b9cfa973f;hb=2a231457bd494079c36cf3e07c9b887016adb491;hp=ecf030d1dd1ebc9f51b3855dce8e4574e75c80f7;hpb=7b0356d1d49da6574570e110f61f95692afdb3d0;p=qmk_firmware.git diff --git a/docs/getting_started_make_guide.md b/docs/getting_started_make_guide.md index ecf030d1d..75eafd42c 100644 --- a/docs/getting_started_make_guide.md +++ b/docs/getting_started_make_guide.md @@ -4,7 +4,7 @@ The full syntax of the `make` command is `::`, * `` is the path of the keyboard, for example `planck` * Use `all` to compile all keyboards - * Specify the path to compile a revision, for example `planck/rev4` or `planck/rev3` + * Specify the path to compile a revision, for example `planck/rev4` or `planck/rev3` * If the keyboard doesn't have any folders, it can be left out * To compile the default folder, you can leave it out * `` is the name of the keymap, for example `algernon` @@ -14,7 +14,7 @@ The full syntax of the `make` command is `::`, The `` means the following * 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. -* `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 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. +* `dfu`, `teensy`, `avrdude` 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 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`. * `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. @@ -30,7 +30,7 @@ The make command itself also has some additional options, type `make --help` for 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 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. ## `rules.mk` Options @@ -53,9 +53,9 @@ This allows you to use the system and audio control key codes. `CONSOLE_ENABLE` -This allows you to print messages that can be read using [`hid_listen`](https://www.pjrc.com/teensy/hid_listen.html). +This allows you to print messages that can be read using [`hid_listen`](https://www.pjrc.com/teensy/hid_listen.html). -By default, all debug (*dprint*) print (*print*, *xprintf*), and user print (*uprint*) messages will be enabled. This will eat up a significant portion of the flash and may make the keyboard .hex file too big to program. +By default, all debug (*dprint*) print (*print*, *xprintf*), and user print (*uprint*) messages will be enabled. This will eat up a significant portion of the flash and may make the keyboard .hex file too big to program. To disable debug messages (*dprint*) and reduce the .hex file size, include `#define NO_DEBUG` in your `config.h` file. @@ -65,7 +65,7 @@ To disable print messages (*print*, *xprintf*) and **KEEP** user print messages To see the text, open `hid_listen` and enjoy looking at your printed messages. -**NOTE:** Do not include *uprint* messages in anything other than your keymap code. It must not be used within the QMK system framework. Otherwise, you will bloat other people's .hex files. +**NOTE:** Do not include *uprint* messages in anything other than your keymap code. It must not be used within the QMK system framework. Otherwise, you will bloat other people's .hex files. Consumes about 400 bytes. @@ -93,19 +93,17 @@ This enables MIDI sending and receiving with your keyboard. To enter MIDI send m `UNICODE_ENABLE` -This allows you to send unicode symbols via `UC()` in your keymap. Only codes up to 0x7FFF are currently supported. +This allows you to send Unicode characters using `UC()` in your keymap. Code points up to `0x7FFF` are supported. This covers characters for most modern languages, as well as symbols, but it doesn't cover emoji. `UNICODEMAP_ENABLE` -This allows sending unicode symbols using `X()` in your keymap. Codes -up to 0xFFFFFFFF are supported, including emojis. You will need to maintain -a separate mapping table in your keymap file. +This allows you to send Unicode characters using `X()` in your keymap. You will need to maintain a mapping table in your keymap file. All possible code points (up to `0x10FFFF`) are supported. -Known limitations: -- Under Mac OS, only codes up to 0xFFFF are supported. -- Under Linux ibus, only codes up to 0xFFFFF are supported (but anything important is still under this limit for now). +`UCIS_ENABLE` -Characters out of range supported by the OS will be ignored. +This allows you to send Unicode characters by inputting a mnemonic corresponding to the character you want to send. You will need to maintain a mapping table in your keymap file. All possible code points (up to `0x10FFFF`) are supported. + +For further details, as well as limitations, see the [Unicode page](feature_unicode.md). `BLUETOOTH_ENABLE` @@ -117,7 +115,7 @@ This allows you output audio on the C6 pin (needs abstracting). See the [audio p `FAUXCLICKY_ENABLE` -Uses buzzer to emulate clicky switches. A cheap imitation of the Cherry blue switches. By default, uses the C6 pin, same as AUDIO_ENABLE. +Uses buzzer to emulate clicky switches. A cheap imitation of the Cherry blue switches. By default, uses the C6 pin, same as `AUDIO_ENABLE`. `VARIABLE_TRACE` @@ -133,6 +131,22 @@ This consumes about 5390 bytes. This enables [key lock](feature_key_lock.md). This consumes an additional 260 bytes. +`SPLIT_KEYBOARD` + +This enables split keyboard support (dual MCU like the let's split and bakingpy's boards) and includes all necessary files located at quantum/split_common + +`SPLIT_TRANSPORT` + +As there is no standard split communication driver for ARM-based split keyboards yet, `SPLIT_TRANSPORT = custom` must be used for these. It will prevent the standard split keyboard communication code (which is AVR-specific) from being included, allowing a custom implementation to be used. + +`CUSTOM_MATRIX` + +Lets you replace the default matrix scanning routine with your own code. You will need to provide your own implementations of matrix_init() and matrix_scan(). + +`DEBOUNCE_TYPE` + +Lets you replace the default key debouncing routine with an alternative one. If `custom` you will need to provide your own implementation. + ## Customizing Makefile Options on a Per-Keymap Basis If your keymap directory has a file called `rules.mk` any options you set in that file will take precedence over other `rules.mk` options for your particular keyboard.