format code according to conventions [skip ci]

* fixed strange space cadet timer owerflow on STM32F103

* Moved elapsed time fix to timer.c

.travis.yml

@@ -12,6 +12,18 @@ env:
   - MAKEFLAGS="-j3 --output-sync"
 services:
   - docker
+addons:
+  apt:
+    sources:
+      - ubuntu-toolchain-r-test
+      - llvm-toolchain-trusty-7
+    packages:
+    - pandoc
+    - diffutils
+    - dos2unix
+    - doxygen
+    - clang-format-7
+    - libstdc++-7-dev
 install:
   - npm install -g moxygen
 script:
@@ -20,13 +32,6 @@ script:
   - bash util/travis_test.sh
   - bash util/travis_build.sh
   - bash util/travis_docs.sh
-addons:
-  apt:
-    packages:
-    - pandoc
-    - diffutils
-    - dos2unix
-    - doxygen
 after_script:
   bash util/travis_compiled_push.sh
 notifications:

common_features.mk

@@ -102,6 +102,57 @@ ifeq ($(strip $(UNICODE_COMMON)), yes)
     SRC += $(QUANTUM_DIR)/process_keycode/process_unicode_common.c
 endif
 
+VALID_EEPROM_DRIVER_TYPES := vendor custom transient i2c
+EEPROM_DRIVER ?= vendor
+ifeq ($(filter $(EEPROM_DRIVER),$(VALID_EEPROM_DRIVER_TYPES)),)
+  $(error EEPROM_DRIVER="$(EEPROM_DRIVER)" is not a valid EEPROM driver)
+else
+  OPT_DEFS += -DEEPROM_ENABLE
+  ifeq ($(strip $(EEPROM_DRIVER)), custom)
+    OPT_DEFS += -DEEPROM_DRIVER -DEEPROM_CUSTOM
+    COMMON_VPATH += $(DRIVER_PATH)/eeprom
+    SRC += eeprom_driver.c
+  else ifeq ($(strip $(EEPROM_DRIVER)), i2c)
+    OPT_DEFS += -DEEPROM_DRIVER -DEEPROM_I2C
+    COMMON_VPATH += $(DRIVER_PATH)/eeprom
+    QUANTUM_LIB_SRC += i2c_master.c
+    SRC += eeprom_driver.c eeprom_i2c.c
+  else ifeq ($(strip $(EEPROM_DRIVER)), transient)
+    OPT_DEFS += -DEEPROM_DRIVER -DEEPROM_TRANSIENT
+    COMMON_VPATH += $(DRIVER_PATH)/eeprom
+    SRC += eeprom_driver.c eeprom_transient.c
+  else ifeq ($(strip $(EEPROM_DRIVER)), vendor)
+    OPT_DEFS += -DEEPROM_VENDOR
+    ifeq ($(PLATFORM),AVR)
+      # Automatically provided by avr-libc, nothing required
+    else ifeq ($(PLATFORM),CHIBIOS)
+      ifeq ($(MCU_SERIES), STM32F3xx)
+        SRC += $(PLATFORM_COMMON_DIR)/eeprom_stm32.c
+        SRC += $(PLATFORM_COMMON_DIR)/flash_stm32.c
+        OPT_DEFS += -DEEPROM_EMU_STM32F303xC
+        OPT_DEFS += -DSTM32_EEPROM_ENABLE
+      else ifeq ($(MCU_SERIES), STM32F1xx)
+        SRC += $(PLATFORM_COMMON_DIR)/eeprom_stm32.c
+        SRC += $(PLATFORM_COMMON_DIR)/flash_stm32.c
+        OPT_DEFS += -DEEPROM_EMU_STM32F103xB
+        OPT_DEFS += -DSTM32_EEPROM_ENABLE
+      else ifeq ($(MCU_SERIES)_$(MCU_LDSCRIPT), STM32F0xx_STM32F072xB)
+        SRC += $(PLATFORM_COMMON_DIR)/eeprom_stm32.c
+        SRC += $(PLATFORM_COMMON_DIR)/flash_stm32.c
+        OPT_DEFS += -DEEPROM_EMU_STM32F072xB
+        OPT_DEFS += -DSTM32_EEPROM_ENABLE
+      else
+        # This will effectively work the same as "transient" if not supported by the chip
+        SRC += $(PLATFORM_COMMON_DIR)/eeprom_teensy.c
+      endif
+    else ifeq ($(PLATFORM),ARM_ATSAM)
+      SRC += $(PLATFORM_COMMON_DIR)/eeprom.c
+    else ifeq ($(PLATFORM),TEST)
+      SRC += $(PLATFORM_COMMON_DIR)/eeprom.c
+    endif
+  endif
+endif
+
 ifeq ($(strip $(RGBLIGHT_ENABLE)), yes)
     POST_CONFIG_H += $(QUANTUM_DIR)/rgblight_post_config.h
     OPT_DEFS += -DRGBLIGHT_ENABLE
@@ -124,7 +175,9 @@ ifneq ($(strip $(LED_MATRIX_ENABLE)), no)
     ifeq ($(filter $(LED_MATRIX_ENABLE),$(VALID_MATRIX_TYPES)),)
         $(error LED_MATRIX_ENABLE="$(LED_MATRIX_ENABLE)" is not a valid matrix type)
     else
-        OPT_DEFS += -DLED_MATRIX_ENABLE -DBACKLIGHT_ENABLE -DBACKLIGHT_CUSTOM_DRIVER
+        BACKLIGHT_ENABLE = yes
+        BACKLIGHT_DRIVER = custom
+        OPT_DEFS += -DLED_MATRIX_ENABLE
         SRC += $(QUANTUM_DIR)/led_matrix.c
         SRC += $(QUANTUM_DIR)/led_matrix_drivers.c
     endif
@@ -249,10 +302,6 @@ ifeq ($(strip $(BACKLIGHT_ENABLE)), yes)
         $(error BACKLIGHT_DRIVER="$(BACKLIGHT_DRIVER)" is not a valid backlight type)
     endif
 
-    ifeq ($(strip $(VISUALIZER_ENABLE)), yes)
-        CIE1931_CURVE := yes
-    endif
-
     COMMON_VPATH += $(QUANTUM_DIR)/backlight
     SRC += $(QUANTUM_DIR)/backlight/backlight.c
     OPT_DEFS += -DBACKLIGHT_ENABLE
@@ -292,6 +341,10 @@ ifeq ($(strip $(WS2812_DRIVER_REQUIRED)), yes)
     endif
 endif
 
+ifeq ($(strip $(VISUALIZER_ENABLE)), yes)
+    CIE1931_CURVE := yes
+endif
+
 ifeq ($(strip $(CIE1931_CURVE)), yes)
     OPT_DEFS += -DUSE_CIE1931_CURVE
     LED_TABLES := yes
@@ -418,9 +471,17 @@ ifeq ($(strip $(SPLIT_KEYBOARD)), yes)
         QUANTUM_SRC += $(QUANTUM_DIR)/split_common/transport.c
         # Functions added via QUANTUM_LIB_SRC are only included in the final binary if they're called.
         # Unused functions are pruned away, which is why we can add multiple drivers here without bloat.
-        QUANTUM_LIB_SRC += $(QUANTUM_DIR)/split_common/serial.c \
-                           i2c_master.c \
-                           i2c_slave.c
+        ifeq ($(PLATFORM),AVR)
+            QUANTUM_LIB_SRC += i2c_master.c \
+                               i2c_slave.c
+        endif
+
+        SERIAL_DRIVER ?= bitbang
+        ifeq ($(strip $(SERIAL_DRIVER)), bitbang)
+            QUANTUM_LIB_SRC += serial.c
+        else
+            QUANTUM_LIB_SRC += serial_$(strip $(SERIAL_DRIVER)).c
+        endif
     endif
     COMMON_VPATH += $(QUANTUM_PATH)/split_common
 endif

docs/_summary.md

@@ -18,6 +18,7 @@
   * [Getting Help](getting_started_getting_help.md)
 
 * [Breaking Changes](breaking_changes.md)
+  * [My Pull Request Was Flagged](breaking_changes_instructions.md)
   * [2019 Aug 30](ChangeLog/20190830.md)
 
 * [FAQ](faq.md)
@@ -104,6 +105,7 @@
   * [ADC Driver](adc_driver.md)
   * [I2C Driver](i2c_driver.md)
   * [WS2812 Driver](ws2812_driver.md)
+  * [EEPROM Driver](eeprom_driver.md)
   * [GPIO Controls](internals_gpio_control.md)
   * [Custom Matrix](custom_matrix.md)
   * [Proton C Conversion](proton_c_conversion.md)

docs/breaking_changes_instructions.md

