From 4d72aa428fb8dc72634bded428f78ffba2284fdc Mon Sep 17 00:00:00 2001 From: fauxpark Date: Fri, 9 Aug 2019 06:12:12 +1000 Subject: Improve backlight PWM pin support (#6202) * Improve backlight PWM pin support * I accidentally an equals sign * Another typo * Order by pin number * Throw an error if backlight pin is C4 or C5 on 16/32U4 * Use else for clarity * Minor alignment adjustments --- docs/getting_started_make_guide.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'docs/getting_started_make_guide.md') diff --git a/docs/getting_started_make_guide.md b/docs/getting_started_make_guide.md index 75eafd42cc..4fe3f184df 100644 --- a/docs/getting_started_make_guide.md +++ b/docs/getting_started_make_guide.md @@ -83,7 +83,7 @@ This allows the keyboard to tell the host OS that up to 248 keys are held down a `BACKLIGHT_ENABLE` -This enables your backlight on Timer1 and ports B5, B6, or B7 (for now). You can specify your port by putting this in your `config.h`: +This enables the in-switch LED backlighting. You can specify the backlight pin by putting this in your `config.h`: #define BACKLIGHT_PIN B7 -- cgit v1.2.3 From 51bcadf38cfccc08b287554ab17e21624abf55b8 Mon Sep 17 00:00:00 2001 From: Joel Challis Date: Sat, 24 Aug 2019 16:35:11 +0100 Subject: Add 'bootloadHID' flash target (#5587) * Add 'bootloadHID' flash target * Prep for flash target * Add :flash support * Align bootloader wait messages Co-Authored-By: Drashna Jaelre * Update template to suggest use of :flash --- docs/flashing.md | 30 ++++++++++++++++ docs/flashing_bootloadhid.md | 70 +++++++++++++++++++++++++++++++++++++ docs/getting_started_make_guide.md | 2 +- docs/newbs_flashing.md | 36 +++++++++++++++++++ quantum/template/ps2avrgb/readme.md | 35 +++---------------- tmk_core/avr.mk | 15 ++++++++ 6 files changed, 157 insertions(+), 31 deletions(-) create mode 100644 docs/flashing_bootloadhid.md (limited to 'docs/getting_started_make_guide.md') diff --git a/docs/flashing.md b/docs/flashing.md index d11dbdf15b..b47a5ebf8e 100644 --- a/docs/flashing.md +++ b/docs/flashing.md @@ -144,6 +144,36 @@ Flashing sequence: 3. Flash a .hex file 4. Reset the device into application mode (may be done automatically) +## BootloadHID + +BootloadHID is a USB bootloader for AVR microcontrollers. The uploader tool requires no kernel level driver on Windows and can therefore be run without installing any DLLs. + +To ensure compatibility with the bootloadHID bootloader, make sure this block is present your `rules.mk`: + + # Bootloader + # This definition is optional, and if your keyboard supports multiple bootloaders of + # different sizes, comment this out, and the correct address will be loaded + # automatically (+60). See bootloader.mk for all options. + BOOTLOADER = bootloadHID + +Compatible flashers: + +* [HIDBootFlash](http://vusb.wikidot.com/project:hidbootflash) (recommended Windows GUI) +* [bootloadhid Command Line](https://www.obdev.at/products/vusb/bootloadhid.html) / `:BootloadHID` in QMK (recommended command line) + +Flashing sequence: + +1. Enter the bootloader using any of the following methods: + * Tap the `RESET` keycode (may not work on all devices) + * Hold the salt key while plugging the keyboard in (usually documented within keyboard readme) +2. Wait for the OS to detect the device +3. Flash a .hex file +4. Reset the device into application mode (may be done automatically) + +or: + + make ::bootloadHID + ## STM32 All STM32 chips come preloaded with a factory bootloader that cannot be modified nor deleted. Some STM32 chips have bootloaders that do not come with USB programming (e.g. STM32F103) but the process is still the same. diff --git a/docs/flashing_bootloadhid.md b/docs/flashing_bootloadhid.md new file mode 100644 index 0000000000..c51d8ce4b8 --- /dev/null +++ b/docs/flashing_bootloadhid.md @@ -0,0 +1,70 @@ +# BootloadHID Flashing Instructions and Bootloader Information + +ps2avr(GB) boards use an ATmega32A microcontroller and a different bootloader. It is not flashable using the regular QMK methods. + +General flashing sequence: + +1. Enter the bootloader using any of the following methods: + * Tap the `RESET` keycode (may not work on all devices) + * Hold the salt key while plugging the keyboard in (usually documented within keyboard readme) +2. Wait for the OS to detect the device +3. Flash a .hex file +4. Reset the device into application mode (may be done automatically) + +## bootloadHID Flashing Target + +Using the QMK installation script, detailed [here](newbs_getting_started.md), the required bootloadHID tools should be automatically installed. + +To flash via the command line, use the target `:bootloadHID` by executing the following command: + + make ::bootloadHID + +## GUI Flashing + +### Windows +1. Download [HIDBootFlash](http://vusb.wikidot.com/project:hidbootflash). +2. Place your keyboard into reset. +3. Ensure the configured VendorID is `16c0` and ProductID is `05df` +4. Press the `Find Device` button and ensure that your keyboard is found. +5. Press the `Open .hex File` button and locate the `.hex` file you created. +6. Press the `Flash Device` button and wait for the process to complete. + +## Command Line Flashing + +1. Place your keyboard into reset. +2. Flash the board by typing `bootloadHID -r` followed by the path to your `.hex` file. + +### Windows Manual Installation +For MSYS2: +1. Download the BootloadHID firmware package from https://www.obdev.at/downloads/vusb/bootloadHID.2012-12-08.tar.gz. +2. Extract contents using a compatible tool, for example 7-Zip. +3. Add to the MSYS path by copying `commandline/bootloadHID.exe` from the extracted archive to your MSYS2 installation, typically `C:\msys64\usr\bin`. + +For native Windows flashing, the `bootloadHID.exe` can be used outside of the MSYS2 environment. + +### Linux Manual Installation +1. Install libusb development dependency: + ```bash + # This depends on OS - for Debian the following works + sudo apt-get install libusb-dev + ``` +2. Download the BootloadHID firmware package: + ``` + wget https://www.obdev.at/downloads/vusb/bootloadHID.2012-12-08.tar.gz -O - | tar -xz -C /tmp + ``` +3. Build the bootloadHID executable: + ``` + cd /tmp/bootloadHID.2012-12-08/commandline/ + make + sudo cp bootloadHID /usr/local/bin + ``` + +### MacOS Manual Installation +1. Install Homebrew by typing the following: + ``` + /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)" + ``` +2. Install the following packages: + ``` + brew install --HEAD https://raw.githubusercontent.com/robertgzr/homebrew-tap/master/bootloadhid.rb + ``` diff --git a/docs/getting_started_make_guide.md b/docs/getting_started_make_guide.md index 4fe3f184df..71e9d33f25 100644 --- a/docs/getting_started_make_guide.md +++ b/docs/getting_started_make_guide.md @@ -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`, `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. +* `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`. * `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. diff --git a/docs/newbs_flashing.md b/docs/newbs_flashing.md index c8a30dba05..3bf582d7f6 100644 --- a/docs/newbs_flashing.md +++ b/docs/newbs_flashing.md @@ -248,6 +248,42 @@ Programming..................................................................... 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 ::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) 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: diff --git a/quantum/template/ps2avrgb/readme.md b/quantum/template/ps2avrgb/readme.md index 1449b278cd..9d3ca0006f 100644 --- a/quantum/template/ps2avrgb/readme.md +++ b/quantum/template/ps2avrgb/readme.md @@ -12,35 +12,10 @@ Make example for this keyboard (after setting up your build environment): make %KEYBOARD%:default -Flashing - -ps2avr(GB) boards use an atmega32a microcontroller and a different bootloader. It is not flashable using the regular QMK methods. - -**Reset Key:** Hold down the key located at `K00`, commonly programmed as `Esc` while plugging in the keyboard. - -Windows: -1. Download [HIDBootFlash](http://vusb.wikidot.com/project:hidbootflash). -2. Place your keyboard into reset. -3. Press the `Find Device` button and ensure that your keyboard is found. -4. Press the `Open .hex File` button and locate the `.hex` file you created. -5. Press the `Flash Device` button and wait for the process to complete. - -macOS: -1. Install homebrew by typing the following: - ``` - /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)" - ``` -2. Install `crosspack-avr`. - ``` - brew cask install crosspack-avr - ``` -3. Install the following packages: - ``` - brew install python3 - pip3 install pyusb - brew install --HEAD https://raw.githubusercontent.com/robertgzr/homebrew-tap/master/bootloadhid.rb - ``` -4. Place your keyboard into reset. -5. Flash the board by typing `bootloadHID -r` followed by the path to your `.hex` file. +Flashing example for this keyboard ([after setting up the bootloadHID flashing environment](flashing_bootloadhid.md)) + + make %KEYBOARD%:default:flash + +**Reset Key**: Hold down the key located at *LOCATION*, commonly programmed as *KEY* while plugging in the keyboard. See the [build environment setup](https://docs.qmk.fm/#/getting_started_build_tools) and the [make instructions](https://docs.qmk.fm/#/getting_started_make_guide) for more information. Brand new to QMK? Start with our [Complete Newbs Guide](https://docs.qmk.fm/#/newbs). diff --git a/tmk_core/avr.mk b/tmk_core/avr.mk index e5443418b9..bdda14a070 100644 --- a/tmk_core/avr.mk +++ b/tmk_core/avr.mk @@ -246,6 +246,19 @@ endef usbasp: $(BUILD_DIR)/$(TARGET).hex check-size cpfirmware $(call EXEC_USBASP) +BOOTLOADHID_PROGRAMMER ?= bootloadHID + +define EXEC_BOOTLOADHID + # bootloadHid executable has no cross platform detect methods + # so keep running bootloadHid if the output contains "The specified device was not found" + until $(BOOTLOADHID_PROGRAMMER) -r $(BUILD_DIR)/$(TARGET).hex 2>&1 | tee /dev/stderr | grep -v "device was not found"; do\ + echo "Error: Bootloader not found. Trying again in 5s." ;\ + sleep 5 ;\ + done +endef + +bootloadHID: $(BUILD_DIR)/$(TARGET).hex check-size cpfirmware + $(call EXEC_BOOTLOADHID) # Convert hex to bin. bin: $(BUILD_DIR)/$(TARGET).hex @@ -331,6 +344,8 @@ else ifeq (dfu,$(findstring dfu,$(BOOTLOADER))) $(call EXEC_DFU) else ifeq ($(strip $(BOOTLOADER)), USBasp) $(call EXEC_USBASP) +else ifeq ($(strip $(BOOTLOADER)), bootloadHID) + $(call EXEC_BOOTLOADHID) else $(PRINT_OK); $(SILENT) || printf "&(MSG_FLASH_BOOTLOADER)" endif -- cgit v1.2.3 From b23f6011c34dcb471c312655f7af37c0a0f5f779 Mon Sep 17 00:00:00 2001 From: Amber Holly Date: Sat, 19 Oct 2019 02:14:49 +0100 Subject: Remove build option firmware size impacts (#6947) * Update rules.mk template to remove build option size impacts * Add rules.mk cleaning script * Update all rules.mk files to remove build option firmware size impact messages * Remove references to feature filesize in documentation * Revert "Update all rules.mk files to remove build option firmware size impact messages" This reverts commit 7cfe70976bcc223bf47c960b2e6af8596df80a32. * Fix regex in cleanup script and exclude keymaps/ directories * Update quantum/template/avr/rules.mk Fixed missing tabs/spaces. Co-Authored-By: fauxpark --- docs/config_options.md | 10 +++++----- docs/feature_hd44780.md | 8 ++++---- docs/feature_terminal.md | 4 ++-- docs/getting_started_make_guide.md | 8 +------- quantum/template/avr/rules.mk | 13 ++++++------- util/rules_cleaner.sh | 40 ++++++++++++++++++++++++++++++++++++++ 6 files changed, 58 insertions(+), 25 deletions(-) create mode 100755 util/rules_cleaner.sh (limited to 'docs/getting_started_make_guide.md') diff --git a/docs/config_options.md b/docs/config_options.md index ec3d1a1c8a..abd98ec8a8 100644 --- a/docs/config_options.md +++ b/docs/config_options.md @@ -310,13 +310,13 @@ This is a [make](https://www.gnu.org/software/make/manual/make.html) file that i Use these to enable or disable building certain features. The more you have enabled the bigger your firmware will be, and you run the risk of building a firmware too large for your MCU. * `BOOTMAGIC_ENABLE` - * Virtual DIP switch configuration(+1000) + * Virtual DIP switch configuration * `MOUSEKEY_ENABLE` - * Mouse keys(+4700) + * Mouse keys * `EXTRAKEY_ENABLE` - * Audio control and System control(+450) + * Audio control and System control * `CONSOLE_ENABLE` - * Console for debug(+400) + * Console for debug * `COMMAND_ENABLE` * Commands for debug and configuration * `COMBO_ENABLE` @@ -348,7 +348,7 @@ Use these to enable or disable building certain features. The more you have enab * `NO_USB_STARTUP_CHECK` * Disables usb suspend check after keyboard startup. Usually the keyboard waits for the host to wake it up before any tasks are performed. This is useful for split keyboards as one half will not get a wakeup call but must send commands to the master. * `LINK_TIME_OPTIMIZATION_ENABLE` - = Enables Link Time Optimization (`LTO`) when compiling the keyboard. This makes the process take longer, but can significantly reduce the compiled size (and since the firmware is small, the added time is not noticable). However, this will automatically disable the old Macros and Functions features automatically, as these break when `LTO` is enabled. It does this by automatically defining `NO_ACTION_MACRO` and `NO_ACTION_FUNCTION` + = Enables Link Time Optimization (`LTO`) when compiling the keyboard. This makes the process take longer, but can significantly reduce the compiled size (and since the firmware is small, the added time is not noticable). However, this will automatically disable the old Macros and Functions features automatically, as these break when `LTO` is enabled. It does this by automatically defining `NO_ACTION_MACRO` and `NO_ACTION_FUNCTION` ## USB Endpoint Limitations diff --git a/docs/feature_hd44780.md b/docs/feature_hd44780.md index e0838948a2..0a174035be 100644 --- a/docs/feature_hd44780.md +++ b/docs/feature_hd44780.md @@ -2,7 +2,7 @@ This is an integration of Peter Fleury's LCD library. This page will explain the basics. [For in depth documentation visit his page.](http://homepage.hispeed.ch/peterfleury/doxygen/avr-gcc-libraries/group__pfleury__lcd.html) -You can enable support for HD44780 Displays by setting the `HD44780_ENABLE` flag in your keyboards `rules.mk` to yes. This will use about 400 KB of extra space. +You can enable support for HD44780 Displays by setting the `HD44780_ENABLE` flag in your keyboards `rules.mk` to yes. ## Configuration @@ -26,7 +26,7 @@ Uncomment the section labled HD44780 and change the parameters as needed. #define LCD_DATA3_PORT LCD_PORT //< port for 4bit data bit 3 #define LCD_DATA0_PIN 4 //< pin for 4bit data bit 0 #define LCD_DATA1_PIN 5 //< pin for 4bit data bit 1 -#define LCD_DATA2_PIN 6 //< pin for 4bit data bit 2 +#define LCD_DATA2_PIN 6 //< pin for 4bit data bit 2 #define LCD_DATA3_PIN 7 //< pin for 4bit data bit 3 #define LCD_RS_PORT LCD_PORT //< port for RS line #define LCD_RS_PIN 3 //< pin for RS line @@ -39,14 +39,14 @@ Uncomment the section labled HD44780 and change the parameters as needed. Should you need to configure other properties you can copy them from `quantum/hd44780.h` and set them in your `config.h` -## Usage +## Usage To initialize your display, call `lcd_init()` with one of these parameters: ```` LCD_DISP_OFF : display off LCD_DISP_ON : display on, cursor off LCD_DISP_ON_CURSOR : display on, cursor on -LCD_DISP_ON_CURSOR_BLINK : display on, cursor on flashing +LCD_DISP_ON_CURSOR_BLINK : display on, cursor on flashing ```` This is best done in your keyboards `matrix_init_kb` or your keymaps `matrix_init_user`. It is advised to clear the display before use. diff --git a/docs/feature_terminal.md b/docs/feature_terminal.md index 1863599f84..f850622165 100644 --- a/docs/feature_terminal.md +++ b/docs/feature_terminal.md @@ -1,6 +1,6 @@ # Terminal -> This feature is currently *huge* at 4400 bytes, and should probably only be put on boards with a lot of memory, or for fun. +> This feature is currently *huge*, and should probably only be put on boards with a lot of memory, or for fun. The terminal feature is a command-line-like interface designed to communicate through a text editor with keystrokes. It's beneficial to turn off auto-indent features in your editor. @@ -56,7 +56,7 @@ Outputs the last 5 commands entered 1. help 2. about 3. keymap 0 -4. help +4. help 5. flush-buffer ``` diff --git a/docs/getting_started_make_guide.md b/docs/getting_started_make_guide.md index 71e9d33f25..d1ecf6f5a6 100644 --- a/docs/getting_started_make_guide.md +++ b/docs/getting_started_make_guide.md @@ -41,8 +41,6 @@ Set these variables to `no` to disable them, and `yes` to enable them. This allows you to hold a key and the salt key (space by default) and have access to a various EEPROM settings that persist over power loss. It's advised you keep this disabled, as the settings are often changed by accident, and produce confusing results that makes it difficult to debug. It's one of the more common problems encountered in help sessions. -Consumes about 1000 bytes. - `MOUSEKEY_ENABLE` This gives you control over cursor movements and clicks via keycodes/custom functions. @@ -67,8 +65,6 @@ 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. -Consumes about 400 bytes. - `COMMAND_ENABLE` This enables magic commands, typically fired with the default magic key combo `LSHIFT+RSHIFT+KEY`. Magic commands include turning on debugging messages (`MAGIC+D`) or temporarily toggling NKRO (`MAGIC+N`). @@ -125,11 +121,9 @@ Use this to debug changes to variable values, see the [tracing variables](unit_t This enables using the Quantum SYSEX API to send strings (somewhere?) -This consumes about 5390 bytes. - `KEY_LOCK_ENABLE` -This enables [key lock](feature_key_lock.md). This consumes an additional 260 bytes. +This enables [key lock](feature_key_lock.md). `SPLIT_KEYBOARD` diff --git a/quantum/template/avr/rules.mk b/quantum/template/avr/rules.mk index 0ed05e71b5..bb2bd14f9f 100644 --- a/quantum/template/avr/rules.mk +++ b/quantum/template/avr/rules.mk @@ -23,10 +23,10 @@ BOOTLOADER = atmel-dfu # Build Options # change yes to no to disable # -BOOTMAGIC_ENABLE = no # Virtual DIP switch configuration(+1000) -MOUSEKEY_ENABLE = yes # Mouse keys(+4700) -EXTRAKEY_ENABLE = yes # Audio control and System control(+450) -CONSOLE_ENABLE = yes # Console for debug(+400) +BOOTMAGIC_ENABLE = no # Virtual DIP switch configuration +MOUSEKEY_ENABLE = yes # Mouse keys +EXTRAKEY_ENABLE = yes # Audio control and System control +CONSOLE_ENABLE = yes # Console for debug COMMAND_ENABLE = yes # Commands for debug and configuration # Do not enable SLEEP_LED_ENABLE. it uses the same timer as BACKLIGHT_ENABLE SLEEP_LED_ENABLE = no # Breathing sleep LED during USB suspend @@ -34,9 +34,8 @@ SLEEP_LED_ENABLE = no # Breathing sleep LED during USB suspend NKRO_ENABLE = no # USB Nkey Rollover BACKLIGHT_ENABLE = no # Enable keyboard backlight functionality RGBLIGHT_ENABLE = no # Enable keyboard RGB underglow -MIDI_ENABLE = no # MIDI support (+2400 to 4200, depending on config) -UNICODE_ENABLE = no # Unicode +MIDI_ENABLE = no # MIDI support BLUETOOTH_ENABLE = no # Enable Bluetooth with the Adafruit EZ-Key HID AUDIO_ENABLE = no # Audio output on port C6 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 diff --git a/util/rules_cleaner.sh b/util/rules_cleaner.sh new file mode 100755 index 0000000000..ac27c2b09b --- /dev/null +++ b/util/rules_cleaner.sh @@ -0,0 +1,40 @@ +#!/bin/bash + +# This script finds all rules.mk files in keyboards/ subdirectories, +# and deletes the build option filesize impacts from them. + +# Print an error message with the word "ERROR" in red. +echo_error() { + echo -e "[\033[0;91mERROR\033[m]: $1" +} + +# If we've been started from util/, we want to be in qmk_firmware/ +[[ "$PWD" == *util ]] && cd .. + +# The root qmk_firmware/ directory should have a subdirectory called quantum/ +if [ ! -d "quantum" ]; then + echo_error "Could not detect the QMK firmware directory!" + echo_error "Are you sure you're in the right place?" + exit 1 +fi + +# Set the inplace editing parameter for sed. +# macOS/BSD sed expects a file extension immediately following -i. +set_sed_i() { + sed_i=(-i) + + case $(uname -a) in + *Darwin*) sed_i=(-i "") + esac +} +set_sed_i + +# Exclude keyamps/ directories +files=$(find keyboards -type f -name 'rules.mk' -not \( -path '*/keymaps*' -prune \)) + +# Edit rules.mk files +for file in $files; do + sed "${sed_i[@]}" -e "s/(+[0-9].*)$//g" "$file" +done + +echo "Cleaned up rules.mk files." -- cgit v1.2.3 From 0e6f78547eca1e7bbb093265e79c26a301e6635a Mon Sep 17 00:00:00 2001 From: Drashna Jaelre Date: Tue, 29 Oct 2019 13:15:03 -0700 Subject: [Docs] Update flashing information to include :flash target (#6999) * Update Newbs Flashing guide For the newbs that want to start flashing * Update flashing docs * Misc flashing * Attempt at flashing in french Lets hope I didn't butcher this too badly with machine transations * Update docs/feature_userspace.md * Apply language suggestions from code review * Apply suggestions from code review * Apply additional fr lang suggestions from code review * Apply suggestions from code review Co-Authored-By: fauxpark Co-Authored-By: Noan Mousy <4sstylz@protonmail.ch> Co-Authored-By: Xavier Hahn Co-Authored-By: Vincent LE GOFF --- docs/feature_userspace.md | 12 +---- docs/flashing.md | 13 +++-- docs/fr-FR/flashing.md | 11 ++-- docs/fr-FR/newbs_flashing.md | 103 ++++++++++++++++++++--------------- docs/getting_started_build_tools.md | 2 +- docs/getting_started_make_guide.md | 6 +-- docs/newbs_flashing.md | 105 +++++++++++++++++++++--------------- 7 files changed, 145 insertions(+), 107 deletions(-) (limited to 'docs/getting_started_make_guide.md') diff --git a/docs/feature_userspace.md b/docs/feature_userspace.md index 1cc8ca7425..e162d423ce 100644 --- a/docs/feature_userspace.md +++ b/docs/feature_userspace.md @@ -211,15 +211,7 @@ bool process_record_user(uint16_t keycode, keyrecord_t *record) { if ( (temp_mod | temp_osm) & MOD_MASK_SHIFT ) #endif { // - #if defined(__arm__) // only run for ARM boards - 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 + SEND_STRING(":flash"); } if ( (temp_mod | temp_osm) & MOD_MASK_CTRL) { 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 :`, 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. diff --git a/docs/flashing.md b/docs/flashing.md index 18ae6364d4..98841c1aac 100644 --- a/docs/flashing.md +++ b/docs/flashing.md @@ -99,11 +99,16 @@ or make ::avrdude -or if you want to flash multiple boards, use the following command - make ::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 @@ -231,7 +236,7 @@ Flashing sequence: 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-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. diff --git a/docs/fr-FR/flashing.md b/docs/fr-FR/flashing.md index f4379189a7..1aa04af5ff 100644 --- a/docs/fr-FR/flashing.md +++ b/docs/fr-FR/flashing.md @@ -99,11 +99,14 @@ ou, utilisez : make ::avrdude -ou, si vous vous voulez flasher plusieurs claviers, utilisez la commande suivante : +#### Commandes Caterina - make ::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 @@ -230,7 +233,7 @@ Séquence pour flasher: 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-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é. * `: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. diff --git a/docs/fr-FR/newbs_flashing.md b/docs/fr-FR/newbs_flashing.md index 401c524aca..267cf3add9 100644 --- a/docs/fr-FR/newbs_flashing.md +++ b/docs/fr-FR/newbs_flashing.md @@ -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 -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 ::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). @@ -207,11 +223,14 @@ Si vous avez un soucis, essayez de faire ceci: sudo make ::avrdude -En addition, si vous voulez flasher plusieurs boards, utilisez la commande suivante: +#### Commandes Caterina - make ::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 @@ -246,42 +265,6 @@ Programming..................................................................... 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 ::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) 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: @@ -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: -* `:dfu-util` - C'est l'option standard pour flasher un appareil STM32. -* `: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` - 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-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. +* `: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 ::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! diff --git a/docs/getting_started_build_tools.md b/docs/getting_started_build_tools.md index 268cc94c38..a55e903a6f 100644 --- a/docs/getting_started_build_tools.md +++ b/docs/getting_started_build_tools.md @@ -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: ```bash 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. diff --git a/docs/getting_started_make_guide.md b/docs/getting_started_make_guide.md index d1ecf6f5a6..d2596b2e2b 100644 --- a/docs/getting_started_make_guide.md +++ b/docs/getting_started_make_guide.md @@ -14,8 +14,8 @@ 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`, `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`. +* `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: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. 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 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 diff --git a/docs/newbs_flashing.md b/docs/newbs_flashing.md index 9c76f5592d..428e698e24 100644 --- a/docs/newbs_flashing.md +++ b/docs/newbs_flashing.md @@ -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 -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 ::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. @@ -216,11 +232,14 @@ If you have any issues with this, you may need to this: sudo make ::avrdude -Additionally, if you want to flash multiple boards, use the following command: +#### Caterina commands - make ::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 @@ -256,42 +275,6 @@ Programming..................................................................... 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 ::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) 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: -* `:dfu-util` - The default command for flashing to STM32 devices. -* `: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 ::dfu-util TIME_DELAY=5` +* `:dfu-util` - The default command for flashing to STM32 devices, and will wait until an STM32 bootloader 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-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 ::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! -- cgit v1.2.3