aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorTycho Andersen <tycho@tycho.ws>2018-12-09 11:04:58 -0700
committerTycho Andersen <tycho@tycho.ws>2018-12-09 11:04:58 -0700
commit852566ee1c0d79643ea2940bd769757fb6d72a0c (patch)
treec80a6a07409fadd27bbef74584f517a0440d451e
parentd9363b37815279e5004106345d93f19d584db2a2 (diff)
downloadModel01-Firmware-852566ee1c0d79643ea2940bd769757fb6d72a0c.tar.gz
Model01-Firmware-852566ee1c0d79643ea2940bd769757fb6d72a0c.zip
add a blurb about binding the PROG key to things
Signed-off-by: Tycho Andersen <tycho@tycho.ws>
-rw-r--r--Model01-Firmware.ino8
1 files changed, 7 insertions, 1 deletions
diff --git a/Model01-Firmware.ino b/Model01-Firmware.ino
index 66701a5..951e24c 100644
--- a/Model01-Firmware.ino
+++ b/Model01-Firmware.ino
@@ -108,9 +108,15 @@ enum { MACRO_VERSION_INFO,
* using ___ to let keypresses fall through to the previously active layer
* using XXX to mark a keyswitch as 'blocked' on this layer
* using ShiftToLayer() and LockLayer() keys to change the active keymap.
- * the special nature of the PROG key
* keeping NUM and FN consistent and accessible on all layers
*
+ * The PROG key is special, since it is how you indicate to the board that you
+ * want to flash the firmware. However, it can be remapped to a regular key.
+ * When the keyboard boots, it first looks to see whether the PROG key is held
+ * down; if it is, it simply awaits further flashing instructions. If it is
+ * not, it continues loading the rest of the firmware and the keyboard
+ * functions normally, with whatever binding you have set to PROG. More detail
+ * here: https://community.keyboard.io/t/how-the-prog-key-gets-you-into-the-bootloader/506/8
*
* The "keymaps" data structure is a list of the keymaps compiled into the firmware.
* The order of keymaps in the list is important, as the ShiftToLayer(#) and LockLayer(#)