@@ -0,0 +1,42 @@
+# Breaking Changes: My Pull Request Was Flagged
+
+A QMK member may have replied to your pull request stating that your submission is a breaking change. In their judgment, the changes you have proposed have greater implications for either QMK, or its users.
+
+Some things that may cause a pull request to be flagged are:
+
+- **Edits to User Keymaps**
+  A user may submit their keymap to QMK, then some time later open a pull request with further updates, only to find it can't be merged because it was edited in the `qmk/qmk_firmware` repository. As not all users are proficient at using Git or GitHub, the user may find themself unable to fix the issue on their own.
+- **Changes to Expected Behavior**
+  Changes to QMK behavior may cause users to believe their hardware or QMK is broken if they flash new firmware that incorporates changes to existing QMK features, and find themselves without a means to restore the desired behavior.
+- **Changes Requiring User Action**
+  Changes may also require action to be taken by users, such as updating a toolchain or taking some action in Git.
+- **Changes Necessitating Increased Scrutiny**
+  On occasion, a submission may have implications for QMK as a project. This could be copyright/licensing issues, coding conventions, large feature overhauls, "high-risk" changes that need wider testing by our community, or something else entirely.
+- **Changes Requiring Communication to End Users**
+  This includes warnings about future deprecations, outdated practices, and anything else that needs to be communicated but doesn't fit into one of the above categories.
+
+## What Do I Do?
+
+If it is determined that your submission is a breaking change, there are a few things you can do to smooth the process:
+
+### Consider Splitting Up Your PR
+
+If you are contributing core code, and the only reason it needs to go through breaking changes is that you are updating keymaps to match your change, consider whether you can submit your feature in a way that the old keymaps continue to work. Then submit a separate PR that goes through the breaking changes process to remove the old code.
+
+### Contribute a ChangeLog Entry
+
+We require submissions that go through the Breaking Change process to include a changelog entry. The entry should be a short summary of the changes your pull request makes – [each section here started as a changelog](ChangeLog/20190830.md "n.b. This should link to the 2019 Aug 30 Breaking Changes doc  - @noroadsleft").
+
+Your changelog should be located at `docs/ChangeLog/YYYYMMDD/PR####.md`, where `YYYYMMDD` is the date on which QMK's breaking change branch – usually named `future` – will be merged into the `master` branch, and `####` is the number of your pull request.
+
+If your submission requires action on the part of users, your changelog should instruct users what action(s) must be taken, or link to a location that does so.
+
+### Document Your Changes
+
+Understanding the purpose for your submission, and possible implications or actions it will require can make the review process more straightforward. A changelog may suffice for this purpose, but more extensive changes may require a level of detail that is ill-suited for a changelog.
+
+Commenting on your pull request and being responsive to questions, comments, and change requests is much appreciated.
+
+### Ask for Help
+
+Having your submission flagged may have caught you off guard. If you find yourself intimidated or overwhelmed, let us know. Comment on your pull request, or [reach out to the QMK team on Discord](https://discord.gg/Uq7gcHh).

docs/cli.md

@@ -141,14 +141,28 @@ qmk docs [-p PORT]
 
 ## `qmk doctor`
 
-This command examines your environment and alerts you to potential build or flash problems.
+This command examines your environment and alerts you to potential build or flash problems. It can fix many of them if you want it to.
 
 **Usage**:
 
 ```
-qmk doctor
+qmk doctor [-y] [-n]
 ```
 
+**Examples**:
+
+Check your environment for problems and prompt to fix them:
+
+    qmk doctor
+
+Check your environment and automatically fix any problems found:
+
+    qmk doctor -y
+
+Check your environment and report problems only:
+
+    qmk doctor -n
+
 ## `qmk json-keymap`
 
 Creates a keymap.c from a QMK Configurator export.

docs/eeprom_driver.md

@@ -0,0 +1,50 @@
+# EEPROM Driver Configuration
+
+The EEPROM driver can be swapped out depending on the needs of the keyboard, or whether extra hardware is present.
+
+Driver                      | Description
+--------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
+`EEPROM_DRIVER = vendor`    | Uses the on-chip driver provided by the chip manufacturer. For AVR, this is provided by avr-libc. This is supported on ARM for a subset of chips -- STM32F3xx, STM32F1xx, and STM32F072xB will be emulated by writing to flash. Other chips will generally act as "transient" below.
+`EEPROM_DRIVER = i2c`       | Supports writing to I2C-based 24xx EEPROM chips. See the driver section below.
+`EEPROM_DRIVER = transient` | Fake EEPROM driver -- supports reading/writing to RAM, and will be discarded when power is lost.
+
+## Vendor Driver Configuration
+
+No configurable options are available.
+
+## I2C Driver Configuration
+
+Currently QMK supports 24xx-series chips over I2C. As such, requires a working i2c_master driver configuration. You can override the driver configuration via your config.h:
+
+`config.h` override                         | Description                                                                         | Default Value
+------------------------------------------- | ----------------------------------------------------------------------------------- | ------------------------------------
+`#define EXTERNAL_EEPROM_I2C_BASE_ADDRESS`  | Base I2C address for the EEPROM -- shifted left by 1 as per i2c_master requirements | 0b10100000
+`#define EXTERNAL_EEPROM_I2C_ADDRESS(addr)` | Calculated I2C address for the EEPROM                                               | `(EXTERNAL_EEPROM_I2C_BASE_ADDRESS)`
+`#define EXTERNAL_EEPROM_BYTE_COUNT`        | Total size of the EEPROM in bytes                                                   | 8192
+`#define EXTERNAL_EEPROM_PAGE_SIZE`         | Page size of the EEPROM in bytes, as specified in the datasheet                     | 32
+`#define EXTERNAL_EEPROM_ADDRESS_SIZE`      | The number of bytes to transmit for the memory location within the EEPROM           | 2
+`#define EXTERNAL_EEPROM_WRITE_TIME`        | Write cycle time of the EEPROM, as specified in the datasheet                       | 5
+
+Default values and extended descriptions can be found in `drivers/eeprom/eeprom_i2c.h`.
+
+Alternatively, there are pre-defined hardware configurations for available chips/modules:
+
+Module           | Equivalent `#define`            | Source
+-----------------|---------------------------------|------------------------------------------
+CAT24C512 EEPROM | `#define EEPROM_I2C_CAT24C512`  | <https://www.sparkfun.com/products/14764>
+RM24C512C EEPROM | `#define EEPROM_I2C_RM24C512C`  | <https://www.sparkfun.com/products/14764>
+24LC128 EEPROM   | `#define EEPROM_I2C_24LC128`    | <https://www.microchip.com/wwwproducts/en/24LC128>
+24LC256 EEPROM   | `#define EEPROM_I2C_24LC256`    | <https://www.sparkfun.com/products/525>
+MB85RC256V FRAM  | `#define EEPROM_I2C_MB85RC256V` | <https://www.adafruit.com/product/1895>
+
+?> If you find that the EEPROM is not cooperating, ensure you've correctly shifted up your EEPROM address by 1. For example, the datasheet might state the address as `0b01010000` -- the correct value of `EXTERNAL_EEPROM_I2C_BASE_ADDRESS` needs to be `0b10100000`.
+
+## Transient Driver configuration
+
+The only configurable item for the transient EEPROM driver is its size:
+
+`config.h` override             | Description                               | Default Value
+------------------------------- | ----------------------------------------- | -------------
+`#define TRANSIENT_EEPROM_SIZE` | Total size of the EEPROM storage in bytes | 64
+
+Default values and extended descriptions can be found in `drivers/eeprom/eeprom_transient.h`.

docs/feature_oled_driver.md

@@ -1,139 +1,142 @@
 # OLED Driver
 
-## OLED Supported Hardware
+## Supported Hardware
 
 OLED modules using SSD1306 or SH1106 driver ICs, communicating over I2C.
 Tested combinations:
 
-| IC driver |   Size | Keyboard Platform | Notes                    |
-|-----------|--------|-------------------|--------------------------|
-| SSD1306   | 128x32 | AVR               | Primary support          |
-| SSD1306   | 128x64 | AVR               | Verified working         |
-| SSD1306   | 128x32 | ARM               |                          |
-| SH1106    | 128x64 | AVR               | No rotation or scrolling |
+|IC       |Size  |Platform|Notes                   |
+|---------|------|--------|------------------------|
+|SSD1306  |128x32|AVR     |Primary support         |
+|SSD1306  |128x64|AVR     |Verified working        |
+|SSD1306  |128x32|Arm     |                        |
+|SH1106   |128x64|AVR     |No rotation or scrolling|
 
-Hardware configurations using ARM-based microcontrollers or different sizes of OLED modules may be compatible, but are untested.
+Hardware configurations using Arm-based microcontrollers or different sizes of OLED modules may be compatible, but are untested.
 
-!> Warning: This OLED Driver currently uses the new i2c_master driver from split common code. If your split keyboard uses I2C to communicate between sides, this driver could cause an address conflict (serial is fine). Please contact your keyboard vendor and ask them to migrate to the latest split common code to fix this. In addition, the display timeout system to reduce OLED burn-in also uses split common to detect keypresses, so you will need to implement custom timeout logic for non-split common keyboards.
+!> Warning: This OLED driver currently uses the new i2c_master driver from Split Common code. If your split keyboard uses I2C to communicate between sides, this driver could cause an address conflict (serial is fine). Please contact your keyboard vendor and ask them to migrate to the latest Split Common code to fix this. In addition, the display timeout system to reduce OLED burn-in also uses Split Common to detect keypresses, so you will need to implement custom timeout logic for non-Split Common keyboards.
 
 ## Usage
 
-To enable the OLED feature, there are three steps. First, when compiling your keyboard, you'll need to set `OLED_DRIVER_ENABLE=yes` in `rules.mk`, e.g.:
+To enable the OLED feature, there are three steps. First, when compiling your keyboard, you'll need to add the following to your `rules.mk`:
 
-```
+```make
 OLED_DRIVER_ENABLE = yes
 ```
 
-This enables the feature and the `OLED_DRIVER_ENABLE` define. Then in your `keymap.c` file, you will need to implement the user task call, e.g:
+Then in your `keymap.c` file, implement the OLED task call. This example assumes your keymap has three layers named `_QWERTY`, `_FN` and `_ADJ`:
 
-```C++
+```c
 #ifdef OLED_DRIVER_ENABLE
 void oled_task_user(void) {
-  // Host Keyboard Layer Status
-  oled_write_P(PSTR("Layer: "), false);
-  switch (get_highest_layer(layer_state)) {
-    case _QWERTY:
-      oled_write_P(PSTR("Default\n"), false);
-      break;
-    case _FN:
-      oled_write_P(PSTR("FN\n"), false);
-      break;
-    case _ADJ:
-      oled_write_P(PSTR("ADJ\n"), false);
-      break;
-    default:
-      // Or use the write_ln shortcut over adding '\n' to the end of your string
-      oled_write_ln_P(PSTR("Undefined"), false);
-  }
+    // Host Keyboard Layer Status
+    oled_write_P(PSTR("Layer: "), false);
 
-  // Host Keyboard LED Status
-  uint8_t led_usb_state = host_keyboard_leds();
-  oled_write_P(led_usb_state & (1<<USB_LED_NUM_LOCK) ? PSTR("NUMLCK ") : PSTR("       "), false);
-  oled_write_P(led_usb_state & (1<<USB_LED_CAPS_LOCK) ? PSTR("CAPLCK ") : PSTR("       "), false);
-  oled_write_P(led_usb_state & (1<<USB_LED_SCROLL_LOCK) ? PSTR("SCRLCK ") : PSTR("       "), false);
+    switch (get_highest_layer(layer_state)) {
+        case _QWERTY:
+            oled_write_P(PSTR("Default\n"), false);
+            break;
+        case _FN:
+            oled_write_P(PSTR("FN\n"), false);
+            break;
+        case _ADJ:
+            oled_write_P(PSTR("ADJ\n"), false);
+            break;
+        default:
+            // Or use the write_ln shortcut over adding '\n' to the end of your string
+            oled_write_ln_P(PSTR("Undefined"), false);
+    }
+
+    // Host Keyboard LED Status
+    led_t led_state = host_keyboard_led_state();
+    oled_write_P(led_state.num_lock ? PSTR("NUM ") : PSTR("    "), false);
+    oled_write_P(led_state.caps_lock ? PSTR("CAP ") : PSTR("    "), false);
+    oled_write_P(led_state.scroll_lock ? PSTR("SCR ") : PSTR("    "), false);
 }
 #endif
 ```
 
 ## Logo Example
 
-In the default font, ranges in the font file are reserved for a QMK Logo. To Render this logo to the oled screen, use the following code example:
+In the default font, certain ranges of characters are reserved for a QMK logo. To render this logo to the OLED screen, use the following code example:
 
-```C++
+```c
 static void render_logo(void) {
-  static const char PROGMEM qmk_logo[] = {
-    0x80,0x81,0x82,0x83,0x84,0x85,0x86,0x87,0x88,0x89,0x8a,0x8b,0x8c,0x8d,0x8e,0x8f,0x90,0x91,0x92,0x93,0x94,
-    0xa0,0xa1,0xa2,0xa3,0xa4,0xa5,0xa6,0xa7,0xa8,0xa9,0xaa,0xab,0xac,0xad,0xae,0xaf,0xb0,0xb1,0xb2,0xb3,0xb4,
-    0xc0,0xc1,0xc2,0xc3,0xc4,0xc5,0xc6,0xc7,0xc8,0xc9,0xca,0xcb,0xcc,0xcd,0xce,0xcf,0xd0,0xd1,0xd2,0xd3,0xd4,0};
+    static const char PROGMEM qmk_logo[] = {
+        0x80, 0x81, 0x82, 0x83, 0x84, 0x85, 0x86, 0x87, 0x88, 0x89, 0x8A, 0x8B, 0x8C, 0x8D, 0x8E, 0x8F, 0x90, 0x91, 0x92, 0x93, 0x94,
+        0xA0, 0xA1, 0xA2, 0xA3, 0xA4, 0xA5, 0xA6, 0xA7, 0xA8, 0xA9, 0xAA, 0xAB, 0xAC, 0xAD, 0xAE, 0xAF, 0xB0, 0xB1, 0xB2, 0xB3, 0xB4,
+        0xC0, 0xC1, 0xC2, 0xC3, 0xC4, 0xC5, 0xC6, 0xC7, 0xC8, 0xC9, 0xCA, 0xCB, 0xCC, 0xCD, 0xCE, 0xCF, 0xD0, 0xD1, 0xD2, 0xD3, 0xD4, 0x00
+    };
 
-  oled_write_P(qmk_logo, false);
+    oled_write_P(qmk_logo, false);
 }
 ```
 
 ## Other Examples
 
-In split keyboards, it is very common to have two OLED displays that each render different content and oriented flipped differently. You can do this by switching which content to render by using the return from `is_keyboard_master()` or `is_keyboard_left()` found in `split_util.h`, e.g:
+In split keyboards, it is very common to have two OLED displays that each render different content and are oriented or flipped differently. You can do this by switching which content to render by using the return value from `is_keyboard_master()` or `is_keyboard_left()` found in `split_util.h`, e.g:
 
-```C++
+```c
 #ifdef OLED_DRIVER_ENABLE
 oled_rotation_t oled_init_user(oled_rotation_t rotation) {
-  if (!is_keyboard_master())
-    return OLED_ROTATION_180;  // flips the display 180 degrees if offhand
-  return rotation;
+    if (!is_keyboard_master()) {
+        return OLED_ROTATION_180;  // flips the display 180 degrees if offhand
+    }
+
+    return rotation;
 }
 
 void oled_task_user(void) {
-  if (is_keyboard_master()) {
-    render_status();     // Renders the current keyboard state (layer, lock, caps, scroll, etc)
-  } else {
-    render_logo();       // Renders a statuc logo
-    oled_scroll_left();  // Turns on scrolling
-  }
+    if (is_keyboard_master()) {
+        render_status();  // Renders the current keyboard state (layer, lock, caps, scroll, etc)
+    } else {
+        render_logo();  // Renders a static logo
+        oled_scroll_left();  // Turns on scrolling
+    }
 }
 #endif
 ```
 
+## Basic Configuration
 
- ## Basic Configuration
-
-| Define                     | Default           | Description                                                                                                                |
-|----------------------------|-------------------|----------------------------------------------------------------------------------------------------------------------------|
-| `OLED_DISPLAY_ADDRESS`     | `0x3C`            | The i2c address of the OLED Display                                                                                        |
-| `OLED_FONT_H`              | `"glcdfont.c"`    | The font code file to use for custom fonts                                                                                 |
-| `OLED_FONT_START`          | `0`               | The starting characer index for custom fonts                                                                               |
-| `OLED_FONT_END`            | `224`             | The ending characer index for custom fonts                                                                                 |
-| `OLED_FONT_WIDTH`          | `6`               | The font width                                                                                                             |
-| `OLED_FONT_HEIGHT`         | `8`               | The font height (untested)                                                                                                 |
-| `OLED_TIMEOUT`             | `60000`           | Turns off the OLED screen after 60000ms of keyboard inactivity. Helps reduce OLED Burn-in. Set to 0 to disable.            |
-| `OLED_SCROLL_TIMEOUT`      | `0`               | Scrolls the OLED screen after 0ms of OLED inactivity. Helps reduce OLED Burn-in. Set to 0 to disable.                      |
-| `OLED_SCROLL_TIMEOUT_RIGHT`| *Not defined*     | Scroll timeout direction is right when defined, left when undefined.                                                       |
-| `OLED_IC`                  | `OLED_IC_SSD1306` | Set to `OLED_IC_SH1106` if you're using the SH1106 OLED controller.                                                        |
-| `OLED_COLUMN_OFFSET`       | `0`               | (SH1106 only.) Shift output to the right this many pixels.<br />Useful for 128x64 displays centered on a 132x64 SH1106 IC. |
+|Define                     |Default          |Description                                                                                                               |
+|---------------------------|-----------------|--------------------------------------------------------------------------------------------------------------------------|
+|`OLED_DISPLAY_ADDRESS`     |`0x3C`           |The i2c address of the OLED Display                                                                                       |
+|`OLED_FONT_H`              |`"glcdfont.c"`   |The font code file to use for custom fonts                                                                                |
+|`OLED_FONT_START`          |`0`              |The starting characer index for custom fonts                                                                              |
+|`OLED_FONT_END`            |`224`            |The ending characer index for custom fonts                                                                                |
+|`OLED_FONT_WIDTH`          |`6`              |The font width                                                                                                            |
+|`OLED_FONT_HEIGHT`         |`8`              |The font height (untested)                                                                                                |
+|`OLED_TIMEOUT`             |`60000`          |Turns off the OLED screen after 60000ms of keyboard inactivity. Helps reduce OLED Burn-in. Set to 0 to disable.           |
+|`OLED_SCROLL_TIMEOUT`      |`0`              |Scrolls the OLED screen after 0ms of OLED inactivity. Helps reduce OLED Burn-in. Set to 0 to disable.                     |
+|`OLED_SCROLL_TIMEOUT_RIGHT`|*Not defined*    |Scroll timeout direction is right when defined, left when undefined.                                                      |
+|`OLED_IC`                  |`OLED_IC_SSD1306`|Set to `OLED_IC_SH1106` if you're using the SH1106 OLED controller.                                                       |
+|`OLED_COLUMN_OFFSET`       |`0`              |(SH1106 only.) Shift output to the right this many pixels.<br />Useful for 128x64 displays centered on a 132x64 SH1106 IC.|
 
  ## 128x64 & Custom sized OLED Displays
 
  The default display size for this feature is 128x32 and all necessary defines are precalculated with that in mind. We have added a define, `OLED_DISPLAY_128X64`, to switch all the values to be used in a 128x64 display, as well as added a custom define, `OLED_DISPLAY_CUSTOM`, that allows you to provide the necessary values to the driver.
 
-|Define                 |Default        |Description                                                      |
-|-----------------------|---------------|-----------------------------------------------------------------|
-|`OLED_DISPLAY_128X64`  |*Not defined*  |Changes the display defines for use with 128x64 displays.        |
-|`OLED_DISPLAY_CUSTOM`  |*Not defined*  |Changes the display defines for use with custom displays.<br />Requires user to implement the below defines. |
-|`OLED_DISPLAY_WIDTH`   |`128`          |The width of the OLED display.                                   |
-|`OLED_DISPLAY_HEIGHT`  |`32`           |The height of the OLED display.                                  |
-|`OLED_MATRIX_SIZE`     |`512`          |The local buffer size to allocate.<br />`(OLED_DISPLAY_HEIGHT / 8 * OLED_DISPLAY_WIDTH)`. |
-|`OLED_BLOCK_TYPE`      |`uint16_t`     |The unsigned integer type to use for dirty rendering. |
-|`OLED_BLOCK_COUNT`     |`16`           |The number of blocks the display is divided into for dirty rendering.<br />`(sizeof(OLED_BLOCK_TYPE) * 8)`. |
-|`OLED_BLOCK_SIZE`      |`32`           |The size of each block for dirty rendering<br />`(OLED_MATRIX_SIZE / OLED_BLOCK_COUNT)`. |
-|`OLED_COM_PINS`        |`COM_PINS_SEQ` |How the SSD1306 chip maps it's memory to display.<br />Options are `COM_PINS_SEQ`, `COM_PINS_ALT`, `COM_PINS_SEQ_LR`, & `COM_PINS_ALT_LR`. |
-|`OLED_SOURCE_MAP`      |`{ 0, ... N }` |Precalculated source array to use for mapping source buffer to target OLED memory in 90 degree rendering.         |
-|`OLED_TARGET_MAP`      |`{ 24, ... N }`|Precalculated target array to use for mapping source buffer to target OLED memory in 90 degree rendering.         |
+|Define               |Default        |Description                                                                                                                             |
+|---------------------|---------------|----------------------------------------------------------------------------------------------------------------------------------------|
+|`OLED_DISPLAY_128X64`|*Not defined*  |Changes the display defines for use with 128x64 displays.                                                                               |
+|`OLED_DISPLAY_CUSTOM`|*Not defined*  |Changes the display defines for use with custom displays.<br>Requires user to implement the below defines.                              |
+|`OLED_DISPLAY_WIDTH` |`128`          |The width of the OLED display.                                                                                                          |
+|`OLED_DISPLAY_HEIGHT`|`32`           |The height of the OLED display.                                                                                                         |
+|`OLED_MATRIX_SIZE`   |`512`          |The local buffer size to allocate.<br>`(OLED_DISPLAY_HEIGHT / 8 * OLED_DISPLAY_WIDTH)`.                                                 |
+|`OLED_BLOCK_TYPE`    |`uint16_t`     |The unsigned integer type to use for dirty rendering.                                                                                   |
+|`OLED_BLOCK_COUNT`   |`16`           |The number of blocks the display is divided into for dirty rendering.<br>`(sizeof(OLED_BLOCK_TYPE) * 8)`.                               |
+|`OLED_BLOCK_SIZE`    |`32`           |The size of each block for dirty rendering<br>`(OLED_MATRIX_SIZE / OLED_BLOCK_COUNT)`.                                                  |
+|`OLED_COM_PINS`      |`COM_PINS_SEQ` |How the SSD1306 chip maps it's memory to display.<br>Options are `COM_PINS_SEQ`, `COM_PINS_ALT`, `COM_PINS_SEQ_LR`, & `COM_PINS_ALT_LR`.|
+|`OLED_SOURCE_MAP`    |`{ 0, ... N }` |Precalculated source array to use for mapping source buffer to target OLED memory in 90 degree rendering.                               |
+|`OLED_TARGET_MAP`    |`{ 24, ... N }`|Precalculated target array to use for mapping source buffer to target OLED memory in 90 degree rendering.                               |
 
 
-### 90 Degree Rotation - Technical Mumbo Jumbo 
+### 90 Degree Rotation - Technical Mumbo Jumbo
 
 !> Rotation is unsupported on the SH1106.
 
-```C
+```c
 // OLED Rotation enum values are flags
 typedef enum {
     OLED_ROTATION_0   = 0,
@@ -143,9 +146,9 @@ typedef enum {
 } oled_rotation_t;
 ```
 
- OLED displays driven by SSD1306 drivers only natively support in hard ware 0 degree and 180 degree rendering. This feature is done in software and not free. Using this feature will increase the time to calculate what data to send over i2c to the OLED. If you are strapped for cycles, this can cause keycodes to not register. In testing however, the rendering time on an `atmega32u4` board only went from 2ms to 5ms and keycodes not registering was only noticed once we hit 15ms. 
- 
- 90 Degree Rotated Rendering is achieved by using bitwise operations to rotate each 8 block of memory and uses two precalculated arrays to remap buffer memory to OLED memory. The memory map defines are precalculated for remap performance and are calculated based on the OLED Height, Width, and Block Size. For example, in the 128x32 implementation with a `uint8_t` block type, we have a 64 byte block size. This gives us eight 8 byte blocks that need to be rotated and rendered. The OLED renders horizontally two 8 byte blocks before moving down a page, e.g:
+OLED displays driven by SSD1306 drivers only natively support in hardware 0 degree and 180 degree rendering. This feature is done in software and not free. Using this feature will increase the time to calculate what data to send over i2c to the OLED. If you are strapped for cycles, this can cause keycodes to not register. In testing however, the rendering time on an ATmega32U4 board only went from 2ms to 5ms and keycodes not registering was only noticed once we hit 15ms.
+
+90 degree rotation is achieved by using bitwise operations to rotate each 8 block of memory and uses two precalculated arrays to remap buffer memory to OLED memory. The memory map defines are precalculated for remap performance and are calculated based on the display height, width, and block size. For example, in the 128x32 implementation with a `uint8_t` block type, we have a 64 byte block size. This gives us eight 8 byte blocks that need to be rotated and rendered. The OLED renders horizontally two 8 byte blocks before moving down a page, e.g:
 
 |   |   |   |   |   |   |
 |---|---|---|---|---|---|
@@ -167,8 +170,8 @@ So those precalculated arrays just index the memory offsets in the order in whic
 
 ## OLED API
 
-```C++
-// OLED Rotation enum values are flags
+```c
+// OLED rotation enum values are flags
 typedef enum {
     OLED_ROTATION_0   = 0,
     OLED_ROTATION_90  = 1,
@@ -272,26 +275,26 @@ uint8_t oled_max_lines(void);
 
 !> Scrolling and rotation are unsupported on the SH1106.
 
-## SSD1306.h driver conversion guide
+## SSD1306.h Driver Conversion Guide
 
-|Old API                    |Recommended New API                |
-|---------------------------|-----------------------------------|
-|`struct CharacterMatrix`   |*removed - delete all references*  |
-|`iota_gfx_init`            |`oled_init`                        |
-|`iota_gfx_on`              |`oled_on`                          |
-|`iota_gfx_off`             |`oled_off`                         |
-|`iota_gfx_flush`           |`oled_render`                      |
-|`iota_gfx_write_char`      |`oled_write_char`                  |
-|`iota_gfx_write`           |`oled_write`                       |
-|`iota_gfx_write_P`         |`oled_write_P`                     |
-|`iota_gfx_clear_screen`    |`oled_clear`                       |
-|`matrix_clear`             |*removed - delete all references*  |
-|`matrix_write_char_inner`  |`oled_write_char`                  |
-|`matrix_write_char`        |`oled_write_char`                  |
-|`matrix_write`             |`oled_write`                       |
-|`matrix_write_ln`          |`oled_write_ln`                    |
-|`matrix_write_P`           |`oled_write_P`                     |
-|`matrix_write_ln_P`        |`oled_write_ln_P`                  |
-|`matrix_render`            |`oled_render`                      |
-|`iota_gfx_task`            |`oled_task`                        |
-|`iota_gfx_task_user`       |`oled_task_user`                   |
+|Old API                  |Recommended New API              |
+|-------------------------|---------------------------------|
+|`struct CharacterMatrix` |*removed - delete all references*|
+|`iota_gfx_init`          |`oled_init`                      |
+|`iota_gfx_on`            |`oled_on`                        |
+|`iota_gfx_off`           |`oled_off`                       |
+|`iota_gfx_flush`         |`oled_render`                    |
+|`iota_gfx_write_char`    |`oled_write_char`                |
+|`iota_gfx_write`         |`oled_write`                     |
+|`iota_gfx_write_P`       |`oled_write_P`                   |
+|`iota_gfx_clear_screen`  |`oled_clear`                     |
+|`matrix_clear`           |*removed - delete all references*|
+|`matrix_write_char_inner`|`oled_write_char`                |
+|`matrix_write_char`      |`oled_write_char`                |
+|`matrix_write`           |`oled_write`                     |
+|`matrix_write_ln`        |`oled_write_ln`                  |
+|`matrix_write_P`         |`oled_write_P`                   |
+|`matrix_write_ln_P`      |`oled_write_ln_P`                |
+|`matrix_render`          |`oled_render`                    |
+|`iota_gfx_task`          |`oled_task`                      |
+|`iota_gfx_task_user`     |`oled_task_user`                 |

docs/hardware_drivers.md

@@ -33,3 +33,7 @@ Support for up to 2 drivers. Each driver impliments 2 charlieplex matrices to in
 ## IS31FL3733
 
 Support for up to a single driver with room for expansion. Each driver can control 192 individual LEDs or 64 RGB LEDs. For more information on how to setup the driver see the [RGB Matrix](feature_rgb_matrix.md) page.
+
+## 24xx series external I2C EEPROM
+
+Support for an external I2C-based EEPROM instead of using the on-chip EEPROM. For more information on how to setup the driver see the [EEPROM Driver](eeprom_driver.md) page.

docs/ja/_summary.md

@@ -10,32 +10,34 @@
    * [学習リソース](ja/newbs_learn_more_resources.md)
 
 * [QMKの基本](ja/README.md)
-   * [QMKの導入](ja/getting_started_introduction.md)
+   * [QMK の導入](ja/getting_started_introduction.md)
    * [QMK CLI](ja/cli.md)
    * [QMK CLI 設定](ja/cli_configuration.md)
-   * [QMKへの貢献](ja/contributing.md)
-   * [Githubの使い方](ja/getting_started_github.md)
+   * [QMK への貢献](ja/contributing.md)
+   * [Github の使い方](ja/getting_started_github.md)
    * [ヘルプ](ja/getting_started_getting_help.md)
 
 * [破壊的な変更](ja/breaking_changes.md)
+   * [プルリクエストにフラグが付けられた](ja/breaking_changes_instructions.md)
    * [2019年8月30日](ja/ChangeLog/20190830.md)
 
 * [FAQ](ja/faq.md)
-   * [一般的なFAQ](ja/faq_general.md)
-   * [QMKのビルド/コンパイル](ja/faq_build.md)
-   * [QMKのデバッグ/トラブルシューティング](ja/faq_debug.md)
+   * [一般的な FAQ](ja/faq_general.md)
+   * [QMK のビルド/コンパイル](ja/faq_build.md)
+   * [QMK のデバッグ/トラブルシューティング](ja/faq_debug.md)
    * [キーマップ](ja/faq_keymap.md)
-   * [Zadigを使ったドライバのインストール](ja/driver_installation_zadig.md)
+   * [Zadig を使ったドライバのインストール](ja/driver_installation_zadig.md)
 
 * 詳細なガイド
    * [ビルドツールのインストール](ja/getting_started_build_tools.md)
-   * [Vagrantのガイド](ja/getting_started_vagrant.md)
+   * [Vagrant のガイド](ja/getting_started_vagrant.md)
    * [ビルド/コンパイルの説明](ja/getting_started_make_guide.md)
    * [ファームウェアのフラッシュ](ja/flashing.md)
    * [機能のカスタマイズ](ja/custom_quantum_functions.md)
    * [キーマップの概要](ja/keymap.md)
 
 * [ハードウェア](ja/hardware.md)
+   * [互換性のあるマイクロコントローラ](ja/compatible_microcontrollers.md)
    * [AVR プロセッサ](ja/hardware_avr.md)
    * [ドライバ](ja/hardware_drivers.md)
 
@@ -66,7 +68,7 @@
    * [ブートマジック](ja/feature_bootmagic.md)
    * [コンボ](ja/feature_combo.md)
    * [コマンド](ja/feature_command.md)
-   * [Debounce API](ja/feature_debounce_type.md)
+   * [デバウンス API](ja/feature_debounce_type.md)
    * [DIP スイッチ](ja/feature_dip_switch.md)
    * [動的マクロ](ja/feature_dynamic_macros.md)
    * [エンコーダ](ja/feature_encoders.md)
@@ -90,27 +92,31 @@
    * [Stenography](ja/feature_stenography.md)
    * [Swap Hands](ja/feature_swap_hands.md)
    * [タップ ダンス](ja/feature_tap_dance.md)
-   * [Terminal](ja/feature_terminal.md)
+   * [ターミナル](ja/feature_terminal.md)
    * [感熱式プリンタ](ja/feature_thermal_printer.md)
    * [ユニコード](ja/feature_unicode.md)
-   * [Userspace](ja/feature_userspace.md)
+   * [ユーザスペース](ja/feature_userspace.md)
    * [Velocikey](ja/feature_velocikey.md)
 
 * メーカーおよびモッダーのために
-   * [Hand Wiring Guide](ja/hand_wire.md)
-   * [ISP Flashing Guide](ja/isp_flashing_guide.md)
+   * [Hand Wiring ガイド](ja/hand_wire.md)
+   * [ISP 書き込みガイド](ja/isp_flashing_guide.md)
    * [ARM デバッグ ガイド](ja/arm_debugging.md)
+   * [ADC ドライバ](ja/adc_driver.md)
    * [I2C ドライバ](ja/i2c_driver.md)
+   * [WS2812 ドライバ](ja/ws2812_driver.md)
+   * [EEPROM ドライバ](ja/eeprom_driver.md)
    * [GPIO コントロール](ja/internals_gpio_control.md)
+   * [カスタムマトリックス](ja/custom_matrix.md)
    * [Proton C 規約](ja/proton_c_conversion.md)
 
 * より深く知るために
    * [キーボードがどのように動作するか](ja/how_keyboards_work.md)
-   * [QMKの理解](ja/understanding_qmk.md)
+   * [QMK の理解](ja/understanding_qmk.md)
 
 * 他の話題
-   * [EclipseでQMKを使用](ja/other_eclipse.md)
-   * [VSCodeでQMKを使用](ja/other_vscode.md)
+   * [Eclipse で QMK を使用](ja/other_eclipse.md)
+   * [VSCode で QMK を使用](ja/other_vscode.md)
    * [サポート](ja/support.md)
    * [翻訳を追加する方法](ja/translating.md)
 

docs/ja/arm_debugging.md

@@ -64,13 +64,13 @@ Eclipse に QMK をビルドしようとするデバイスを教える必要が
 
 ## ビルド
 
-全て正しくセットアップできていれば、ハンマーボタンを押すとファームウェアがビルドされ、.binファイルが出力されるはずです。
+全て正しくセットアップできていれば、ハンマーボタンを押すとファームウェアがビルドされ、.bin ファイルが出力されるはずです。
 
 ## デバッグ
 
 ### デバッガの接続
 
-ARM MCU は、クロック信号(SWCLK) とデータ信号(SWDIO) で構成される Single Wire Debug (SWD) プロトコルを使います。MCUを 完全に操作するには、この2本のワイヤとグラウンドを接続するだけで十分です。ここでは、キーボードは USB を介して電力が供給されると想定しています。手動でリセットボタンを使えるため、RESET 信号は必要ありません。より高度なセットアップのために printf と scanf をホストに非同期にパイプする SWO 信号を使用できますが、私たちのセットアップでは無視します。
+ARM MCU は、クロック信号(SWCLK) とデータ信号(SWDIO) で構成される Single Wire Debug (SWD) プロトコルを使います。MCU を 完全に操作するには、この2本のワイヤとグラウンドを接続するだけで十分です。ここでは、キーボードは USB を介して電力が供給されると想定しています。手動でリセットボタンを使えるため、RESET 信号は必要ありません。より高度なセットアップのために printf と scanf をホストに非同期にパイプする SWO 信号を使用できますが、私たちのセットアップでは無視します。
 
 注意: SWCLK と SWDIO ピンがキーボードのマトリックスで使われていないことを確認してください。もし使われている場合は、一時的に他のピンに切り替えることができます。
 

docs/ja/config_options.md

@@ -1,8 +1,8 @@
 # QMK の設定
 
 <!---
-  original document: 0f43c2652:docs/config_options.md
-  git diff 0f43c2652 HEAD -- docs/config_options.md | cat
+  original document: 9ff61601e:docs/config_options.md
+  git diff 9ff61601e HEAD -- docs/config_options.md | cat
 -->
 
 QMK はほぼ無制限に設定可能です。可能なところはいかなるところでも、やりすぎな程、ユーザーがコードサイズを犠牲にしてでも彼らのキーボードをカスタマイズをすることを許しています。ただし、このレベルの柔軟性により設定が困難になります。
@@ -154,6 +154,8 @@ QMK での全ての利用可能な設定にはデフォルトがあります。
    * タップされた直後に、デュアルロールキーを修飾子として使用できるようにします
    * [Hold after tap](ja/feature_advanced_keycodes.md#tapping-force-hold)を見てください
    * タップトグル機能を無効にします (`TT` あるいは One Shot Tap Toggle)
+* `#define TAPPING_FORCE_HOLD_PER_KEY`
+   * キーごとの `TAPPING_FORCE_HOLD` 設定処理を有効にします。
 * `#define LEADER_TIMEOUT 300`
    * リーダーキーがタイムアウトするまでの時間
       * タイムアウトする前にシーケンスを終了できない場合は、タイムアウトの設定を増やす必要があるかもしれません。あるいは、`LEADER_PER_KEY_TIMING` オプションを有効にすると良いでしょう。これは各キーがタップされた後でタイムアウトを再設定します。
@@ -187,7 +189,7 @@ QMK での全ての利用可能な設定にはデフォルトがあります。
 * `#define RGBLIGHT_SPLIT`
    * 分割キーボードの左半分の RGB LED の出力を右半分の RGB LED の入力につなげるかわりに、それぞれの側で個別にコントローラの出力ピンが直接 RGB LED の入力に繋がっているときは、この定義が必要です。
 * `#define RGBLED_SPLIT { 6, 6 }`
-   * 分割キーボードの各半分の `RGB_DI_PIN` に直接配線されている接続されているLEDの数
+   * 分割キーボードの各半分の `RGB_DI_PIN` に直接配線されている接続されている LED の数
    * 最初の値は左半分の LED の数を示し、2番目の値は右半分です。
    * RGBLED_SPLIT が定義されている場合、RGBLIGHT_SPLIT は暗黙的に定義されます。
 * `#define RGBLIGHT_HUE_STEP 12`
@@ -216,7 +218,7 @@ QMK での全ての利用可能な設定にはデフォルトがあります。
 
 ### 左右の設定
 
-一つ覚えておかなければならないことは、USB ポートが接続されている側が常にマスター側であるということです。USB に接続されていない側はスレーブです。
+1つ覚えておかなければならないことは、USB ポートが接続されている側が常にマスター側であるということです。USB に接続されていない側はスレーブです。
 
 分割キーボードの左右を設定するには、幾つかの異なる方法があります (優先度の順にリストされています):
 
@@ -260,7 +262,7 @@ QMK での全ての利用可能な設定にはデフォルトがあります。
 * `#define SELECT_SOFT_SERIAL_SPEED <speed>` (デフォルトの速度は1です)
    * serial 通信を使う時のプロトコルの速度を設定します。
    * 速度:
-      * 0: 約189kbps (実験目的のみ)
+      * 0: 約 189kbps (実験目的のみ)
       * 1: 約 137kbps (デフォルト)
       * 2: 約 75kbps
       * 3: 約 39kbps

docs/ja/newbs_building_firmware_configurator.md

@@ -63,7 +63,7 @@ QMK Configurator は Chrome/Firefox で最適に動作します。
 
 2分割の右シフト: 両方とも右シフトで埋めます。
 
-左シフトとISOサポート用に1つずつ: 両方とも左シフトで埋めます。
+左シフトと ISO サポート用に1つずつ: 両方とも左シフトで埋めます。
 
 5分割だが4キーのみ: 以前やったことがある人を推測して確認するか尋ねてください。
 
@@ -73,7 +73,7 @@ QMK Configurator は Chrome/Firefox で最適に動作します。
 
 後日、`Import Keymap` ボタンを押すことで、この .json ファイルをロードできます。
 
-!> **注意:** このファイルは、kbfirmware.com またはその他のツールに使用される .jsonファイルと同じ形式ではありません。これらのツールにこれを使用したり、QMK Configurator でこれらのツールの .json を使用しようとすると、キーボードが **爆発** する可能性があります。
+!> **注意:** このファイルは、kbfirmware.com またはその他のツールに使用される .json ファイルと同じ形式ではありません。これらのツールにこれを使用したり、QMK Configurator でこれらのツールの .json を使用しようとすると、キーボードが **爆発** する可能性があります。
 
 ## ファームウェアファイルを生成する
 

docs/ja/newbs_flashing.md

@@ -13,7 +13,7 @@
 キーボードに書き込む最も簡単な方法は [QMK Toolbox](https://github.com/qmk/qmk_toolbox/releases) を使うことです。
 
 ただし、QMK Toolbox は、現在は Windows と macOS でしか使えません。
-Linuxを使用している場合(および、コマンドラインでファームウェアを書き込みたい場合)は、下の方で概説する[方法](ja/newbs_flashing.md#flash-your-keyboard-from-the-command-line)で行なう必要があります。
+Linux を使用している場合(および、コマンドラインでファームウェアを書き込みたい場合)は、下の方で概説する[方法](ja/newbs_flashing.md#flash-your-keyboard-from-the-command-line)で行なう必要があります。
 
 ### QMK Toolbox にファイルをロードする
 
@@ -65,7 +65,7 @@ planck_rev5_default.hex
 * 基板(PCB)に付けられている物理的な `RESET` ボタンを押す
 * PCB 上の `BOOT0` か `RESET` のラベルの付いたヘッダピンを探し、PCB 接続中にそれらを互いにショートする
 
-うまくいけば、QMK Toolboxに次のようなメッセージが表示されます。
+うまくいけば、QMK Toolbox に次のようなメッセージが表示されます。
 
 ```
 *** Clueboard - Clueboard 66% HotSwap disconnected -- 0xC1ED:0x2390
@@ -121,7 +121,7 @@ QMK Toolbox の `Flash` ボタンをクリックします。
 この場合、あなたは明示的にブートローダを指定する方法を使わなければなりません。
 
 ブートローダは主に 5 種類のものが使われています。
-Pro Micro とそのクローンは Caterina を、Teensy は HalfKay を、OLKBの AVR ボードは QMK-DFU を、その他の ATmega32U4 ボードは DFU を、そして多くの ARM ボードは ARM DFU を使います。
+Pro Micro とそのクローンは Caterina を、Teensy は HalfKay を、OLKB の AVR ボードは QMK-DFU を、その他の ATmega32U4 ボードは DFU を、そして多くの ARM ボードは ARM DFU を使います。
 
 より詳しいブートローダの情報は、[Flashing Instructions and Bootloader Information](ja/flashing.md) にあります。
 
@@ -178,10 +178,10 @@ Checking file size of planck_rev5_xyverz.hex
 
 ファームウェアを DFU デバイスに書き込むために使用できる DFU コマンドがいくつかあります。
 
-* `:dfu` - これが通常のオプションで、DFUデバイスが使用可能になるまで待機したのちファームウェアを書き込みます。5秒ごとに、DFUデバイスが存在するかチェックしています。
+* `:dfu` - これが通常のオプションで、DFU デバイスが使用可能になるまで待機したのちファームウェアを書き込みます。5秒ごとに、DFU デバイスが存在するかチェックしています。
 * `:dfu-ee` - 通常の hex ファイルの代わりに `eep` ファイルを書き込みます。これを使用するのはまれです。
-* `:dfu-split-left` - デフォルトオプション (`:dfu`) と同様に、通常のファームウェアが書き込まれます。ただし、分割キーボードの「左側の」 EEPROMファイルも書き込まれます。_これは、Elite C ベースの分割キーボードに最適です。_
-* `:dfu-split-right` - デフォルトオプション (`:dfu`) と同様に、通常のファームウェアが書き込まれます。ただし、分割キーボードの「右側の」EEPROMファイルも書き込まれます。_これは、Elite C ベースの分割キーボードに最適です。_
+* `:dfu-split-left` - デフォルトオプション (`:dfu`) と同様に、通常のファームウェアが書き込まれます。ただし、分割キーボードの「左側の」 EEPROM ファイルも書き込まれます。_これは、Elite C ベースの分割キーボードに最適です。_
+* `:dfu-split-right` - デフォルトオプション (`:dfu`) と同様に、通常のファームウェアが書き込まれます。ただし、分割キーボードの「右側の」EEPROM ファイルも書き込まれます。_これは、Elite C ベースの分割キーボードに最適です。_
 
 
 ### Caterina 
@@ -259,8 +259,8 @@ avrdude.exe done.  Thank you.
 
 * `:avrdude` - これが通常のオプションで、Caterina デバイスが(新しい COM ポートを検出して)使用可能になるまで待機し、ファームウェアを書き込みます。
 * `:avrdude-loop` - これは `:avrdude` と同じです。ただし書き込みが終了すると再び Caterina デバイスの書き込み待ちに戻ります。これは何台ものデバイスへの書き込みに便利です。_Control+C を押して、手動でこの繰り返しを終了させる必要があります。_
-* `:avrdude-split-left` - デフォルトオプション(`:avrdude`)と同様に通常のファームウェアが書き込まれます。ただし、分割キーボードの「左側の」EEPROMファイルもフラッシュされます。 _これは、Pro Micro ベースの分割キーボードに最適です。_
-* `:avrdude-split-right` - デフォルトオプション(`:avrdude`)と同様に通常のファームウェアが書き込まれます。ただし、分割キーボードの「右側の」EEPROMファイルもフラッシュされます。 _これは、Pro Micro ベースの分割キーボードに最適です。_
+* `:avrdude-split-left` - デフォルトオプション(`:avrdude`)と同様に通常のファームウェアが書き込まれます。ただし、分割キーボードの「左側の」EEPROM ファイルもフラッシュされます。 _これは、Pro Micro ベースの分割キーボードに最適です。_
+* `:avrdude-split-right` - デフォルトオプション(`:avrdude`)と同様に通常のファームウェアが書き込まれます。ただし、分割キーボードの「右側の」EEPROM ファイルもフラッシュされます。 _これは、Pro Micro ベースの分割キーボードに最適です。_
 
 ### HalfKay
 

docs/ja/newbs_getting_started.md

@@ -12,7 +12,7 @@ QMK は、そのソフトウェアの役割を果たし、ボタンの押下を
 カスタムキーマップを作るということは、キーボード上で動くプログラムを作るということなのです。
 
 QMK は、簡単なことは簡単に、そして、難しいことを可能なことにすることで、あなたの手にたくさんのパワーをもたらします。
-パワフルなキーマップを作るためにプログラムを作成する方法を知る必要はありません。いくつかのシンプルな文法に従うだけでOKです。
+パワフルなキーマップを作るためにプログラムを作成する方法を知る必要はありません。いくつかのシンプルな文法に従うだけで OK です。
 
 # はじめに
 

docs/ja/newbs_git_resynchronize_a_branch.md

@@ -7,7 +7,7 @@
 -->
 
 仮にあなたの `master` ブランチにあなたのコミットを行い、そしてあなたの QMK リポジトリの更新が必要になったとします。
-(フォーク元の) QMKの `master` ブランチをあなたの `master` ブランチに `git pull` することもできますが、GitHub は、あなたのブランチが `qmk:master` より何コミットか先行していると通知します、この状態で QMK にプルリクエストを行う場合、問題が発生する可能性があります。
+(フォーク元の) QMK の `master` ブランチをあなたの `master` ブランチに `git pull` することもできますが、GitHub は、あなたのブランチが `qmk:master` より何コミットか先行していると通知します、この状態で QMK にプルリクエストを行う場合、問題が発生する可能性があります。
 (訳注：この通知は、GitHub のあなたのリポジトリの code ペインのブランチ選択メニューの下のあたりで `This branch is 3 commit ahead of qmk:master` という様な文面で表示されています。)
 
 ?> このドキュメントは [あなたのフォークの master ブランチ: 更新は頻繁に、コミットはしないこと](ja/newbs_git_using_your_master_branch.md) で詳述されている概念に基づいています。その概念に慣れていない場合は、まずそれを読んでから、ここに戻ってください。  

docs/ja/newbs_git_using_your_master_branch.md

@@ -41,7 +41,7 @@ upstream        https://github.com/qmk/qmk_firmware.git (push)
 このコマンドは `upstream` というニックネームを持つ QMK リポジトリから、ブランチとタグ — "refs" と総称されます — を取得します。
 これで、あなたのフォーク `origin` のデータを QMK が保持するデータと比較できます。
 
-あなたのフォークの `master` を更新するには、次を実行します、各行の後にEnterキーを押してください:
+あなたのフォークの `master` を更新するには、次を実行します、各行の後に Enter キーを押してください:
 
 ```
 git checkout master
@@ -98,4 +98,4 @@ git commit -m "My commit message."
 
 最後のステップは、変更をフォークにプッシュすることです。
 これを行うには、`git push`と入力します。
-Gitは、 `dev_branch`の現在の状態をフォークに公開します。
+Git は、 `dev_branch`の現在の状態をフォークに公開します。

docs/ja/newbs_learn_more_resources.md

@@ -6,7 +6,7 @@
   git diff ed0575fc8 HEAD -- docs/newbs_learn_more_resources.md | cat
 -->
 
-これらのリソースは、QMKコミュニティの新しいメンバーに、初心者向けドキュメントで提供されている情報に対する理解を深めることを目的としています。
+これらのリソースは、QMK コミュニティの新しいメンバーに、初心者向けドキュメントで提供されている情報に対する理解を深めることを目的としています。
 
 ## Git に関するリース:
 

docs/ja/newbs_testing_debugging.md

@@ -12,7 +12,7 @@
 
 通常、キーボードをテストするのは非常に簡単です。全てのキーをひとつずつ押して、期待されるキーが送信されていることを確認します。キーを押したことを見逃さないためのプログラムもあります。
 
-メモ：　これらのプログラムはQMKによって提供・承認されたものではありません。
+メモ：　これらのプログラムは QMK によって提供・承認されたものではありません。
 
 * [QMK Configurator](https://config.qmk.fm/#/test/) (Web Based)
 * [Switch Hitter](https://web.archive.org/web/20190413233743/https://elitekeyboards.com/switchhitter.php) (Windows Only)
@@ -40,7 +40,7 @@ void keyboard_post_init_user(void) {
 
 ### hid_listenを使ったデバッグ
 
-ターミナルベースの方法がお好みですか？PJRCが提供する[hid_listen](https://www.pjrc.com/teensy/hid_listen.html)もデバッグメッセージの表示に使用できます。ビルド済みの実行ファイルはWindows, Linux, MacOS用が用意されています。
+ターミナルベースの方法がお好みですか？PJRC が提供する[hid_listen](https://www.pjrc.com/teensy/hid_listen.html)もデバッグメッセージの表示に使用できます。ビルド済みの実行ファイルは Windows, Linux, MacOS 用が用意されています。
 
 <!-- FIXME: Describe the debugging messages here. -->
 
@@ -50,7 +50,7 @@ void keyboard_post_init_user(void) {
 
     #include <print.h>
 
-そのあとは、いくつかの異なったprint関数を使用することが出来ます。
+そのあとは、いくつかの異なった print 関数を使用することが出来ます。
 
 * `print("string")`: シンプルな文字列を出力します
 * `uprintf("%s string", var)`: フォーマットされた文字列を出力します

drivers/arm/i2c_master.c

@@ -29,8 +29,6 @@
 #include <string.h>
 #include <hal.h>
 
-static uint8_t i2c_address;
-
 static const I2CConfig i2cconfig = {
 #ifdef USE_I2CV1
     I2C1_OPMODE,
@@ -71,27 +69,49 @@ __attribute__((weak)) void i2c_init(void) {
 }
 
 i2c_status_t i2c_start(uint8_t address) {
-    i2c_address = address;
+#if I2C_USE_MUTUAL_EXCLUSION
+    i2cAcquireBus(&I2C_DRIVER);
+#endif
+
     i2cStart(&I2C_DRIVER, &i2cconfig);
     return I2C_STATUS_SUCCESS;
 }
 
 i2c_status_t i2c_transmit(uint8_t address, const uint8_t* data, uint16_t length, uint16_t timeout) {
-    i2c_address = address;
+#if I2C_USE_MUTUAL_EXCLUSION
+    i2cAcquireBus(&I2C_DRIVER);
+#endif
+
     i2cStart(&I2C_DRIVER, &i2cconfig);
-    msg_t status = i2cMasterTransmitTimeout(&I2C_DRIVER, (i2c_address >> 1), data, length, 0, 0, MS2ST(timeout));
+    msg_t status = i2cMasterTransmitTimeout(&I2C_DRIVER, (address >> 1), data, length, 0, 0, MS2ST(timeout));
+
+#if I2C_USE_MUTUAL_EXCLUSION
+    i2cReleaseBus(&I2C_DRIVER);
+#endif
+
     return chibios_to_qmk(&status);
 }
 
 i2c_status_t i2c_receive(uint8_t address, uint8_t* data, uint16_t length, uint16_t timeout) {
-    i2c_address = address;
+#if I2C_USE_MUTUAL_EXCLUSION
+    i2cAcquireBus(&I2C_DRIVER);
+#endif
+
     i2cStart(&I2C_DRIVER, &i2cconfig);
-    msg_t status = i2cMasterReceiveTimeout(&I2C_DRIVER, (i2c_address >> 1), data, length, MS2ST(timeout));
+    msg_t status = i2cMasterReceiveTimeout(&I2C_DRIVER, (address >> 1), data, length, MS2ST(timeout));
+
+#if I2C_USE_MUTUAL_EXCLUSION
+    i2cReleaseBus(&I2C_DRIVER);
+#endif
+
     return chibios_to_qmk(&status);
 }
 
 i2c_status_t i2c_writeReg(uint8_t devaddr, uint8_t regaddr, const uint8_t* data, uint16_t length, uint16_t timeout) {
-    i2c_address = devaddr;
+#if I2C_USE_MUTUAL_EXCLUSION
+    i2cAcquireBus(&I2C_DRIVER);
+#endif
+
     i2cStart(&I2C_DRIVER, &i2cconfig);
 
     uint8_t complete_packet[length + 1];
@@ -100,15 +120,34 @@ i2c_status_t i2c_writeReg(uint8_t devaddr, uint8_t regaddr, const uint8_t* data,
     }
     complete_packet[0] = regaddr;
 
-    msg_t status = i2cMasterTransmitTimeout(&I2C_DRIVER, (i2c_address >> 1), complete_packet, length + 1, 0, 0, MS2ST(timeout));
+    msg_t status = i2cMasterTransmitTimeout(&I2C_DRIVER, (devaddr >> 1), complete_packet, length + 1, 0, 0, MS2ST(timeout));
+
+#if I2C_USE_MUTUAL_EXCLUSION
+    i2cReleaseBus(&I2C_DRIVER);
+#endif
+
     return chibios_to_qmk(&status);
 }
 
 i2c_status_t i2c_readReg(uint8_t devaddr, uint8_t regaddr, uint8_t* data, uint16_t length, uint16_t timeout) {
-    i2c_address = devaddr;
+#if I2C_USE_MUTUAL_EXCLUSION
+    i2cAcquireBus(&I2C_DRIVER);
+#endif
+
     i2cStart(&I2C_DRIVER, &i2cconfig);
-    msg_t status = i2cMasterTransmitTimeout(&I2C_DRIVER, (i2c_address >> 1), &regaddr, 1, data, length, MS2ST(timeout));
+    msg_t status = i2cMasterTransmitTimeout(&I2C_DRIVER, (devaddr >> 1), &regaddr, 1, data, length, MS2ST(timeout));
+
+#if I2C_USE_MUTUAL_EXCLUSION
+    i2cReleaseBus(&I2C_DRIVER);
+#endif
+
     return chibios_to_qmk(&status);
 }
 
-void i2c_stop(void) { i2cStop(&I2C_DRIVER); }
+void i2c_stop(void) {
+    i2cStop(&I2C_DRIVER);
+
+#if I2C_USE_MUTUAL_EXCLUSION
+    i2cReleaseBus(&I2C_DRIVER);
+#endif
+}

drivers/boards/STM32_F103_STM32DUINO/board.h

@@ -24,8 +24,8 @@
 /*
  * Board identifier.
  */
-#define BOARD_GENERIC_STM32_F103
-#define BOARD_NAME              "Generic STM32F103x board"
+#define BOARD_STM32_F103_STM32DUINO
+#define BOARD_NAME              "GENERIC STM32F103C8T6 board - stm32duino bootloader"
 
 /*
  * Board frequencies.

drivers/boards/STM32_F103_STM32DUINO/board.mk

@@ -0,0 +1,5 @@
+# List of all the board related files.
+BOARDSRC = $(BOARD_PATH)/boards/STM32_F103_STM32DUINO/board.c
+
+# Required include directories
+BOARDINC = $(BOARD_PATH)/boards/STM32_F103_STM32DUINO

drivers/eeprom/eeprom_custom.c-template

@@ -0,0 +1,46 @@
+/* Copyright 2019 Nick Brassel (tzarc)
+ *
+ * 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 <stdint.h>
+#include <string.h>
+
+#include "eeprom_driver.h"
+
+void eeprom_driver_init(void) {
+    /* Any initialisation code */
+ }
+
+void eeprom_driver_erase(void) {
+    /* Wipe out the EEPROM, setting values to zero */
+}
+
+void eeprom_read_block(void *buf, const void *addr, size_t len) {
+    /*
+        Read a block of data:
+            buf: target buffer
+            addr: 0-based offset within the EEPROM
+            len: length to read
+     */
+}
+
+void eeprom_write_block(const void *buf, void *addr, size_t len) {
+    /*
+        Write a block of data:
+            buf: target buffer
+            addr: 0-based offset within the EEPROM
+            len: length to write
+     */
+}

drivers/eeprom/eeprom_driver.c

@@ -0,0 +1,73 @@
+/* Copyright 2019 Nick Brassel (tzarc)
+ *
+ * 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 <stdint.h>
+#include <string.h>
+
+#include "eeprom_driver.h"
+
+uint8_t eeprom_read_byte(const uint8_t *addr) {
+    uint8_t ret;
+    eeprom_read_block(&ret, addr, 1);
+    return ret;
+}
+
+uint16_t eeprom_read_word(const uint16_t *addr) {
+    uint16_t ret;
+    eeprom_read_block(&ret, addr, 2);
+    return ret;
+}
+
+uint32_t eeprom_read_dword(const uint32_t *addr) {
+    uint32_t ret;
+    eeprom_read_block(&ret, addr, 4);
+    return ret;
+}
+
+void eeprom_write_byte(uint8_t *addr, uint8_t value) { eeprom_write_block(&value, addr, 1); }
+
+void eeprom_write_word(uint16_t *addr, uint16_t value) { eeprom_write_block(&value, addr, 2); }
+
+void eeprom_write_dword(uint32_t *addr, uint32_t value) { eeprom_write_block(&value, addr, 4); }
+
+void eeprom_update_block(const void *buf, void *addr, size_t len) {
+    uint8_t read_buf[len];
+    eeprom_read_block(read_buf, addr, len);
+    if (memcmp(buf, read_buf, len) != 0) {
+        eeprom_write_block(buf, addr, len);
+    }
+}
+
+void eeprom_update_byte(uint8_t *addr, uint8_t value) {
+    uint8_t orig = eeprom_read_byte(addr);
+    if (orig != value) {
+        eeprom_write_byte(addr, value);
+    }
+}
+
+void eeprom_update_word(uint16_t *addr, uint16_t value) {
+    uint16_t orig = eeprom_read_word(addr);
+    if (orig != value) {
+        eeprom_write_word(addr, value);
+    }
+}
+
+void eeprom_update_dword(uint32_t *addr, uint32_t value) {
+    uint32_t orig = eeprom_read_dword(addr);
+    if (orig != value) {
+        eeprom_write_dword(addr, value);
+    }
+}

drivers/eeprom/eeprom_driver.h

@@ -0,0 +1,22 @@
+/* Copyright 2019 Nick Brassel (tzarc)
+ *
+ * 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
+
+#include "eeprom.h"
+
+void eeprom_driver_init(void);
+void eeprom_driver_erase(void);