From 15864029246333fe72e9fb4beea85a57c1666b74 Mon Sep 17 00:00:00 2001 From: tzarc Date: Tue, 28 Nov 2023 05:42:53 +0000 Subject: [PATCH] =?UTF-8?q?Deploying=20to=20gh-pages=20from=20@=20qmk/qmk?= =?UTF-8?q?=5Ffirmware@0115951de12bd4c798a43a380651c34552552e85=20?= =?UTF-8?q?=F0=9F=9A=80?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ChangeLog/20231126.md | 336 ++++++++++++++++++++++++++++++++++++ _summary.md | 6 +- adc_driver.md | 2 +- apa102_driver.md | 49 ++++++ breaking_changes.md | 20 +-- breaking_changes_history.md | 1 + cli_commands.md | 125 ++++++++++++++ custom_quantum_functions.md | 59 +++++++ eeprom_driver.md | 20 ++- feature_auto_shift.md | 18 +- feature_backlight.md | 15 +- feature_led_matrix.md | 55 +++--- feature_oled_driver.md | 42 ++++- feature_os_detection.md | 9 +- feature_pointing_device.md | 65 +++++++ feature_rgb_matrix.md | 286 +++++++++++++++--------------- feature_rgblight.md | 37 +++- feature_split_keyboard.md | 2 +- feature_stenography.md | 6 +- feature_velocikey.md | 29 ---- i2c_driver.md | 12 ++ ja/_summary.md | 1 - ja/feature_velocikey.md | 34 ---- newbs_external_userspace.md | 96 +++++++++++ quantum_painter.md | 209 +++++++++++++++------- quantum_painter_lvgl.md | 8 + reference_info_json.md | 172 ++++++++++++++++-- reference_keymap_extras.md | 1 - spi_driver.md | 17 ++ squeezing_avr.md | 1 + uart_driver.md | 12 ++ unit_testing.md | 4 +- ws2812_driver.md | 278 ++++++++++++++++------------- zh-cn/_summary.md | 1 - 34 files changed, 1555 insertions(+), 473 deletions(-) create mode 100644 ChangeLog/20231126.md create mode 100644 apa102_driver.md delete mode 100644 feature_velocikey.md delete mode 100644 ja/feature_velocikey.md create mode 100644 newbs_external_userspace.md diff --git a/ChangeLog/20231126.md b/ChangeLog/20231126.md new file mode 100644 index 00000000000..61cff520c80 --- /dev/null +++ b/ChangeLog/20231126.md @@ -0,0 +1,336 @@ +# QMK Breaking Changes - 2023 November 26 Changelog + +## Notable Features :id=notable-features + +As per last few breaking changes cycles, there have been _a lot_ of behind-the-scenes changes, mainly around consolidation of config into `info.json` files, cleanup of `info.json` files, cleaning up driver naming, as well as addressing technical debt. + +As a followup to last cycle's [notable changes](20230827.md#notable-changes), as `qmk/qmk_firmware` is no longer accepting PRs for keymaps we're pleased to announce that storing and building keymaps externally from the normal QMK Firmware repository is now possible. This is done through the new [External Userspace](newbs_external_userspace.md) feature, more details below! + +## Changes Requiring User Action :id=changes-requiring-user-action + +### Updated Keyboard Codebases :id=updated-keyboard-codebases + +| Old Keyboard Name | New Keyboard Name | +|---------------------------------------|-------------------------------| +| adm42 | adm42/rev4 | +| dp3000 | dp3000/rev1 | +| handwired/dactyl_manuform/dmote/62key | handwired/dmote | +| keychron/q0/rev_0130 | keychron/q0/base | +| keychron/q0/rev_0131 | keychron/q0/plus | +| keychron/q1/ansi | keychron/q1v1/ansi | +| keychron/q1/ansi_encoder | keychron/q1v1/ansi_encoder | +| keychron/q1/iso | keychron/q1v1/iso | +| keychron/q1/iso_encoder | keychron/q1v1/iso_encoder | +| keychron/q4/ansi_v1 | keychron/q4/ansi | +| kprepublic/bm40hsrgb | kprepublic/bm40hsrgb/rev1 | +| matchstickworks/southpad | matchstickworks/southpad/rev2 | +| soda/mango | magic_force/mf17 | +| soda/pocket | magic_force/mf34 | +| studiokestra/line_tkl | studiokestra/line_friends_tkl | +| ymdk/melody96 | ymdk/melody96/soldered | + +## Notable core changes :id=notable-core + +### External Userspace ([#22222](https://github.com/qmk/qmk_firmware/pull/22222)) + +As mentioned above, the new External Userspace feature allows for keymaps to be stored and built externally from the main QMK Firmware repository. This allows for keymaps to be stored separately -- usually in their own repository -- and for users to be able to maintain and build their keymaps without needing to fork the main QMK Firmware repository. + +See the [External Userspace documentation](newbs_external_userspace.md) for more details. + +A significant portion of user keymaps have already been removed from `qmk/qmk_firmware` and more will follow in coming weeks. You can still recover your keymap from the tag [user-keymaps-still-present](https://github.com/qmk/qmk_firmware/tree/user-keymaps-still-present) if required -- a perfect time to migrate to the new External Userspace! + +!> This feature is still in beta, and we're looking for feedback on it. Please try it out and let us know what you think -- a new `#help-userspace` channel has been set up on Discord. + +### Improve and Cleanup Shutdown callbacks ([#21060](https://github.com/qmk/qmk_firmware/pull/20160)) :id=improve-and-cleanup-shutdown-callbacks + +Shutdown callbacks at the keyboard level were never present, preventing safe shutdown sequencing for peripherals such as OLEDs, RGB LEDs, and other devices. This PR adds a new `shutdown_kb` function, as well as amending `shutdown_user`, allowing for safe shutdown of peripherals at both keyboard and keymap level. + +See the [Keyboard Shutdown/Reboot Code](custom_quantum_functions.md#keyboard-shutdown-reboot-code) documentation for more details. + +### OLED Force Flush ([#20953](https://github.com/qmk/qmk_firmware/pull/20953)) :id=oled-force-flush + +Along with the new `shutdown_kb` function, a new API `oled_render_dirty(bool)` function has been added. This allows OLED contents to be written deterministically when supplied with `true` -- that is, the OLED will be updated immediately, rather than waiting for the next OLED update cycle. This allows for OLEDs to show things such as "BOOTLOADER MODE" and the like if resetting to bootloader from QMK. + +### Switch statement helpers for keycode ranges ([#20059](https://github.com/qmk/qmk_firmware/pull/20059)) :id=switch-statement-helpers-for-keycode-ranges + +Predefined ranges usable within switch statements have been added for groups of similar keycodes, where people who wish to handle entire blocks at once can do so. This allows keymaps to be immune to changes in keycode values, and also allows for more efficient code generation. + +The ranges are as follows: + +| Name | Mapping | +|-------------------------------------|------------------------------------------------------------------------| +| `INTERNAL_KEYCODE_RANGE` | `KC_NO ... KC_TRANSPARENT` | +| `BASIC_KEYCODE_RANGE` | `KC_A ... KC_EXSEL` | +| `SYSTEM_KEYCODE_RANGE` | `KC_SYSTEM_POWER ... KC_SYSTEM_WAKE` | +| `CONSUMER_KEYCODE_RANGE` | `KC_AUDIO_MUTE ... KC_LAUNCHPAD` | +| `MOUSE_KEYCODE_RANGE` | `KC_MS_UP ... KC_MS_ACCEL2` | +| `MODIFIER_KEYCODE_RANGE` | `KC_LEFT_CTRL ... KC_RIGHT_GUI` | +| `SWAP_HANDS_KEYCODE_RANGE` | `QK_SWAP_HANDS_TOGGLE ... QK_SWAP_HANDS_ONE_SHOT` | +| `MAGIC_KEYCODE_RANGE` | `QK_MAGIC_SWAP_CONTROL_CAPS_LOCK ... QK_MAGIC_TOGGLE_ESCAPE_CAPS_LOCK` | +| `MIDI_KEYCODE_RANGE` | `QK_MIDI_ON ... QK_MIDI_PITCH_BEND_UP` | +| `SEQUENCER_KEYCODE_RANGE` | `QK_SEQUENCER_ON ... QK_SEQUENCER_STEPS_CLEAR` | +| `JOYSTICK_KEYCODE_RANGE` | `QK_JOYSTICK_BUTTON_0 ... QK_JOYSTICK_BUTTON_31` | +| `PROGRAMMABLE_BUTTON_KEYCODE_RANGE` | `QK_PROGRAMMABLE_BUTTON_1 ... QK_PROGRAMMABLE_BUTTON_32` | +| `AUDIO_KEYCODE_RANGE` | `QK_AUDIO_ON ... QK_AUDIO_VOICE_PREVIOUS` | +| `STENO_KEYCODE_RANGE` | `QK_STENO_BOLT ... QK_STENO_COMB_MAX` | +| `MACRO_KEYCODE_RANGE` | `QK_MACRO_0 ... QK_MACRO_31` | +| `BACKLIGHT_KEYCODE_RANGE` | `QK_BACKLIGHT_ON ... QK_BACKLIGHT_TOGGLE_BREATHING` | +| `RGB_KEYCODE_RANGE` | `RGB_TOG ... RGB_MODE_TWINKLE` | +| `QUANTUM_KEYCODE_RANGE` | `QK_BOOTLOADER ... QK_ALT_REPEAT_KEY` | +| `KB_KEYCODE_RANGE` | `QK_KB_0 ... QK_KB_31` | +| `USER_KEYCODE_RANGE` | `QK_USER_0 ... QK_USER_31` | + +Usage: + +```c + switch (keycode) { + case KC_A ... KC_EXSEL: + case KC_LEFT_CTRL ... KC_RIGHT_GUI: + /* do stuff with basic and modifier keycodes */ +``` + +Becomes: + +```c + switch (keycode) { + case BASIC_KEYCODE_RANGE: + case MODIFIER_KEYCODE_RANGE: + /* do stuff with basic and modifier keycodes */ +``` + +### Quantum Painter OLED support ([#19997](https://github.com/qmk/qmk_firmware/pull/19997)) :id=quantum-painter-oled-support + +Quantum Painter has picked up support for SH1106 displays -- commonly seen as 128x64 OLEDs. Support for both I2C and SPI displays is available. + +If you're already using OLED through `OLED_DRIVER_ENABLE = yes` or equivalent in `info.json` and wish to use Quantum Painter instead, you'll need to disable the old OLED system, instead enabling Quantum Painter as well as enabling the appropriate SH1106 driver. See the [Quantum Painter driver documentation](quantum_painter.md#quantum-painter-drivers) for more details. The old OLED driver is still available, and keymaps do not require migrating to Quantum Painter if you don't want to do so. + +### RGB/LED lighting driver naming and cleanup ([#21890](https://github.com/qmk/qmk_firmware/pull/21890), [#21891](https://github.com/qmk/qmk_firmware/pull/21891), [#21892](https://github.com/qmk/qmk_firmware/pull/21892), [#21903](https://github.com/qmk/qmk_firmware/pull/21903), [#21904](https://github.com/qmk/qmk_firmware/pull/21904), [#21905](https://github.com/qmk/qmk_firmware/pull/21905), [#21918](https://github.com/qmk/qmk_firmware/pull/21918), [#21929](https://github.com/qmk/qmk_firmware/pull/21929), [#21938](https://github.com/qmk/qmk_firmware/pull/21938), [#22004](https://github.com/qmk/qmk_firmware/pull/22004), [#22008](https://github.com/qmk/qmk_firmware/pull/22008), [#22009](https://github.com/qmk/qmk_firmware/pull/22009), [#22071](https://github.com/qmk/qmk_firmware/pull/22071), [#22090](https://github.com/qmk/qmk_firmware/pull/22090), [#22099](https://github.com/qmk/qmk_firmware/pull/22099), [#22126](https://github.com/qmk/qmk_firmware/pull/22126), [#22133](https://github.com/qmk/qmk_firmware/pull/22133), [#22163](https://github.com/qmk/qmk_firmware/pull/22163), [#22200](https://github.com/qmk/qmk_firmware/pull/22200), [#22308](https://github.com/qmk/qmk_firmware/pull/22308), [#22309](https://github.com/qmk/qmk_firmware/pull/22309), [#22311](https://github.com/qmk/qmk_firmware/pull/22311), [#22325](https://github.com/qmk/qmk_firmware/pull/22325), [#22365](https://github.com/qmk/qmk_firmware/pull/22365), [#22379](https://github.com/qmk/qmk_firmware/pull/22379), [#22380](https://github.com/qmk/qmk_firmware/pull/22380), [#22381](https://github.com/qmk/qmk_firmware/pull/22381), [#22383](https://github.com/qmk/qmk_firmware/pull/22383), [#22436](https://github.com/qmk/qmk_firmware/pull/22436)) + +As you can probably tell by the list of PRs just above, there has been a lot of cleanup and consolidation this cycle when it comes to RGB/LED lighting drivers. The number of changes is too large to list here, but the general theme has been focusing on consistency of naming, both of drivers themselves and their respective implementation and configuration. Most changes only affect keyboard designers -- if you find that your in-development keyboard is no longer building due to naming of defines changing, your best bet is to refer to another board already in the repository which has had the changes applied. + +### Peripheral subsystem enabling ([#22253](https://github.com/qmk/qmk_firmware/pull/22253), [#22448](https://github.com/qmk/qmk_firmware/pull/22448), [#22106](https://github.com/qmk/qmk_firmware/pull/22106)) :id=peripheral-subsystem-enabling + +When enabling peripherals such as I2C, SPI, or Analog/ADC, some required manual inclusion of source files in order to provide driver support, and in some cases, when multiple drivers were using the same underlying peripheral, files were being added to the build multiple times. + +Most systems requiring other peripherals now mark their respective dependencies as "required", allowing the build system to check whether peripherals are necessary before including them in the build rather than having each location enable them manually. + +For a concrete example, users or keyboard designers who previously added `SRC += analog.c` in order to allow for analog readings via an ADC now should specify `ANALOG_DRIVER_REQUIRED = yes` instead. The full list of added options is as follows: + +| New option | Old Equivalent | +|--------------------------------|------------------------------------------------------------| +| `ANALOG_DRIVER_REQUIRED = yes` | `SRC += analog.c` | +| `APA102_DRIVER_REQUIRED = yes` | `SRC += apa102.c` | +| `I2C_DRIVER_REQUIRED = yes` | `SRC += i2c_master.c` or `QUANTUM_LIB_SRC += i2c_master.c` | +| `SPI_DRIVER_REQUIRED = yes` | `SRC += spi_master.c` or `QUANTUM_LIB_SRC += spi_master.c` | +| `UART_DRIVER_REQUIRED = yes` | `SRC += uart.c` | +| `WS2812_DRIVER_REQUIRED = yes` | `SRC += ws2812.c` | + +### NKRO on V-USB boards ([#22398](https://github.com/qmk/qmk_firmware/pull/22398)) :id=vusb-nkro + +NKRO is now available for ATmega32A and 328P-based keyboards (including PS2AVRGB/Bootmapper boards), thanks to some internal refactoring and cleanup. To enable it, the process is the same as always - add `NKRO_ENABLE = yes` to your `rules.mk`, then assign and press the `NK_TOGG` keycode to switch modes. + +## Full changelist :id=full-changelist + +Core: +* Compilation warning if both `keymap.json` and `keymap.c` exist ([#19939](https://github.com/qmk/qmk_firmware/pull/19939)) +* [QP] Add support for OLED, variable framebuffer bpp ([#19997](https://github.com/qmk/qmk_firmware/pull/19997)) +* Generate switch statement helpers for keycode ranges ([#20059](https://github.com/qmk/qmk_firmware/pull/20059)) +* Chibios SPI driver: allow some SPI pins to be left unassigned ([#20315](https://github.com/qmk/qmk_firmware/pull/20315)) +* Take care of scroll divisor remainders for PS/2 drag scroll ([#20732](https://github.com/qmk/qmk_firmware/pull/20732)) +* Add `RGBLIGHT_DEFAULT_ON` macro configuration option ([#20857](https://github.com/qmk/qmk_firmware/pull/20857)) +* Allow force flush of oled display. ([#20953](https://github.com/qmk/qmk_firmware/pull/20953)) +* Improve and Cleanup Shutdown callbacks ([#21060](https://github.com/qmk/qmk_firmware/pull/21060)) +* [Enhancement] QP Getters ([#21171](https://github.com/qmk/qmk_firmware/pull/21171)) +* Russian typewriter keymap file for popular legacy layout. ([#21174](https://github.com/qmk/qmk_firmware/pull/21174)) +* Improve directional transition of overlapping mouse keys ([#21494](https://github.com/qmk/qmk_firmware/pull/21494)) +* Add full solenoid support on split keyboards ([#21583](https://github.com/qmk/qmk_firmware/pull/21583)) +* Reduce popping during audio initialization using the additive DAC ([#21642](https://github.com/qmk/qmk_firmware/pull/21642)) +* [Maintenance] USB HID control packet as struct ([#21688](https://github.com/qmk/qmk_firmware/pull/21688)) +* Bump mouse endpoint packet size to 16 bytes ([#21711](https://github.com/qmk/qmk_firmware/pull/21711)) +* Allow customizing PWM frequency ([#21717](https://github.com/qmk/qmk_firmware/pull/21717)) +* Add simpler method for relocating functions to RAM. ([#21804](https://github.com/qmk/qmk_firmware/pull/21804)) +* Clean up RGB LED type ([#21859](https://github.com/qmk/qmk_firmware/pull/21859)) +* is31fl3741: Allow changing config register ([#21861](https://github.com/qmk/qmk_firmware/pull/21861)) +* Add _DEFAULT_ON lighting configuration options ([#21865](https://github.com/qmk/qmk_firmware/pull/21865)) +* Modify split config is_keyboard_master/left checks. ([#21875](https://github.com/qmk/qmk_firmware/pull/21875)) +* Remove old `IS_LED_ON/OFF()` macros ([#21878](https://github.com/qmk/qmk_firmware/pull/21878)) +* ckled2001: driver naming cleanups ([#21890](https://github.com/qmk/qmk_firmware/pull/21890)) +* aw20216: driver naming cleanups ([#21891](https://github.com/qmk/qmk_firmware/pull/21891)) +* is31fl3218: driver naming cleanups ([#21892](https://github.com/qmk/qmk_firmware/pull/21892)) +* is31fl3736: driver naming cleanups ([#21903](https://github.com/qmk/qmk_firmware/pull/21903)) +* is31fl3737: driver naming cleanups ([#21904](https://github.com/qmk/qmk_firmware/pull/21904)) +* is31fl3733: driver naming cleanups ([#21905](https://github.com/qmk/qmk_firmware/pull/21905)) +* Enable RP2040 support for apa102 RGB LED driver ([#21908](https://github.com/qmk/qmk_firmware/pull/21908)) +* is31fl3731: driver naming cleanups ([#21918](https://github.com/qmk/qmk_firmware/pull/21918)) +* is31fl3741: driver naming cleanups ([#21929](https://github.com/qmk/qmk_firmware/pull/21929)) +* refactor: move default RGB/LED matrix #defines ([#21938](https://github.com/qmk/qmk_firmware/pull/21938)) +* Added flower blooming on RGB Matrix effect ([#21948](https://github.com/qmk/qmk_firmware/pull/21948)) +* Remove 'Firmware size check does not yet support' message ([#21977](https://github.com/qmk/qmk_firmware/pull/21977)) +* chibios: mark boot2 bootlader data readonly ([#21986](https://github.com/qmk/qmk_firmware/pull/21986)) +* Complete RGB Matrix support for IS31FL3218 ([#22004](https://github.com/qmk/qmk_firmware/pull/22004)) +* Default wear leveling logical size to half backing ([#22006](https://github.com/qmk/qmk_firmware/pull/22006)) +* chibios: disable RWX segment warning on newer GNU lds ([#22007](https://github.com/qmk/qmk_firmware/pull/22007)) +* Add and use I2C address defines for ISSI LED drivers ([#22008](https://github.com/qmk/qmk_firmware/pull/22008)) +* Add and use PWM frequency defines for ISSI LED drivers ([#22009](https://github.com/qmk/qmk_firmware/pull/22009)) +* directly use object files when linking ELF ([#22025](https://github.com/qmk/qmk_firmware/pull/22025)) +* Lvgl rate control ([#22049](https://github.com/qmk/qmk_firmware/pull/22049)) +* Rename CKLED2001 driver to SNLED27351 ([#22071](https://github.com/qmk/qmk_firmware/pull/22071)) +* Move `PACKED` define to util.h ([#22074](https://github.com/qmk/qmk_firmware/pull/22074)) +* Simplify more feature driver defines ([#22090](https://github.com/qmk/qmk_firmware/pull/22090)) +* Update ISSI LED types ([#22099](https://github.com/qmk/qmk_firmware/pull/22099)) +* Move velocikey to within rgblight ([#22123](https://github.com/qmk/qmk_firmware/pull/22123)) +* is31fl3218: Add LED Matrix support ([#22126](https://github.com/qmk/qmk_firmware/pull/22126)) +* Set default board files for uf2boot bootloader ([#22129](https://github.com/qmk/qmk_firmware/pull/22129)) +* is31fl3736: extract single-color API ([#22133](https://github.com/qmk/qmk_firmware/pull/22133)) +* is31fl3737/3741: add LED Matrix support ([#22163](https://github.com/qmk/qmk_firmware/pull/22163)) +* Rename `DRIVER_ADDR_n` defines ([#22200](https://github.com/qmk/qmk_firmware/pull/22200)) +* New RGB Animations - 4 "Starlight" Animation Variations ([#22212](https://github.com/qmk/qmk_firmware/pull/22212)) +* QMK Userspace ([#22222](https://github.com/qmk/qmk_firmware/pull/22222)) +* Dedupe I2C, SPI, UART driver inclusions ([#22253](https://github.com/qmk/qmk_firmware/pull/22253)) +* Add "AC Next Keyboard Layout Select" consumer usage entry (macOS Globe key) ([#22256](https://github.com/qmk/qmk_firmware/pull/22256)) +* Separate 6KRO and NKRO report structs ([#22267](https://github.com/qmk/qmk_firmware/pull/22267)) +* Azoteq IQS5xx support ([#22280](https://github.com/qmk/qmk_firmware/pull/22280)) +* Add `_flush()` functions to LED drivers ([#22308](https://github.com/qmk/qmk_firmware/pull/22308)) +* Add `_LED_COUNT` defines to LED drivers ([#22309](https://github.com/qmk/qmk_firmware/pull/22309)) +* Infer LED DRIVER_COUNT from configured addresses ([#22311](https://github.com/qmk/qmk_firmware/pull/22311)) +* Added gamma values for ST7735 displays ([#22313](https://github.com/qmk/qmk_firmware/pull/22313)) +* Consolidate some EEPROM Driver configuration ([#22321](https://github.com/qmk/qmk_firmware/pull/22321)) +* V-USB: Add generic `send_report()` function ([#22323](https://github.com/qmk/qmk_firmware/pull/22323)) +* V-USB: Implement `GET_PROTOCOL` and `SET_PROTOCOL` handling ([#22324](https://github.com/qmk/qmk_firmware/pull/22324)) +* RGB/LED matrix use limits size optimisation ([#22325](https://github.com/qmk/qmk_firmware/pull/22325)) +* Relocate LED driver init code ([#22365](https://github.com/qmk/qmk_firmware/pull/22365)) +* WT RGB cleanups ([#22379](https://github.com/qmk/qmk_firmware/pull/22379)) +* LED drivers: use `PACKED` define from util.h ([#22380](https://github.com/qmk/qmk_firmware/pull/22380)) +* LED drivers: clean up `SWx`/`CSy` pullup/down resistor config ([#22381](https://github.com/qmk/qmk_firmware/pull/22381)) +* LED drivers: add defines for PWM and LED control register counts ([#22383](https://github.com/qmk/qmk_firmware/pull/22383)) +* V-USB: implement NKRO ([#22398](https://github.com/qmk/qmk_firmware/pull/22398)) +* Allow generic_features to handle subdirectories ([#22400](https://github.com/qmk/qmk_firmware/pull/22400)) +* Migrate some common features to generic ([#22403](https://github.com/qmk/qmk_firmware/pull/22403)) +* Remove requirement for `keymap_steno.h` include in keymaps ([#22423](https://github.com/qmk/qmk_firmware/pull/22423)) +* LED drivers: register naming cleanups ([#22436](https://github.com/qmk/qmk_firmware/pull/22436)) +* Slight refactor of joystick axis type into typedef ([#22445](https://github.com/qmk/qmk_firmware/pull/22445)) +* Generalise analog SRC inclusion ([#22448](https://github.com/qmk/qmk_firmware/pull/22448)) +* Revert "chibios: disable RWX segment warning on newer GNU lds" ([#22469](https://github.com/qmk/qmk_firmware/pull/22469)) +* chibios: disable RWX segment warning on newer GNU lds ([#22471](https://github.com/qmk/qmk_firmware/pull/22471)) + +CLI: +* Implement data driven lighting defaults ([#21825](https://github.com/qmk/qmk_firmware/pull/21825)) +* Generate keymap.json config options more forcefully ([#21960](https://github.com/qmk/qmk_firmware/pull/21960)) +* Implement data driven dip switches ([#22017](https://github.com/qmk/qmk_firmware/pull/22017)) +* Improve argument handling of c2json ([#22170](https://github.com/qmk/qmk_firmware/pull/22170)) +* Support additional split sync items for info.json ([#22193](https://github.com/qmk/qmk_firmware/pull/22193)) +* CLI refactoring for common build target APIs ([#22221](https://github.com/qmk/qmk_firmware/pull/22221)) +* Add dd mapping for hardware based split handedness ([#22369](https://github.com/qmk/qmk_firmware/pull/22369)) +* CLI parallel search updates ([#22525](https://github.com/qmk/qmk_firmware/pull/22525)) +* Remove duplicates from search results ([#22528](https://github.com/qmk/qmk_firmware/pull/22528)) + +Keyboards: +* Add KPRepublic/BM40hsrgb rev2 ([#16689](https://github.com/qmk/qmk_firmware/pull/16689)) +* update to data driven - superseeds part of https://github.com/qmk/qmk… ([#20220](https://github.com/qmk/qmk_firmware/pull/20220)) +* Modernize `dactyl_manuform/dmote` keyboard ([#20427](https://github.com/qmk/qmk_firmware/pull/20427)) +* add Skyloong/GK61_V1 keyboard ([#21364](https://github.com/qmk/qmk_firmware/pull/21364)) +* [Refactor] Make changes to some pins ([#21380](https://github.com/qmk/qmk_firmware/pull/21380)) +* Add missing fullsize extended default layouts ([#21402](https://github.com/qmk/qmk_firmware/pull/21402)) +* Add Skyloong/Gk61 PRO keyboard ([#21450](https://github.com/qmk/qmk_firmware/pull/21450)) +* Added skyloong/Qk21 v1 Number Pad ([#21467](https://github.com/qmk/qmk_firmware/pull/21467)) +* matchstickworks/southpad - Move files to rev1, add rev2 ([#21574](https://github.com/qmk/qmk_firmware/pull/21574)) +* partially modernize `dactyl_minidox` ([#21576](https://github.com/qmk/qmk_firmware/pull/21576)) +* tominabox1/le_chiffre oled rework ([#21611](https://github.com/qmk/qmk_firmware/pull/21611)) +* Add Skyloong/Gk61_pro_48 keyboard ([#21654](https://github.com/qmk/qmk_firmware/pull/21654)) +* Adding support for new Waffling60 revision ([#21664](https://github.com/qmk/qmk_firmware/pull/21664)) +* Leeloo revision 2 updates. ([#21671](https://github.com/qmk/qmk_firmware/pull/21671)) +* rename og60 to tofu60 ([#21684](https://github.com/qmk/qmk_firmware/pull/21684)) +* add tofujr v2 keyboard ([#21740](https://github.com/qmk/qmk_firmware/pull/21740)) +* Rotary numpad ([#21744](https://github.com/qmk/qmk_firmware/pull/21744)) +* Update era/divine ([#21767](https://github.com/qmk/qmk_firmware/pull/21767)) +* 1UpKeyboards Pi60 Layout Additions ([#21874](https://github.com/qmk/qmk_firmware/pull/21874)) +* BIOI keyboards: use core UART driver ([#21879](https://github.com/qmk/qmk_firmware/pull/21879)) +* Resolve some "Layout should not contain name of keyboard" lint warnings ([#21898](https://github.com/qmk/qmk_firmware/pull/21898)) +* fc660c/fc980c: clean up actuation point adjustment code ([#21964](https://github.com/qmk/qmk_firmware/pull/21964)) +* Chromatonemini info json revised to support qmk 0.22.2 ([#21966](https://github.com/qmk/qmk_firmware/pull/21966)) +* Migrate spi_flash WEAR_LEVELING_DRIVER to info.json ([#21978](https://github.com/qmk/qmk_firmware/pull/21978)) +* Remove duplication of RP2040 EEPROM defaults ([#21979](https://github.com/qmk/qmk_firmware/pull/21979)) +* Remove duplication of STM32L432 EEPROM defaults ([#21981](https://github.com/qmk/qmk_firmware/pull/21981)) +* Migrate spi EEPROM_DRIVER to info.json ([#21991](https://github.com/qmk/qmk_firmware/pull/21991)) +* Update Keychron Q1v1 ([#21993](https://github.com/qmk/qmk_firmware/pull/21993)) +* Update Keychron Q2 ([#21994](https://github.com/qmk/qmk_firmware/pull/21994)) +* Update Keychron Q3 ([#21995](https://github.com/qmk/qmk_firmware/pull/21995)) +* Update Keychron Q4 ([#21996](https://github.com/qmk/qmk_firmware/pull/21996)) +* Migrate WEAR_LEVELING_*_SIZE to info.json ([#22010](https://github.com/qmk/qmk_firmware/pull/22010)) +* Remove duplication of EEPROM defaults ([#22011](https://github.com/qmk/qmk_firmware/pull/22011)) +* Migrate i2c EEPROM_DRIVER to info.json ([#22013](https://github.com/qmk/qmk_firmware/pull/22013)) +* Remove config.h which only set DYNAMIC_KEYMAP_LAYER_COUNT ([#22034](https://github.com/qmk/qmk_firmware/pull/22034)) +* Add community layout support to tofu60 ([#22041](https://github.com/qmk/qmk_firmware/pull/22041)) +* Update Keychron Q0 ([#22068](https://github.com/qmk/qmk_firmware/pull/22068)) +* Remove custom ISSI lighting code ([#22073](https://github.com/qmk/qmk_firmware/pull/22073)) +* add dp3000 rev2 featuring rgblight ([#22084](https://github.com/qmk/qmk_firmware/pull/22084)) +* Remove ALLOW_WARNINGS and PICO_INTRINSICS_ENABLED ([#22085](https://github.com/qmk/qmk_firmware/pull/22085)) +* Partially migrate `DYNAMIC_KEYMAP_LAYER_COUNT` ([#22087](https://github.com/qmk/qmk_firmware/pull/22087)) +* feat(eyeohdesigns/babyv): rgb matrix ([#22105](https://github.com/qmk/qmk_firmware/pull/22105)) +* input_club/infinity60: remove custom 3731 code, convert to LED Matrix ([#22117](https://github.com/qmk/qmk_firmware/pull/22117)) +* YMDK Melody96 Break-Up ([#22121](https://github.com/qmk/qmk_firmware/pull/22121)) +* Remove duplicated rgblight implementation from mxss ([#22122](https://github.com/qmk/qmk_firmware/pull/22122)) +* KC60 Layout Standardization and Cleanup ([#22125](https://github.com/qmk/qmk_firmware/pull/22125)) +* Convert adm42 to data driven ([#22144](https://github.com/qmk/qmk_firmware/pull/22144)) +* Update Drop keyboards for develop ([#22145](https://github.com/qmk/qmk_firmware/pull/22145)) +* move soda/mango and soda/pocket to magic_force/mf17 and magic_force/mf34 ([#22151](https://github.com/qmk/qmk_firmware/pull/22151)) +* GMMK2 65% ISO Community Layout Support ([#22152](https://github.com/qmk/qmk_firmware/pull/22152)) +* Leeloo v2.1 revision 3 updates. ([#22236](https://github.com/qmk/qmk_firmware/pull/22236)) +* jian/rev1: convert to DIP Switch ([#22248](https://github.com/qmk/qmk_firmware/pull/22248)) +* Enable linking of encoders to switch within layout macros ([#22264](https://github.com/qmk/qmk_firmware/pull/22264)) +* Migrate recently introduced sync items ([#22305](https://github.com/qmk/qmk_firmware/pull/22305)) +* Rename LINE FRIENDS TKL keyboard ([#22310](https://github.com/qmk/qmk_firmware/pull/22310)) +* feat(mechwild/clunker): new layouts ([#22342](https://github.com/qmk/qmk_firmware/pull/22342)) +* Remove use of broken split.main ([#22363](https://github.com/qmk/qmk_firmware/pull/22363)) +* whitefox: remove pointless file ([#22366](https://github.com/qmk/qmk_firmware/pull/22366)) +* Migrate some EEPROM config to info.json ([#22434](https://github.com/qmk/qmk_firmware/pull/22434)) +* Remove unnecessary driver counts ([#22435](https://github.com/qmk/qmk_firmware/pull/22435)) +* Migrate some dip switch config to info.json ([#22437](https://github.com/qmk/qmk_firmware/pull/22437)) +* Remove userspace keymaps ([#22544](https://github.com/qmk/qmk_firmware/pull/22544)) +* Stub out community layout directory structure ([#22545](https://github.com/qmk/qmk_firmware/pull/22545)) +* Remove symbolic linked userspace folder ([#22548](https://github.com/qmk/qmk_firmware/pull/22548)) + +Keyboard fixes: +* fix unxmaal for 60_iso ([#21975](https://github.com/qmk/qmk_firmware/pull/21975)) +* Fix input_club/k_type when RGB Matrix disabled ([#22021](https://github.com/qmk/qmk_firmware/pull/22021)) +* Fixup snes_macropad on develop ([#22444](https://github.com/qmk/qmk_firmware/pull/22444)) +* Fix missed shutdown callbacks ([#22549](https://github.com/qmk/qmk_firmware/pull/22549)) + +Others: +* Implement data driven wear leveling ([#21906](https://github.com/qmk/qmk_firmware/pull/21906)) +* More data driven RGB/LED Matrix config ([#21939](https://github.com/qmk/qmk_firmware/pull/21939)) +* Update WS2812 docs and add APA102 docs ([#22106](https://github.com/qmk/qmk_firmware/pull/22106)) +* Add DD mappings for locking switch ([#22242](https://github.com/qmk/qmk_firmware/pull/22242)) + +Bugs: +* Improve test invocation, fix Retro Shift bugs, and add Auto+Retro Shift test cases ([#15889](https://github.com/qmk/qmk_firmware/pull/15889)) +* [Bugfix] `qp_ellipse` overflow ([#19005](https://github.com/qmk/qmk_firmware/pull/19005)) +* Cater for ECC failures in EFL wear-leveling. ([#19749](https://github.com/qmk/qmk_firmware/pull/19749)) +* Fix OSM on a OSL activated layer ([#20410](https://github.com/qmk/qmk_firmware/pull/20410)) +* Fixed WB32 MCU remote wakeup issue ([#20863](https://github.com/qmk/qmk_firmware/pull/20863)) +* Optimize the additive DAC code, fixing performance-related hangs ([#21662](https://github.com/qmk/qmk_firmware/pull/21662)) +* [Enhancement] Improvements for debounce test coverage + bug fixes for sym_defer_g and sym_eager_pr ([#21667](https://github.com/qmk/qmk_firmware/pull/21667)) +* fix: make clicky delay silent ([#21866](https://github.com/qmk/qmk_firmware/pull/21866)) +* Add `mousekey.h` include to `quantum.h` ([#21897](https://github.com/qmk/qmk_firmware/pull/21897)) +* Fix default layer value in eeconfig_init ([#21909](https://github.com/qmk/qmk_firmware/pull/21909)) +* Add RTC IRQ Priority to RP2040 board files ([#21926](https://github.com/qmk/qmk_firmware/pull/21926)) +* Update AW20216S LED type ([#22072](https://github.com/qmk/qmk_firmware/pull/22072)) +* LED/RGB Matrix: prefix driver defines ([#22088](https://github.com/qmk/qmk_firmware/pull/22088)) +* RGBLight/Backlight: add prefixed driver defines ([#22089](https://github.com/qmk/qmk_firmware/pull/22089)) +* Fix lower cpi bound on PMW33XX ([#22108](https://github.com/qmk/qmk_firmware/pull/22108)) +* Fix parsing/validation for 21939 ([#22148](https://github.com/qmk/qmk_firmware/pull/22148)) +* is31fl3733: complete LED Matrix support ([#22149](https://github.com/qmk/qmk_firmware/pull/22149)) +* Fix memory leak in realloc failure handling ([#22188](https://github.com/qmk/qmk_firmware/pull/22188)) +* avrdude: Version 7.2 changes the text output ([#22235](https://github.com/qmk/qmk_firmware/pull/22235)) +* Resolve invalid keyboard alias targets ([#22239](https://github.com/qmk/qmk_firmware/pull/22239)) +* Prep work for NKRO report separation ([#22268](https://github.com/qmk/qmk_firmware/pull/22268)) +* ChibiOS pin defs: use only vendor if present ([#22297](https://github.com/qmk/qmk_firmware/pull/22297)) +* Fix invalid LED driver config ([#22312](https://github.com/qmk/qmk_firmware/pull/22312)) +* Fix compilation error when led/rgb process limit is zero. ([#22328](https://github.com/qmk/qmk_firmware/pull/22328)) +* V-USB: Fix `GET_IDLE/SET_IDLE` ([#22332](https://github.com/qmk/qmk_firmware/pull/22332)) +* QP getters correction ([#22357](https://github.com/qmk/qmk_firmware/pull/22357)) +* Fix 'to_c' for config.h mappings ([#22364](https://github.com/qmk/qmk_firmware/pull/22364)) +* snled27351: fix missing `i2c_init()` ([#22446](https://github.com/qmk/qmk_firmware/pull/22446)) +* Move BACKLIGHT_PWM_PERIOD to correct docs section ([#22480](https://github.com/qmk/qmk_firmware/pull/22480)) +* `qmk find`: Fix failure with multiple filters ([#22497](https://github.com/qmk/qmk_firmware/pull/22497)) +* Fix `qmk find` failure due to circular imports ([#22523](https://github.com/qmk/qmk_firmware/pull/22523)) diff --git a/_summary.md b/_summary.md index 26a543aee42..bae93da5b6c 100644 --- a/_summary.md +++ b/_summary.md @@ -4,7 +4,7 @@ * [Building Your First Firmware](newbs_building_firmware.md) * [Flashing Firmware](newbs_flashing.md) * [Getting Help/Support](support.md) - * [Building With GitHub Userspace](newbs_building_firmware_workflow.md) + * [External Userspace](newbs_external_userspace.md) * [Other Resources](newbs_learn_more_resources.md) * [Syllabus](syllabus.md) @@ -126,7 +126,6 @@ * [PS/2 Mouse](feature_ps2_mouse.md) * [Split Keyboard](feature_split_keyboard.md) * [Stenography](feature_stenography.md) - * [Velocikey](feature_velocikey.md) * Keyboard Building * [Easy Maker for One Offs](easy_maker.md) @@ -139,7 +138,7 @@ * Breaking Changes * [Overview](breaking_changes.md) * [My Pull Request Was Flagged](breaking_changes_instructions.md) - * [Most Recent ChangeLog](ChangeLog/20230827.md "QMK v0.22.0 - 2023 Aug 27") + * [Most Recent ChangeLog](ChangeLog/20231126.md "QMK v0.23.0 - 2023 Nov 26") * [Past Breaking Changes](breaking_changes_history.md) * C Development @@ -148,6 +147,7 @@ * [Compatible Microcontrollers](compatible_microcontrollers.md) * [Drivers](hardware_drivers.md) * [ADC Driver](adc_driver.md) + * [APA102 Driver](apa102_driver.md) * [Audio Driver](audio_driver.md) * [I2C Driver](i2c_driver.md) * [SPI Driver](spi_driver.md) diff --git a/adc_driver.md b/adc_driver.md index 494d90c94fa..dd928e1e7f0 100644 --- a/adc_driver.md +++ b/adc_driver.md @@ -9,7 +9,7 @@ This driver currently supports both AVR and a limited selection of ARM devices. To use this driver, add the following to your `rules.mk`: ```make -SRC += analog.c +ANALOG_DRIVER_REQUIRED = yes ``` Then place this include at the top of your code: diff --git a/apa102_driver.md b/apa102_driver.md new file mode 100644 index 00000000000..1da2de6ca35 --- /dev/null +++ b/apa102_driver.md @@ -0,0 +1,49 @@ +# APA102 Driver :id=apa102-driver + +This driver provides support for APA102 addressable RGB LEDs. They are similar to the [WS2812](ws2812_driver.md) LEDs, but have increased data and refresh rates. + +## Usage :id=usage + +In most cases, the APA102 driver code is automatically included if you are using either the [RGBLight](feature_rgblight.md) or [RGB Matrix](feature_rgb_matrix.md) feature with the `apa102` driver set, and you would use those APIs instead. + +However, if you need to use the driver standalone, add the following to your `rules.mk`: + +```make +APA102_DRIVER_REQUIRED = yes +``` + +You can then call the APA102 API by including `apa102.h` in your code. + +## Basic Configuration :id=basic-configuration + +Add the following to your `config.h`: + +|Define |Default |Description | +|---------------------------|-------------|------------------------------------------------------------------| +|`APA102_DI_PIN` |*Not defined*|The GPIO pin connected to the DI pin of the first LED in the chain| +|`APA102_CI_PIN` |*Not defined*|The GPIO pin connected to the CI pin of the first LED in the chain| +|`APA102_DEFAULT_BRIGHTNESS`|`31` |The default global brightness level of the LEDs, from 0 to 31 | + +## API :id=api + +### `void apa102_setleds(rgb_led_t *start_led, uint16_t num_leds)` + +Send RGB data to the APA102 LED chain. + +#### Arguments :id=api-apa102-setleds-arguments + + - `rgb_led_t *start_led` + A pointer to the LED array. + - `uint16_t num_leds` + The length of the LED array. + +--- + +### `void apa102_set_brightness(uint8_t brightness)` + +Set the global brightness. + +#### Arguments :id=api-apa102-set-brightness-arguments + + - `uint8_t brightness` + The brightness level to set, from 0 to 31. diff --git a/breaking_changes.md b/breaking_changes.md index fdf6ccef9c7..70a9044c8c0 100644 --- a/breaking_changes.md +++ b/breaking_changes.md @@ -10,9 +10,9 @@ Practically, this means QMK merges the `develop` branch into the `master` branch ## What has been included in past Breaking Changes? +* [2023 Nov 26](ChangeLog/20231126.md) * [2023 Aug 27](ChangeLog/20230827.md) * [2023 May 28](ChangeLog/20230528.md) -* [2023 Feb 26](ChangeLog/20230226.md) * [Older Breaking Changes](breaking_changes_history.md) ## When is the next Breaking Change? @@ -21,14 +21,14 @@ The next Breaking Change is scheduled for November 26, 2023. ### Important Dates -* 2023 Aug 27 - `develop` is tagged with a new release version. Each push to `master` is subsequently merged to `develop` by GitHub actions. -* 2023 Oct 29 - `develop` closed to new PRs. -* 2023 Oct 29 - Call for testers. -* 2023 Nov 5 - Last day for merges -- after this point `develop` is locked for testing and accepts only bugfixes -* 2023 Nov 19 - `develop` is locked, only critical bugfix PRs merged. -* 2023 Nov 23 - `master` is locked, no PRs merged. -* 2023 Nov 26 - Merge `develop` to `master`. -* 2023 Nov 26 - `master` is unlocked. PRs can be merged again. +* 2023 Nov 26 - `develop` is tagged with a new release version. Each push to `master` is subsequently merged to `develop` by GitHub actions. +* 2024 Jan 28 - `develop` closed to new PRs. +* 2024 Jan 28 - Call for testers. +* 2024 Feb 4 - Last day for merges -- after this point `develop` is locked for testing and accepts only bugfixes +* 2024 Feb 18 - `develop` is locked, only critical bugfix PRs merged. +* 2024 Feb 22 - `master` is locked, no PRs merged. +* 2024 Feb 25 - Merge `develop` to `master`. +* 2024 Feb 25 - `master` is unlocked. PRs can be merged again. ## What changes will be included? @@ -48,7 +48,7 @@ Criteria for acceptance: Strongly suggested: -* The PR has a ChangeLog file describing the changes under `/docs/Changelog/20231126`. +* The PR has a ChangeLog file describing the changes under `/docs/Changelog/20240225`. * This should be in Markdown format, with a name in the format `PR12345.md`, substituting the digits for your PRs ID. * One strong recommendation that the ChangeLog document matches the PR description on GitHub, so as to ensure traceability. diff --git a/breaking_changes_history.md b/breaking_changes_history.md index deb3dfb9900..4ab890294bb 100644 --- a/breaking_changes_history.md +++ b/breaking_changes_history.md @@ -2,6 +2,7 @@ This page links to all previous changelogs from the QMK Breaking Changes process. +* [2023 Nov 26](ChangeLog/20231126.md) - version 0.23.0 * [2023 Aug 27](ChangeLog/20230827.md) - version 0.22.0 * [2023 May 28](ChangeLog/20230528.md) - version 0.21.0 * [2023 Feb 26](ChangeLog/20230226.md) - version 0.20.0 diff --git a/cli_commands.md b/cli_commands.md index 79fd9de5757..7b5ad5b13ac 100644 --- a/cli_commands.md +++ b/cli_commands.md @@ -482,6 +482,131 @@ $ qmk import-kbfirmware ~/Downloads/gh62.json --- +# External Userspace Commands + +## `qmk userspace-add` + +This command adds a keyboard/keymap to the External Userspace build targets. + +**Usage**: + +``` +qmk userspace-add [-h] [-km KEYMAP] [-kb KEYBOARD] [builds ...] + +positional arguments: + builds List of builds in form :, or path to a keymap JSON file. + +options: + -h, --help show this help message and exit + -km KEYMAP, --keymap KEYMAP + The keymap to build a firmware for. Ignored when a configurator export is supplied. + -kb KEYBOARD, --keyboard KEYBOARD + The keyboard to build a firmware for. Ignored when a configurator export is supplied. +``` + +**Example**: + +``` +$ qmk userspace-add -kb planck/rev6 -km default +Ψ Added planck/rev6:default to userspace build targets +Ψ Saved userspace file to /home/you/qmk_userspace/qmk.json +``` + +## `qmk userspace-remove` + +This command removes a keyboard/keymap from the External Userspace build targets. + +**Usage**: + +``` +qmk userspace-remove [-h] [-km KEYMAP] [-kb KEYBOARD] [builds ...] + +positional arguments: + builds List of builds in form :, or path to a keymap JSON file. + +options: + -h, --help show this help message and exit + -km KEYMAP, --keymap KEYMAP + The keymap to build a firmware for. Ignored when a configurator export is supplied. + -kb KEYBOARD, --keyboard KEYBOARD + The keyboard to build a firmware for. Ignored when a configurator export is supplied. +``` + +**Example**: + +``` +$ qmk userspace-remove -kb planck/rev6 -km default +Ψ Removed planck/rev6:default from userspace build targets +Ψ Saved userspace file to /home/you/qmk_userspace/qmk.json +``` + +## `qmk userspace-list` + +This command lists the External Userspace build targets. + +**Usage**: + +``` +qmk userspace-list [-h] [-e] + +options: + -h, --help show this help message and exit + -e, --expand Expands any use of `all` for either keyboard or keymap. +``` + +**Example**: + +``` +$ qmk userspace-list +Ψ Current userspace build targets: +Ψ Keyboard: planck/rev6, keymap: you +Ψ Keyboard: clueboard/66/rev3, keymap: you +``` + +## `qmk userspace-compile` + +This command compiles all the External Userspace build targets. + +**Usage**: + +``` +qmk userspace-compile [-h] [-e ENV] [-n] [-c] [-j PARALLEL] [-t] + +options: + -h, --help show this help message and exit + -e ENV, --env ENV Set a variable to be passed to make. May be passed multiple times. + -n, --dry-run Don't actually build, just show the commands to be run. + -c, --clean Remove object files before compiling. + -j PARALLEL, --parallel PARALLEL + Set the number of parallel make jobs; 0 means unlimited. + -t, --no-temp Remove temporary files during build. +``` + +**Example**: + +``` +$ qmk userspace-compile +Ψ Preparing target list... +Build planck/rev6:you [OK] +Build clueboard/66/rev3:you [OK] +``` + +## `qmk userspace-doctor` + +This command examines your environment and alerts you to potential problems related to External Userspace. + +**Example**: + +``` +% qmk userspace-doctor +Ψ QMK home: /home/you/qmk_userspace/qmk_firmware +Ψ Testing userspace candidate: /home/you/qmk_userspace -- Valid `qmk.json` +Ψ QMK userspace: /home/you/qmk_userspace +Ψ Userspace enabled: True +``` + +--- + # Developer Commands ## `qmk format-text` diff --git a/custom_quantum_functions.md b/custom_quantum_functions.md index 5d63f3cfb7d..957633837c4 100644 --- a/custom_quantum_functions.md +++ b/custom_quantum_functions.md @@ -283,6 +283,65 @@ void suspend_wakeup_init_user(void) { * Keyboard/Revision: `void suspend_power_down_kb(void)` and `void suspend_wakeup_init_user(void)` * Keymap: `void suspend_power_down_kb(void)` and `void suspend_wakeup_init_user(void)` + +# Keyboard Shutdown/Reboot Code :id=keyboard-shutdown-reboot-code + +This function gets called whenever the firmware is reset, whether it's a soft reset or reset to the bootloader. This is the spot to use for any sort of cleanup, as this happens right before the actual reset. And it can be useful for turning off different systems (such as RGB, onboard screens, etc). + +Additionally, it differentiates between the soft reset (eg, rebooting back into the firmware) or jumping to the bootloader. + +Certain tasks are performed during shutdown too. The keyboard is cleared, music and midi is stopped (if enabled), the shutdown chime is triggered (if audio is enabled), and haptic is stopped. + +If `jump_to_bootloader` is set to `true`, this indicates that the board will be entering the bootloader for a new firmware flash, whereas `false` indicates that this is happening for a soft reset and will load the firmware agaim immediately (such as when using `QK_REBOOT` or `QK_CLEAR_EEPROM`). + +As there is a keyboard and user level function, returning `false` for the user function will disable the keyboard level function, allowing for customization. + +?> Bootmagic does not trigger `shutdown_*()` as it happens before most of the initialization process. + +### Example `shutdown_kb()` Implementation + +```c +bool shutdown_kb(bool jump_to_bootloader) { + if (!shutdown_user(jump_to_bootloader)) { + return false; + } + + if (jump_to_bootloader) { + // red for bootloader + rgb_matrix_set_color_all(RGB_OFF); + } else { + // off for soft reset + rgb_matrix_set_color_all(RGB_GREEN); + } + // force flushing -- otherwise will never happen + rgb_matrix_update_pwm_buffers(); + return true; +} +``` + +### Example `shutdown_user()` Implementation + +```c +bool shutdown_user(bool jump_to_bootloader) { + if (jump_to_bootloader) { + // red for bootloader + rgb_matrix_set_color_all(RGB_RED); + } else { + // off for soft reset + rgb_matrix_set_color_all(RGB_OFF); + } + // force flushing -- otherwise will never happen + rgb_matrix_update_pwm_buffers(); + // false to not process kb level + return false; +} +``` + +### Keyboard shutdown/reboot Function Documentation + +* Keyboard/Revision: `bool shutdown_kb(bool jump_to_bootloader)` +* Keymap: `bool shutdown_user(bool jump_to_bootloader)` + # Deferred Execution :id=deferred-execution QMK has the ability to execute a callback after a specified period of time, rather than having to manually manage timers. To enable this functionality, set `DEFERRED_EXEC_ENABLE = yes` in rules.mk. diff --git a/eeprom_driver.md b/eeprom_driver.md index 50d8bcb7b32..c77d18c68df 100644 --- a/eeprom_driver.md +++ b/eeprom_driver.md @@ -66,6 +66,14 @@ Currently QMK supports 25xx-series chips over SPI. As such, requires a working s `#define EXTERNAL_EEPROM_PAGE_SIZE` | `32` | Page size of the EEPROM in bytes, as specified in the datasheet `#define EXTERNAL_EEPROM_ADDRESS_SIZE` | `2` | The number of bytes to transmit for the memory location within the EEPROM +Default values and extended descriptions can be found in `drivers/eeprom/eeprom_spi.h`. + +Alternatively, there are pre-defined hardware configurations for available chips/modules: + +Module | Equivalent `#define` | Source +-----------------|---------------------------------|------------------------------------------ +MB85RS64V FRAM | `define EEPROM_SPI_MB85RS64V` | + !> There's no way to determine if there is an SPI EEPROM actually responding. Generally, this will result in reads of nothing but zero. ## Transient Driver configuration :id=transient-eeprom-driver-configuration @@ -105,11 +113,11 @@ Configurable options in your keyboard's `config.h`: `config.h` override | Default | Description -----------------------------------------|-------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -`#define WEAR_LEVELING_EFL_FIRST_SECTOR` | _unset_ | The first sector on the MCU to use. By default this is not defined and calculated at runtime based on the MCU. However, different flash sizes on MCUs may require custom configuration. -`#define WEAR_LEVELING_EFL_FLASH_SIZE` | _unset_ | Allows overriding the flash size available for use for wear-leveling. Under normal circumstances this is automatically calculated and should not need to be overridden. Specifying a size larger than the amount actually available in flash will usually prevent the MCU from booting. -`#define WEAR_LEVELING_LOGICAL_SIZE` | `1024` | Number of bytes "exposed" to the rest of QMK and denotes the size of the usable EEPROM. -`#define WEAR_LEVELING_BACKING_SIZE` | `2048` | Number of bytes used by the wear-leveling algorithm for its underlying storage, and needs to be a multiple of the logical size. -`#define BACKING_STORE_WRITE_SIZE` | _automatic_ | The byte width of the underlying write used on the MCU, and is usually automatically determined from the selected MCU family. If an error occurs in the auto-detection, you'll need to consult the MCU's datasheet and determine this value, specifying it directly. +`#define WEAR_LEVELING_EFL_FIRST_SECTOR` | _unset_ | The first sector on the MCU to use. By default this is not defined and calculated at runtime based on the MCU. However, different flash sizes on MCUs may require custom configuration. +`#define WEAR_LEVELING_EFL_FLASH_SIZE` | _unset_ | Allows overriding the flash size available for use for wear-leveling. Under normal circumstances this is automatically calculated and should not need to be overridden. Specifying a size larger than the amount actually available in flash will usually prevent the MCU from booting. +`#define WEAR_LEVELING_LOGICAL_SIZE` | `(backing_size/2)` | Number of bytes "exposed" to the rest of QMK and denotes the size of the usable EEPROM. +`#define WEAR_LEVELING_BACKING_SIZE` | `2048` | Number of bytes used by the wear-leveling algorithm for its underlying storage, and needs to be a multiple of the logical size. +`#define BACKING_STORE_WRITE_SIZE` | _automatic_ | The byte width of the underlying write used on the MCU, and is usually automatically determined from the selected MCU family. If an error occurs in the auto-detection, you'll need to consult the MCU's datasheet and determine this value, specifying it directly. !> If your MCU does not boot after swapping to the EFL wear-leveling driver, it's likely that the flash size is incorrectly detected, usually as an MCU with larger flash and may require overriding. @@ -139,7 +147,7 @@ Configurable options in your keyboard's `config.h`: ------------------------------------------|----------------------------|-------------------------------------------------------------------------------------------------------------------------------- `#define WEAR_LEVELING_RP2040_FLASH_SIZE` | `PICO_FLASH_SIZE_BYTES` | Number of bytes of flash on the board. `#define WEAR_LEVELING_RP2040_FLASH_BASE` | `(flash_size-sector_size)` | The byte-wise location that the backing storage should be located. -`#define WEAR_LEVELING_LOGICAL_SIZE` | `4096` | Number of bytes "exposed" to the rest of QMK and denotes the size of the usable EEPROM. +`#define WEAR_LEVELING_LOGICAL_SIZE` | `(backing_size/2)` | Number of bytes "exposed" to the rest of QMK and denotes the size of the usable EEPROM. `#define WEAR_LEVELING_BACKING_SIZE` | `8192` | Number of bytes used by the wear-leveling algorithm for its underlying storage, and needs to be a multiple of the logical size as well as the sector size. `#define BACKING_STORE_WRITE_SIZE` | `2` | The write width used whenever a write is performed on the external flash peripheral. diff --git a/feature_auto_shift.md b/feature_auto_shift.md index 6241cbaeb15..74be33cdd47 100644 --- a/feature_auto_shift.md +++ b/feature_auto_shift.md @@ -180,18 +180,18 @@ For more granular control, there is `get_auto_shifted_key`. The default function bool get_auto_shifted_key(uint16_t keycode, keyrecord_t *record) { switch (keycode) { # ifndef NO_AUTO_SHIFT_ALPHA - case KC_A ... KC_Z: + case AUTO_SHIFT_ALPHA: # endif # ifndef NO_AUTO_SHIFT_NUMERIC - case KC_1 ... KC_0: + case AUTO_SHIFT_NUMERIC: # endif # ifndef NO_AUTO_SHIFT_SPECIAL -# ifndef NO_AUTO_SHIFT_TAB +# ifndef NO_AUTO_SHIFT_TAB case KC_TAB: -# endif -# ifndef NO_AUTO_SHIFT_SYMBOLS +# endif +# ifndef NO_AUTO_SHIFT_SYMBOLS case AUTO_SHIFT_SYMBOLS: -# endif +# endif # endif # ifdef AUTO_SHIFT_ENTER case KC_ENT: @@ -310,10 +310,16 @@ generating taps on release. For example: #define RETRO_SHIFT 500 ``` +Without a value set, holds of any length without an interrupting key will produce the shifted value. + This value (if set) must be greater than one's `TAPPING_TERM`, as the key press must be designated as a 'hold' by `process_tapping` before we send the modifier. +[Per-key tapping terms](tap_hold.md#tapping-term) can be used as a workaround. There is no such limitation in regards to `AUTO_SHIFT_TIMEOUT` for normal keys. +**Note:** Tap Holds must be added to Auto Shift, see [here.](feature_auto_shift.md#auto-shift-per-key) +`IS_RETRO` may be helpful if one wants all Tap Holds retro shifted. + ### Retro Shift and Tap Hold Configurations Tap Hold Configurations work a little differently when using Retro Shift. diff --git a/feature_backlight.md b/feature_backlight.md index d032c33f18a..69391fcefe9 100644 --- a/feature_backlight.md +++ b/feature_backlight.md @@ -37,8 +37,9 @@ Add the following to your `config.h`: |`BREATHING_PERIOD` |`6` |The length of one backlight "breath" in seconds | |`BACKLIGHT_ON_STATE` |`1` |The state of the backlight pin when the backlight is "on" - `1` for high, `0` for low | |`BACKLIGHT_LIMIT_VAL` |`255` |The maximum duty cycle of the backlight -- `255` allows for full brightness, any lower will decrease the maximum.| +|`BACKLIGHT_DEFAULT_ON` |`true` |Enable backlight upon clearing the EEPROM | +|`BACKLIGHT_DEFAULT_BREATHING`|`false` |Whether to enable backlight breathing upon clearing the EEPROM | |`BACKLIGHT_DEFAULT_LEVEL` |`BACKLIGHT_LEVELS`|The default backlight level to use upon clearing the EEPROM | -|`BACKLIGHT_DEFAULT_BREATHING`|*Not defined* |Whether to enable backlight breathing upon clearing the EEPROM | Unless you are designing your own keyboard, you generally should not need to change the `BACKLIGHT_PIN` or `BACKLIGHT_ON_STATE`. @@ -172,11 +173,13 @@ Depending on the ChibiOS board configuration, you may need to enable PWM at the The following `#define`s apply only to the `pwm` driver: -|Define |Default |Description | -|-----------------------|--------|-----------------------------------| -|`BACKLIGHT_PWM_DRIVER` |`PWMD4` |The PWM driver to use | -|`BACKLIGHT_PWM_CHANNEL`|`3` |The PWM channel to use | -|`BACKLIGHT_PAL_MODE` |`2` |The pin alternative function to use| +|Define |Default |Description | +|-----------------------|-------------|---------------------------------------------------------------| +|`BACKLIGHT_PWM_DRIVER` |`PWMD4` |The PWM driver to use | +|`BACKLIGHT_PWM_CHANNEL`|`3` |The PWM channel to use | +|`BACKLIGHT_PAL_MODE` |`2` |The pin alternative function to use | +|`BACKLIGHT_PWM_PERIOD` |*Not defined*|The PWM period in counter ticks - Default is platform dependent| + Refer to the ST datasheet for your particular MCU to determine these values. For example, these defaults are set up for pin `B8` on a Proton-C (STM32F303) using `TIM4_CH3` on AF2. Unless you are designing your own keyboard, you generally should not need to change them. diff --git a/feature_led_matrix.md b/feature_led_matrix.md index fd56a457258..b1ce09d3494 100644 --- a/feature_led_matrix.md +++ b/feature_led_matrix.md @@ -19,14 +19,13 @@ You can use between 1 and 4 IS31FL3731 IC's. Do not specify `LED_DRIVER_ADDR_ | Variable | Description | Default | |----------|-------------|---------| -| `ISSI_TIMEOUT` | (Optional) How long to wait for i2c messages, in milliseconds | 100 | -| `ISSI_PERSISTENCE` | (Optional) Retry failed messages this many times | 0 | -| `LED_DRIVER_COUNT` | (Required) How many LED driver IC's are present | | +| `IS31FL3731_I2C_TIMEOUT` | (Optional) How long to wait for i2c messages, in milliseconds | 100 | +| `IS31FL3731_I2C_PERSISTENCE` | (Optional) Retry failed messages this many times | 0 | | `LED_MATRIX_LED_COUNT` | (Required) How many LED lights are present across all drivers | | -| `LED_DRIVER_ADDR_1` | (Required) Address for the first LED driver | | -| `LED_DRIVER_ADDR_2` | (Optional) Address for the second LED driver | | -| `LED_DRIVER_ADDR_3` | (Optional) Address for the third LED driver | | -| `LED_DRIVER_ADDR_4` | (Optional) Address for the fourth LED driver | | +| `IS31FL3731_I2C_ADDRESS_1` | (Required) Address for the first LED driver | | +| `IS31FL3731_I2C_ADDRESS_2` | (Optional) Address for the second LED driver | | +| `IS31FL3731_I2C_ADDRESS_3` | (Optional) Address for the third LED driver | | +| `IS31FL3731_I2C_ADDRESS_4` | (Optional) Address for the fourth LED driver | | Here is an example using 2 drivers. @@ -34,14 +33,15 @@ Here is an example using 2 drivers. // This is a 7-bit address, that gets left-shifted and bit 0 // set to 0 for write, 1 for read (as per I2C protocol) // The address will vary depending on your wiring: -// 0b1110100 AD <-> GND -// 0b1110111 AD <-> VCC -// 0b1110101 AD <-> SCL -// 0b1110110 AD <-> SDA -#define LED_DRIVER_ADDR_1 0b1110100 -#define LED_DRIVER_ADDR_2 0b1110110 - -#define LED_DRIVER_COUNT 2 +// 00 AD <-> GND +// 01 AD <-> SCL +// 10 AD <-> SDA +// 11 AD <-> VCC +// ADDR represents A1:A0 of the 7-bit address. +// The result is: 0b11101(ADDR) +#define IS31FL3731_I2C_ADDRESS_1 IS31FL3731_I2C_ADDRESS_GND +#define IS31FL3731_I2C_ADDRESS_2 IS31FL3731_I2C_ADDRESS_SDA + #define LED_DRIVER_1_LED_TOTAL 25 #define LED_DRIVER_2_LED_TOTAL 24 #define LED_MATRIX_LED_COUNT (LED_DRIVER_1_LED_TOTAL + LED_DRIVER_2_LED_TOTAL) @@ -49,12 +49,12 @@ Here is an example using 2 drivers. !> Note the parentheses, this is so when `LED_MATRIX_LED_COUNT` is used in code and expanded, the values are added together before any additional math is applied to them. As an example, `rand() % (LED_DRIVER_1_LED_TOTAL + LED_DRIVER_2_LED_TOTAL)` will give very different results than `rand() % LED_DRIVER_1_LED_TOTAL + LED_DRIVER_2_LED_TOTAL`. -For split keyboards using `LED_MATRIX_SPLIT` with an LED driver, you can either have the same driver address or different driver addresses. If using different addresses, use `DRIVER_ADDR_1` for one and `DRIVER_ADDR_2` for the other one. Then, in `g_is31_leds`, fill out the correct driver index (0 or 1). If using one address, use `DRIVER_ADDR_1` for both, and use index 0 for `g_is31_leds`. +For split keyboards using `LED_MATRIX_SPLIT` with an LED driver, you can either have the same driver address or different driver addresses. If using different addresses, use `IS31FL3731_I2C_ADDRESS_1` for one and `IS31FL3731_I2C_ADDRESS_2` for the other one. Then, in `g_is31fl3731_leds`, fill out the correct driver index (0 or 1). If using one address, use `IS31FL3731_I2C_ADDRESS_1` for both, and use index 0 for `g_is31fl3731_leds`. Define these arrays listing all the LEDs in your `.c`: ```c -const is31_led PROGMEM g_is31_leds[LED_MATRIX_LED_COUNT] = { +const is31fl3731_led_t PROGMEM g_is31fl3731_leds[LED_MATRIX_LED_COUNT] = { /* Refer to IS31 manual for these locations * driver * | LED address @@ -94,7 +94,6 @@ Configure the hardware via your `config.h`: |----------|-------------|---------| | `ISSI_TIMEOUT` | (Optional) How long to wait for i2c messages, in milliseconds | 100 | | `ISSI_PERSISTENCE` | (Optional) Retry failed messages this many times | 0 | -| `DRIVER_COUNT` | (Required) How many LED driver IC's are present | | | `LED_MATRIX_LED_COUNT` | (Required) How many LED lights are present across all drivers | | | `DRIVER_ADDR_1` | (Optional) Address for the first LED driver | | | `DRIVER_ADDR_` | (Required) Address for the additional LED drivers | | @@ -127,7 +126,6 @@ Here is an example using 2 drivers. ```c #define DRIVER_ADDR_2 0b0100001 -#define DRIVER_COUNT 2 #define DRIVER_1_LED_TOTAL 66 #define DRIVER_2_LED_TOTAL 42 #define LED_MATRIX_LED_COUNT (DRIVER_1_LED_TOTAL + DRIVER_2_LED_TOTAL) @@ -159,7 +157,7 @@ Then Define the array listing all the LEDs you want to override in your ` If using one of the above defines you can skip to gesture settings. + +| Setting | Description | Default | +| -------------------------------- | ---------------------------------------------------------- | ------------- | +| `AZOTEQ_IQS5XX_WIDTH_MM` | (Required) Width of the trackpad sensor in millimeters. | _not defined_ | +| `AZOTEQ_IQS5XX_HEIGHT_MM` | (Required) Height of the trackpad sensor in millimeters. | _not defined_ | +| `AZOTEQ_IQS5XX_RESOLUTION_X` | (Optional) Specify X resolution for CPI calculation. | _not defined_ | +| `AZOTEQ_IQS5XX_RESOLUTION_Y` | (Optional) Specify Y resolution for CPI calculation. | _not defined_ | + +**`AZOTEQ_IQS5XX_RESOLUTION_X/Y`** fall back resolutions are provided within the driver based on controller model. + +| I2C Setting | Description | Default | +| ------------------------- | ------------------------------------------------------------------------------- | ------- | +| `AZOTEQ_IQS5XX_ADDRESS` | (Optional) Sets the I2C Address for the Azoteq trackpad | `0xE8` | +| `AZOTEQ_IQS5XX_TIMEOUT_MS`| (Optional) The timeout for i2c communication with in milliseconds. | `10` | + +#### Gesture settings + +| Setting | Description | Default | +| ----------------------------------------- | ------------------------------------------------------------------------------------ | ----------- | +| `AZOTEQ_IQS5XX_TAP_ENABLE` | (Optional) Enable single finger tap. (Left click) | `true` | +| `AZOTEQ_IQS5XX_TWO_FINGER_TAP_ENABLE` | (Optional) Enable two finger tap. (Right click) | `true` | +| `AZOTEQ_IQS5XX_PRESS_AND_HOLD_ENABLE` | (Optional) Emulates holding left click to select text. | `false` | +| `AZOTEQ_IQS5XX_SWIPE_X_ENABLE` | (Optional) Enable swipe gestures X+ (Mouse Button 5) / X- (Mouse Button 4) | `false` | +| `AZOTEQ_IQS5XX_SWIPE_Y_ENABLE` | (Optional) Enable swipe gestures Y+ (Mouse Button 3) / Y- (Mouse Button 6) | `false` | +| `AZOTEQ_IQS5XX_ZOOM_ENABLE` | (Optional) Enable zoom gestures Zoom Out (Mouse Button 7) / Zoom In (Mouse Button 8) | `false` | +| `AZOTEQ_IQS5XX_SCROLL_ENABLE` | (Optional) Enable scrolling using two fingers. | `true` | +| `AZOTEQ_IQS5XX_TAP_TIME` | (Optional) Maximum time in ms for tap to be registered. | `150` | +| `AZOTEQ_IQS5XX_TAP_DISTANCE` | (Optional) Maximum deviation in pixels before single tap is no longer valid. | `25` | +| `AZOTEQ_IQS5XX_HOLD_TIME` | (Optional) Minimum time in ms for press and hold. | `300` | +| `AZOTEQ_IQS5XX_SWIPE_INITIAL_TIME` | (Optional) Maximum time to travel initial distance before swipe is registered. | `150` | +| `AZOTEQ_IQS5XX_SWIPE_INITIAL_DISTANCE` | (Optional) Minimum travel in pixels before swipe is registered. | `300` | +| `AZOTEQ_IQS5XX_SWIPE_CONSECUTIVE_TIME` | (Optional) Maximum time to travel consecutive distance before swipe is registered. | `0` | +| `AZOTEQ_IQS5XX_SWIPE_CONSECUTIVE_DISTANCE`| (Optional) Minimum travel in pixels before a consecutive swipe is registered. | `2000` | +| `AZOTEQ_IQS5XX_SCROLL_INITIAL_DISTANCE` | (Optional) Minimum travel in pixels before scroll is registered. | `50` | +| `AZOTEQ_IQS5XX_ZOOM_INITIAL_DISTANCE` | (Optional) Minimum travel in pixels before zoom is registered. | `50` | +| `AZOTEQ_IQS5XX_ZOOM_CONSECUTIVE_DISTANCE` | (Optional) Maximum time to travel zoom distance before zoom is registered. | `25` | + +#### Rotation settings + +| Setting | Description | Default | +| ---------------------------- | ---------------------------------------------------------- | ------------- | +| `AZOTEQ_IQS5XX_ROTATION_90` | (Optional) Configures hardware for 90 degree rotation. | _not defined_ | +| `AZOTEQ_IQS5XX_ROTATION_180` | (Optional) Configures hardware for 180 degree rotation. | _not defined_ | +| `AZOTEQ_IQS5XX_ROTATION_270` | (Optional) Configures hardware for 270 degree rotation. | _not defined_ | + ### Cirque Trackpad To use the Cirque Trackpad sensor, add this to your `rules.mk`: diff --git a/feature_rgb_matrix.md b/feature_rgb_matrix.md index 44899d70d9d..824ff50648a 100644 --- a/feature_rgb_matrix.md +++ b/feature_rgb_matrix.md @@ -19,15 +19,14 @@ You can use between 1 and 4 IS31FL3731 IC's. Do not specify `DRIVER_ADDR_` de | Variable | Description | Default | |----------|-------------|---------| -| `ISSI_TIMEOUT` | (Optional) How long to wait for i2c messages, in milliseconds | 100 | -| `ISSI_PERSISTENCE` | (Optional) Retry failed messages this many times | 0 | -| `ISSI_3731_DEGHOST` | (Optional) Set this define to enable de-ghosting by halving Vcc during blanking time | | -| `DRIVER_COUNT` | (Required) How many RGB driver IC's are present | | +| `IS31FL3731_I2C_TIMEOUT` | (Optional) How long to wait for i2c messages, in milliseconds | 100 | +| `IS31FL3731_I2C_PERSISTENCE` | (Optional) Retry failed messages this many times | 0 | +| `IS31FL3731_DEGHOST` | (Optional) Set this define to enable de-ghosting by halving Vcc during blanking time | | | `RGB_MATRIX_LED_COUNT` | (Required) How many RGB lights are present across all drivers | | -| `DRIVER_ADDR_1` | (Required) Address for the first RGB driver | | -| `DRIVER_ADDR_2` | (Optional) Address for the second RGB driver | | -| `DRIVER_ADDR_3` | (Optional) Address for the third RGB driver | | -| `DRIVER_ADDR_4` | (Optional) Address for the fourth RGB driver | | +| `IS31FL3731_I2C_ADDRESS_1` | (Required) Address for the first RGB driver | | +| `IS31FL3731_I2C_ADDRESS_2` | (Optional) Address for the second RGB driver | | +| `IS31FL3731_I2C_ADDRESS_3` | (Optional) Address for the third RGB driver | | +| `IS31FL3731_I2C_ADDRESS_4` | (Optional) Address for the fourth RGB driver | | Here is an example using 2 drivers. @@ -35,14 +34,15 @@ Here is an example using 2 drivers. // This is a 7-bit address, that gets left-shifted and bit 0 // set to 0 for write, 1 for read (as per I2C protocol) // The address will vary depending on your wiring: -// 0b1110100 AD <-> GND -// 0b1110111 AD <-> VCC -// 0b1110101 AD <-> SCL -// 0b1110110 AD <-> SDA -#define DRIVER_ADDR_1 0b1110100 -#define DRIVER_ADDR_2 0b1110110 - -#define DRIVER_COUNT 2 +// 00 AD <-> GND +// 01 AD <-> SCL +// 10 AD <-> SDA +// 11 AD <-> VCC +// ADDR represents A1:A0 of the 7-bit address. +// The result is: 0b11101(ADDR) +#define IS31FL3731_I2C_ADDRESS_1 IS31FL3731_I2C_ADDRESS_GND +#define IS31FL3731_I2C_ADDRESS_2 IS31FL3731_I2C_ADDRESS_SDA + #define DRIVER_1_LED_TOTAL 25 #define DRIVER_2_LED_TOTAL 24 #define RGB_MATRIX_LED_COUNT (DRIVER_1_LED_TOTAL + DRIVER_2_LED_TOTAL) @@ -50,12 +50,12 @@ Here is an example using 2 drivers. !> Note the parentheses, this is so when `RGB_MATRIX_LED_COUNT` is used in code and expanded, the values are added together before any additional math is applied to them. As an example, `rand() % (DRIVER_1_LED_TOTAL + DRIVER_2_LED_TOTAL)` will give very different results than `rand() % DRIVER_1_LED_TOTAL + DRIVER_2_LED_TOTAL`. -For split keyboards using `RGB_MATRIX_SPLIT` with an LED driver, you can either have the same driver address or different driver addresses. If using different addresses, use `DRIVER_ADDR_1` for one and `DRIVER_ADDR_2` for the other one. Then, in `g_is31_leds`, fill out the correct driver index (0 or 1). If using one address, use `DRIVER_ADDR_1` for both, and use index 0 for `g_is31_leds`. +For split keyboards using `RGB_MATRIX_SPLIT` with an LED driver, you can either have the same driver address or different driver addresses. If using different addresses, use `IS31FL3731_I2C_ADDRESS_1` for one and `IS31FL3731_I2C_ADDRESS_2` for the other one. Then, in `g_is31fl3731_leds`, fill out the correct driver index (0 or 1). If using one address, use `IS31FL3731_I2C_ADDRESS_1` for both, and use index 0 for `g_is31fl3731_leds`. Define these arrays listing all the LEDs in your `.c`: ```c -const is31_led PROGMEM g_is31_leds[RGB_MATRIX_LED_COUNT] = { +const is31fl3731_led_t PROGMEM g_is31fl3731_leds[RGB_MATRIX_LED_COUNT] = { /* Refer to IS31 manual for these locations * driver * | R location @@ -83,34 +83,33 @@ You can use between 1 and 4 IS31FL3733 IC's. Do not specify `DRIVER_ADDR_` de | Variable | Description | Default | |----------|-------------|---------| -| `ISSI_TIMEOUT` | (Optional) How long to wait for i2c messages, in milliseconds | 100 | -| `ISSI_PERSISTENCE` | (Optional) Retry failed messages this many times | 0 | -| `ISSI_PWM_FREQUENCY` | (Optional) PWM Frequency Setting - IS31FL3733B only | 0 | -| `ISSI_GLOBALCURRENT` | (Optional) Configuration for the Global Current Register | 0xFF | -| `ISSI_SWPULLUP` | (Optional) Set the value of the SWx lines on-chip de-ghosting resistors | PUR_0R (Disabled) | -| `ISSI_CSPULLUP` | (Optional) Set the value of the CSx lines on-chip de-ghosting resistors | PUR_0R (Disabled) | -| `DRIVER_COUNT` | (Required) How many RGB driver IC's are present | | +| `IS31FL3733_I2C_TIMEOUT` | (Optional) How long to wait for i2c messages, in milliseconds | 100 | +| `IS31FL3733_I2C_PERSISTENCE` | (Optional) Retry failed messages this many times | 0 | +| `IS31FL3733_PWM_FREQUENCY` | (Optional) PWM Frequency Setting - IS31FL3733B only | 0 | +| `IS31FL3733_GLOBALCURRENT` | (Optional) Configuration for the Global Current Register | 0xFF | +| `IS31FL3733_SWPULLUP` | (Optional) Set the value of the SWx lines on-chip de-ghosting resistors | PUR_0R (Disabled) | +| `IS31FL3733_CSPULLUP` | (Optional) Set the value of the CSx lines on-chip de-ghosting resistors | PUR_0R (Disabled) | | `RGB_MATRIX_LED_COUNT` | (Required) How many RGB lights are present across all drivers | | -| `DRIVER_ADDR_1` | (Required) Address for the first RGB driver | | -| `DRIVER_ADDR_2` | (Optional) Address for the second RGB driver | | -| `DRIVER_ADDR_3` | (Optional) Address for the third RGB driver | | -| `DRIVER_ADDR_4` | (Optional) Address for the fourth RGB driver | | -| `DRIVER_SYNC_1` | (Optional) Sync configuration for the first RGB driver | 0 | -| `DRIVER_SYNC_2` | (Optional) Sync configuration for the second RGB driver | 0 | -| `DRIVER_SYNC_3` | (Optional) Sync configuration for the third RGB driver | 0 | -| `DRIVER_SYNC_4` | (Optional) Sync configuration for the fourth RGB driver | 0 | - -The IS31FL3733 IC's have on-chip resistors that can be enabled to allow for de-ghosting of the RGB matrix. By default these resistors are not enabled (`ISSI_SWPULLUP`/`ISSI_CSPULLUP` are given the value of`PUR_0R`), the values that can be set to enable de-ghosting are as follows: - -| `ISSI_SWPULLUP/ISSI_CSPULLUP` | Description | +| `IS31FL3733_I2C_ADDRESS_1` | (Required) Address for the first RGB driver | | +| `IS31FL3733_I2C_ADDRESS_2` | (Optional) Address for the second RGB driver | | +| `IS31FL3733_I2C_ADDRESS_3` | (Optional) Address for the third RGB driver | | +| `IS31FL3733_I2C_ADDRESS_4` | (Optional) Address for the fourth RGB driver | | +| `IS31FL3733_SYNC_1` | (Optional) Sync configuration for the first RGB driver | 0 | +| `IS31FL3733_SYNC_2` | (Optional) Sync configuration for the second RGB driver | 0 | +| `IS31FL3733_SYNC_3` | (Optional) Sync configuration for the third RGB driver | 0 | +| `IS31FL3733_SYNC_4` | (Optional) Sync configuration for the fourth RGB driver | 0 | + +The IS31FL3733 IC's have on-chip resistors that can be enabled to allow for de-ghosting of the RGB matrix. By default these resistors are not enabled (`IS31FL3733_SWPULLUP`/`IS31FL3733_CSPULLUP` are given the value of `IS31FL3733_PUR_0R`), the values that can be set to enable de-ghosting are as follows: + +| `IS31FL3733_SWPULLUP/IS31FL3733_CSPULLUP` | Description | |----------------------|-------------| -| `PUR_0R` | (default) Do not use the on-chip resistors/enable de-ghosting | -| `PUR_05KR` | The 0.5k Ohm resistor used during blanking period (t_NOL) | -| `PUR_3KR` | The 3k Ohm resistor used at all times | -| `PUR_4KR` | The 4k Ohm resistor used at all times | -| `PUR_8KR` | The 8k Ohm resistor used at all times | -| `PUR_16KR` | The 16k Ohm resistor used at all times | -| `PUR_32KR` | The 32k Ohm resistor used during blanking period (t_NOL) | +| `IS31FL3733_PUR_0R` | (default) Do not use the on-chip resistors/enable de-ghosting | +| `IS31FL3733_PUR_05KR` | The 0.5k Ohm resistor used during blanking period (t_NOL) | +| `IS31FL3733_PUR_3KR` | The 3k Ohm resistor used at all times | +| `IS31FL3733_PUR_4KR` | The 4k Ohm resistor used at all times | +| `IS31FL3733_PUR_8KR` | The 8k Ohm resistor used at all times | +| `IS31FL3733_PUR_16KR` | The 16k Ohm resistor used at all times | +| `IS31FL3733_PUR_32KR` | The 32k Ohm resistor used during blanking period (t_NOL) | Here is an example using 2 drivers. @@ -118,17 +117,16 @@ Here is an example using 2 drivers. // This is a 7-bit address, that gets left-shifted and bit 0 // set to 0 for write, 1 for read (as per I2C protocol) // The address will vary depending on your wiring: -// 00 <-> GND -// 01 <-> SCL -// 10 <-> SDA -// 11 <-> VCC +// 00 ADDRn <-> GND +// 01 ADDRn <-> SCL +// 10 ADDRn <-> SDA +// 11 ADDRn <-> VCC // ADDR1 represents A1:A0 of the 7-bit address. // ADDR2 represents A3:A2 of the 7-bit address. // The result is: 0b101(ADDR2)(ADDR1) -#define DRIVER_ADDR_1 0b1010000 -#define DRIVER_ADDR_2 0b1010011 +#define IS31FL3733_I2C_ADDRESS_1 IS31FL3733_I2C_ADDRESS_GND_GND +#define IS31FL3733_I2C_ADDRESS_2 IS31FL3733_I2C_ADDRESS_GND_VCC -#define DRIVER_COUNT 2 #define DRIVER_1_LED_TOTAL 58 #define DRIVER_2_LED_TOTAL 10 #define RGB_MATRIX_LED_COUNT (DRIVER_1_LED_TOTAL + DRIVER_2_LED_TOTAL) @@ -141,7 +139,7 @@ Currently only 4 drivers are supported, but it would be trivial to support all 8 Define these arrays listing all the LEDs in your `.c`: ```c -const is31_led PROGMEM g_is31_leds[RGB_MATRIX_LED_COUNT] = { +const is31fl3733_led_t PROGMEM g_is31fl3733_leds[RGB_MATRIX_LED_COUNT] = { /* Refer to IS31 manual for these locations * driver * | R location @@ -170,31 +168,30 @@ Configure the hardware via your `config.h`: | Variable | Description | Default | |----------|-------------|---------| -| `ISSI_TIMEOUT` | (Optional) How long to wait for i2c messages, in milliseconds | 100 | -| `ISSI_PERSISTENCE` | (Optional) Retry failed messages this many times | 0 | -| `ISSI_PWM_FREQUENCY` | (Optional) PWM Frequency Setting - IS31FL3736B only | 0 | -| `ISSI_GLOBALCURRENT` | (Optional) Configuration for the Global Current Register | 0xFF | -| `ISSI_SWPULLUP` | (Optional) Set the value of the SWx lines on-chip de-ghosting resistors | PUR_0R (Disabled) | -| `ISSI_CSPULLUP` | (Optional) Set the value of the CSx lines on-chip de-ghosting resistors | PUR_0R (Disabled) | -| `DRIVER_COUNT` | (Required) How many RGB driver IC's are present | | +| `IS31FL3736_I2C_TIMEOUT` | (Optional) How long to wait for i2c messages, in milliseconds | 100 | +| `IS31FL3736_PERSISTENCE` | (Optional) Retry failed messages this many times | 0 | +| `IS31FL3736_PWM_FREQUENCY` | (Optional) PWM Frequency Setting - IS31FL3736B only | 0 | +| `IS31FL3736_GLOBALCURRENT` | (Optional) Configuration for the Global Current Register | 0xFF | +| `IS31FL3736_SWPULLUP` | (Optional) Set the value of the SWx lines on-chip de-ghosting resistors | PUR_0R (Disabled) | +| `IS31FL3736_CSPULLUP` | (Optional) Set the value of the CSx lines on-chip de-ghosting resistors | PUR_0R (Disabled) | | `RGB_MATRIX_LED_COUNT` | (Required) How many RGB lights are present across all drivers | | -| `DRIVER_ADDR_1` | (Required) Address for the first RGB driver | | -| `DRIVER_ADDR_2` | (Optional) Address for the second RGB driver | | -| `DRIVER_ADDR_3` | (Optional) Address for the third RGB driver | | -| `DRIVER_ADDR_4` | (Optional) Address for the fourth RGB driver | | +| `IS31FL3736_I2C_ADDRESS_1` | (Required) Address for the first RGB driver | | +| `IS31FL3736_I2C_ADDRESS_2` | (Optional) Address for the second RGB driver | | +| `IS31FL3736_I2C_ADDRESS_3` | (Optional) Address for the third RGB driver | | +| `IS31FL3736_I2C_ADDRESS_4` | (Optional) Address for the fourth RGB driver | | -The IS31FL3736 IC's have on-chip resistors that can be enabled to allow for de-ghosting of the RGB matrix. By default these resistors are not enabled (`ISSI_SWPULLUP`/`ISSI_CSPULLUP` are given the value of`PUR_0R`), the values that can be set to enable de-ghosting are as follows: +The IS31FL3736 IC's have on-chip resistors that can be enabled to allow for de-ghosting of the RGB matrix. By default these resistors are not enabled (`IS31FL3736_SWPULLUP`/`IS31FL3736_CSPULLUP` are given the value of `IS31FL3736_PUR_0R`), the values that can be set to enable de-ghosting are as follows: -| `ISSI_SWPULLUP/ISSI_CSPULLUP` | Description | +| `IS31FL3736_SWPULLUP/IS31FL3736_CSPULLUP` | Description | |----------------------|-------------| -| `PUR_0R` | (default) Do not use the on-chip resistors/enable de-ghosting | -| `PUR_05KR` | The 0.5k Ohm resistor used during blanking period (t_NOL) | -| `PUR_1KR` | The 1k Ohm resistor used during blanking period (t_NOL) | -| `PUR_2KR` | The 2k Ohm resistor used during blanking period (t_NOL) | -| `PUR_4KR` | The 4k Ohm resistor used during blanking period (t_NOL) | -| `PUR_8KR` | The 8k Ohm resistor during blanking period (t_NOL) | -| `PUR_16KR` | The 16k Ohm resistor during blanking period (t_NOL) | -| `PUR_32KR` | The 32k Ohm resistor used during blanking period (t_NOL) | +| `IS31FL3736_PUR_0R` | (default) Do not use the on-chip resistors/enable de-ghosting | +| `IS31FL3736_PUR_05KR` | The 0.5k Ohm resistor used during blanking period (t_NOL) | +| `IS31FL3736_PUR_1KR` | The 1k Ohm resistor used during blanking period (t_NOL) | +| `IS31FL3736_PUR_2KR` | The 2k Ohm resistor used during blanking period (t_NOL) | +| `IS31FL3736_PUR_4KR` | The 4k Ohm resistor used during blanking period (t_NOL) | +| `IS31FL3736_PUR_8KR` | The 8k Ohm resistor during blanking period (t_NOL) | +| `IS31FL3736_PUR_16KR` | The 16k Ohm resistor during blanking period (t_NOL) | +| `IS31FL3736_PUR_32KR` | The 32k Ohm resistor used during blanking period (t_NOL) | Here is an example using 2 drivers. @@ -202,16 +199,16 @@ Here is an example using 2 drivers. // This is a 7-bit address, that gets left-shifted and bit 0 // set to 0 for write, 1 for read (as per I2C protocol) // The address will vary depending on your wiring: -// 0000 <-> GND -// 0101 <-> SCL -// 1010 <-> SDA -// 1111 <-> VCC -// ADDR represents A3:A0 of the 7-bit address. -// The result is: 0b101(ADDR) -#define DRIVER_ADDR_1 0b1010000 -#define DRIVER_ADDR_2 0b1010001 +// 00 ADDRn <-> GND +// 01 ADDRn <-> SCL +// 10 ADDRn <-> SDA +// 11 ADDRn <-> VCC +// ADDR1 represents A1:A0 of the 7-bit address. +// ADDR2 represents A3:A2 of the 7-bit address. +// The result is: 0b101(ADDR2)(ADDR1) +#define IS31FL3736_I2C_ADDRESS_1 IS31FL3736_I2C_ADDRESS_GND_GND +#define IS31FL3736_I2C_ADDRESS_2 IS31FL3736_I2C_ADDRESS_GND_SCL -#define DRIVER_COUNT 2 #define DRIVER_1_LED_TOTAL 30 #define DRIVER_2_LED_TOTAL 32 #define RGB_MATRIX_LED_COUNT (DRIVER_1_LED_TOTAL + DRIVER_2_LED_TOTAL) @@ -221,7 +218,7 @@ Here is an example using 2 drivers. Define these arrays listing all the LEDs in your `.c`: ```c -const is31_led PROGMEM g_is31_leds[RGB_MATRIX_LED_COUNT] = { +const is31fl3736_led_t PROGMEM g_is31fl3736_leds[RGB_MATRIX_LED_COUNT] = { /* Refer to IS31 manual for these locations * driver * | R location @@ -246,31 +243,30 @@ Configure the hardware via your `config.h`: | Variable | Description | Default | |----------|-------------|---------| -| `ISSI_TIMEOUT` | (Optional) How long to wait for i2c messages, in milliseconds | 100 | -| `ISSI_PERSISTENCE` | (Optional) Retry failed messages this many times | 0 | -| `ISSI_PWM_FREQUENCY` | (Optional) PWM Frequency Setting - IS31FL3737B only | 0 | -| `ISSI_GLOBALCURRENT` | (Optional) Configuration for the Global Current Register | 0xFF | -| `ISSI_SWPULLUP` | (Optional) Set the value of the SWx lines on-chip de-ghosting resistors | PUR_0R (Disabled) | -| `ISSI_CSPULLUP` | (Optional) Set the value of the CSx lines on-chip de-ghosting resistors | PUR_0R (Disabled) | -| `DRIVER_COUNT` | (Required) How many RGB driver IC's are present | | +| `IS31FL3737_I2C_TIMEOUT` | (Optional) How long to wait for i2c messages, in milliseconds | 100 | +| `IS31FL3737_I2C_PERSISTENCE` | (Optional) Retry failed messages this many times | 0 | +| `IS31FL3737_PWM_FREQUENCY` | (Optional) PWM Frequency Setting - IS31FL3737B only | 0 | +| `IS31FL3737_GLOBALCURRENT` | (Optional) Configuration for the Global Current Register | 0xFF | +| `IS31FL3737_SWPULLUP` | (Optional) Set the value of the SWx lines on-chip de-ghosting resistors | PUR_0R (Disabled) | +| `IS31FL3737_CSPULLUP` | (Optional) Set the value of the CSx lines on-chip de-ghosting resistors | PUR_0R (Disabled) | | `RGB_MATRIX_LED_COUNT` | (Required) How many RGB lights are present across all drivers | | -| `DRIVER_ADDR_1` | (Required) Address for the first RGB driver | | -| `DRIVER_ADDR_2` | (Optional) Address for the second RGB driver | | -| `DRIVER_ADDR_3` | (Optional) Address for the third RGB driver | | -| `DRIVER_ADDR_4` | (Optional) Address for the fourth RGB driver | | +| `IS31FL3737_I2C_ADDRESS_1` | (Required) Address for the first RGB driver | | +| `IS31FL3737_I2C_ADDRESS_2` | (Optional) Address for the second RGB driver | | +| `IS31FL3737_I2C_ADDRESS_3` | (Optional) Address for the third RGB driver | | +| `IS31FL3737_I2C_ADDRESS_4` | (Optional) Address for the fourth RGB driver | | -The IS31FL3737 IC's have on-chip resistors that can be enabled to allow for de-ghosting of the RGB matrix. By default these resistors are not enabled (`ISSI_SWPULLUP`/`ISSI_CSPULLUP` are given the value of`PUR_0R`), the values that can be set to enable de-ghosting are as follows: +The IS31FL3737 IC's have on-chip resistors that can be enabled to allow for de-ghosting of the RGB matrix. By default these resistors are not enabled (`IS31FL3737_SWPULLUP`/`IS31FL3737_CSPULLUP` are given the value of `IS31FL3737_PUR_0R`), the values that can be set to enable de-ghosting are as follows: -| `ISSI_SWPULLUP/ISSI_CSPULLUP` | Description | +| `IS31FL3737_SWPULLUP/IS31FL3737_CSPULLUP` | Description | |----------------------|-------------| -| `PUR_0R` | (default) Do not use the on-chip resistors/enable de-ghosting | -| `PUR_05KR` | The 0.5k Ohm resistor used during blanking period (t_NOL) | -| `PUR_1KR` | The 1k Ohm resistor used during blanking period (t_NOL) | -| `PUR_2KR` | The 2k Ohm resistor used during blanking period (t_NOL) | -| `PUR_4KR` | The 4k Ohm resistor used during blanking period (t_NOL) | -| `PUR_8KR` | The 8k Ohm resistor during blanking period (t_NOL) | -| `PUR_16KR` | The 16k Ohm resistor during blanking period (t_NOL) | -| `PUR_32KR` | The 32k Ohm resistor used during blanking period (t_NOL) | +| `IS31FL3737_PUR_0R` | (default) Do not use the on-chip resistors/enable de-ghosting | +| `IS31FL3737_PUR_05KR` | The 0.5k Ohm resistor used during blanking period (t_NOL) | +| `IS31FL3737_PUR_1KR` | The 1k Ohm resistor used during blanking period (t_NOL) | +| `IS31FL3737_PUR_2KR` | The 2k Ohm resistor used during blanking period (t_NOL) | +| `IS31FL3737_PUR_4KR` | The 4k Ohm resistor used during blanking period (t_NOL) | +| `IS31FL3737_PUR_8KR` | The 8k Ohm resistor during blanking period (t_NOL) | +| `IS31FL3737_PUR_16KR` | The 16k Ohm resistor during blanking period (t_NOL) | +| `IS31FL3737_PUR_32KR` | The 32k Ohm resistor used during blanking period (t_NOL) | Here is an example using 2 drivers. @@ -278,16 +274,15 @@ Here is an example using 2 drivers. // This is a 7-bit address, that gets left-shifted and bit 0 // set to 0 for write, 1 for read (as per I2C protocol) // The address will vary depending on your wiring: -// 0000 <-> GND -// 0101 <-> SCL -// 1010 <-> SDA -// 1111 <-> VCC +// 0000 ADDR <-> GND +// 0101 ADDR <-> SCL +// 1010 ADDR <-> SDA +// 1111 ADDR <-> VCC // ADDR represents A3:A0 of the 7-bit address. // The result is: 0b101(ADDR) -#define DRIVER_ADDR_1 0b1010000 -#define DRIVER_ADDR_2 0b1010001 +#define IS31FL3737_I2C_ADDRESS_1 IS31FL3737_I2C_ADDRESS_GND +#define IS31FL3737_I2C_ADDRESS_2 IS31FL3737_I2C_ADDRESS_SCL -#define DRIVER_COUNT 2 #define DRIVER_1_LED_TOTAL 30 #define DRIVER_2_LED_TOTAL 36 #define RGB_MATRIX_LED_COUNT (DRIVER_1_LED_TOTAL + DRIVER_2_LED_TOTAL) @@ -297,7 +292,7 @@ Here is an example using 2 drivers. Define these arrays listing all the LEDs in your `.c`: ```c -const is31_led PROGMEM g_is31_leds[RGB_MATRIX_LED_COUNT] = { +const is31fl3737_led_t PROGMEM g_is31fl3737_leds[RGB_MATRIX_LED_COUNT] = { /* Refer to IS31 manual for these locations * driver * | R location @@ -338,7 +333,6 @@ Configure the hardware via your `config.h`: |----------|-------------|---------| | `ISSI_TIMEOUT` | (Optional) How long to wait for i2c messages, in milliseconds | 100 | | `ISSI_PERSISTENCE` | (Optional) Retry failed messages this many times | 0 | -| `DRIVER_COUNT` | (Required) How many RGB driver IC's are present | | | `RGB_MATRIX_LED_COUNT` | (Required) How many RGB lights are present across all drivers | | | `DRIVER_ADDR_1` | (Optional) Address for the first RGB driver | | | `DRIVER_ADDR_` | (Required) Address for the additional RGB drivers | | @@ -373,7 +367,6 @@ Here is an example using 2 drivers. ```c #define DRIVER_ADDR_2 0b0100001 -#define DRIVER_COUNT 2 #define DRIVER_1_LED_TOTAL 66 #define DRIVER_2_LED_TOTAL 42 #define RGB_MATRIX_LED_COUNT (DRIVER_1_LED_TOTAL + DRIVER_2_LED_TOTAL) @@ -407,7 +400,7 @@ Then Define the array listing all the LEDs you want to override in your `_xxx` defines for IC's that are not present on your keyboard. You can define the following items in `config.h`: +You can use up to 2 AW20216S IC's. Do not specify `DRIVER__xxx` defines for IC's that are not present on your keyboard. You can define the following items in `config.h`: | Variable | Description | Default | |----------|-------------|---------| -| `DRIVER_1_CS` | (Required) MCU pin connected to first RGB driver chip select line | B13 | -| `DRIVER_2_CS` | (Optional) MCU pin connected to second RGB driver chip select line | | -| `DRIVER_1_EN` | (Required) MCU pin connected to first RGB driver hardware enable line | C13 | -| `DRIVER_2_EN` | (Optional) MCU pin connected to second RGB driver hardware enable line | | +| `AW20216S_CS_PIN_1` | (Required) MCU pin connected to first RGB driver chip select line | B13 | +| `AW20216S_CS_PIN_2` | (Optional) MCU pin connected to second RGB driver chip select line | | +| `AW20216S_EN_PIN_1` | (Required) MCU pin connected to first RGB driver hardware enable line | C13 | +| `AW20216S_EN_PIN_2` | (Optional) MCU pin connected to second RGB driver hardware enable line | | | `DRIVER_1_LED_TOTAL` | (Required) How many RGB lights are connected to first RGB driver | | | `DRIVER_2_LED_TOTAL` | (Optional) How many RGB lights are connected to second RGB driver | | -| `DRIVER_COUNT` | (Required) How many RGB driver IC's are present | | | `RGB_MATRIX_LED_COUNT` | (Required) How many RGB lights are present across all drivers | | -| `AW_SCALING_MAX` | (Optional) LED current scaling value (0-255, higher values mean LED is brighter at full PWM) | 150 | -| `AW_GLOBAL_CURRENT_MAX` | (Optional) Driver global current limit (0-255, higher values means the driver may consume more power) | 150 | -| `AW_SPI_MODE` | (Optional) Mode for SPI communication (0-3, defines polarity and phase of the clock) | 3 | -| `AW_SPI_DIVISOR` | (Optional) Clock divisor for SPI communication (powers of 2, smaller numbers means faster communication, should not be less than 4) | 4 | +| `AW20216S_SCALING_MAX` | (Optional) LED current scaling value (0-255, higher values mean LED is brighter at full PWM) | 150 | +| `AW20216S_GLOBAL_CURRENT_MAX` | (Optional) Driver global current limit (0-255, higher values means the driver may consume more power) | 150 | +| `AW20216S_SPI_MODE` | (Optional) Mode for SPI communication (0-3, defines polarity and phase of the clock) | 3 | +| `AW20216S_SPI_DIVISOR` | (Optional) Clock divisor for SPI communication (powers of 2, smaller numbers means faster communication, should not be less than 4) | 4 | Here is an example using 2 drivers. ```c -#define DRIVER_1_CS B13 -#define DRIVER_2_CS B14 +#define AW20216S_CS_PIN_1 B13 +#define AW20216S_CS_PIN_2 B14 // Hardware enable lines may be connected to the same pin -#define DRIVER_1_EN C13 -#define DRIVER_2_EN C13 +#define AW20216S_EN_PIN_1 C13 +#define AW20216S_EN_PIN_2 C13 -#define DRIVER_COUNT 2 #define DRIVER_1_LED_TOTAL 66 #define DRIVER_2_LED_TOTAL 32 #define RGB_MATRIX_LED_COUNT (DRIVER_1_LED_TOTAL + DRIVER_2_LED_TOTAL) @@ -510,10 +501,10 @@ Here is an example using 2 drivers. Define these arrays listing all the LEDs in your `.c`: ```c -const aw_led PROGMEM g_aw_leds[RGB_MATRIX_LED_COUNT] = { -/* Each AW20216 channel is controlled by a register at some offset between 0x00 +const aw20216s_led_t PROGMEM g_aw20216s_leds[RGB_MATRIX_LED_COUNT] = { +/* Each AW20216S channel is controlled by a register at some offset between 0x00 * and 0xD7 inclusive. - * See drivers/awinic/aw20216.h for the mapping between register offsets and + * See drivers/led/aw20216s.h for the mapping between register offsets and * driver pin locations. * driver * | R location @@ -642,6 +633,7 @@ enum rgb_matrix_effects { RGB_MATRIX_DUAL_BEACON, // Full gradient spinning around center of keyboard RGB_MATRIX_RAINBOW_BEACON, // Full tighter gradient spinning around center of keyboard RGB_MATRIX_RAINBOW_PINWHEELS, // Full dual gradients spinning two halfs of keyboard + RGB_MATRIX_FLOWER_BLOOMING, // Full tighter gradient of first half scrolling left to right and second half scrolling right to left RGB_MATRIX_RAINDROPS, // Randomly changes a single key's hue RGB_MATRIX_JELLYBEAN_RAINDROPS, // Randomly changes a single key's hue and saturation RGB_MATRIX_HUE_BREATHING, // Hue shifts up a slight ammount at the same time, then shifts back @@ -654,16 +646,20 @@ enum rgb_matrix_effects { RGB_MATRIX_DIGITAL_RAIN, // That famous computer simulation RGB_MATRIX_SOLID_REACTIVE_SIMPLE, // Pulses keys hit to hue & value then fades value out RGB_MATRIX_SOLID_REACTIVE, // Static single hue, pulses keys hit to shifted hue then fades to current hue - RGB_MATRIX_SOLID_REACTIVE_WIDE // Hue & value pulse near a single key hit then fades value out - RGB_MATRIX_SOLID_REACTIVE_MULTIWIDE // Hue & value pulse near multiple key hits then fades value out - RGB_MATRIX_SOLID_REACTIVE_CROSS // Hue & value pulse the same column and row of a single key hit then fades value out - RGB_MATRIX_SOLID_REACTIVE_MULTICROSS // Hue & value pulse the same column and row of multiple key hits then fades value out - RGB_MATRIX_SOLID_REACTIVE_NEXUS // Hue & value pulse away on the same column and row of a single key hit then fades value out - RGB_MATRIX_SOLID_REACTIVE_MULTINEXUS // Hue & value pulse away on the same column and row of multiple key hits then fades value out + RGB_MATRIX_SOLID_REACTIVE_WIDE, // Hue & value pulse near a single key hit then fades value out + RGB_MATRIX_SOLID_REACTIVE_MULTIWIDE, // Hue & value pulse near multiple key hits then fades value out + RGB_MATRIX_SOLID_REACTIVE_CROSS, // Hue & value pulse the same column and row of a single key hit then fades value out + RGB_MATRIX_SOLID_REACTIVE_MULTICROSS, // Hue & value pulse the same column and row of multiple key hits then fades value out + RGB_MATRIX_SOLID_REACTIVE_NEXUS, // Hue & value pulse away on the same column and row of a single key hit then fades value out + RGB_MATRIX_SOLID_REACTIVE_MULTINEXUS, // Hue & value pulse away on the same column and row of multiple key hits then fades value out RGB_MATRIX_SPLASH, // Full gradient & value pulse away from a single key hit then fades value out RGB_MATRIX_MULTISPLASH, // Full gradient & value pulse away from multiple key hits then fades value out RGB_MATRIX_SOLID_SPLASH, // Hue & value pulse away from a single key hit then fades value out RGB_MATRIX_SOLID_MULTISPLASH, // Hue & value pulse away from multiple key hits then fades value out + RGB_MATRIX_STARLIGHT, // LEDs turn on and off at random at varying brightness, maintaining user set color + RGB_MATRIX_STARLIGHT_DUAL_HUE, // LEDs turn on and off at random at varying brightness, modifies user set hue by +- 30 + RGB_MATRIX_STARLIGHT_DUAL_SAT, // LEDs turn on and off at random at varying brightness, modifies user set saturation by +- 30 + RGB_MATRIX_RIVERFLOW, // Modification to breathing animation, offset's animation depending on key location to simulate a river flowing RGB_MATRIX_EFFECT_MAX }; ``` @@ -694,6 +690,7 @@ You can enable a single effect by defining `ENABLE_[EFFECT_NAME]` in your `confi |`#define ENABLE_RGB_MATRIX_DUAL_BEACON` |Enables `RGB_MATRIX_DUAL_BEACON` | |`#define ENABLE_RGB_MATRIX_RAINBOW_BEACON` |Enables `RGB_MATRIX_RAINBOW_BEACON` | |`#define ENABLE_RGB_MATRIX_RAINBOW_PINWHEELS` |Enables `RGB_MATRIX_RAINBOW_PINWHEELS` | +|`#define ENABLE_RGB_MATRIX_FLOWER_BLOOMING` |Enables `RGB_MATRIX_FLOWER_BLOOMING` | |`#define ENABLE_RGB_MATRIX_RAINDROPS` |Enables `RGB_MATRIX_RAINDROPS` | |`#define ENABLE_RGB_MATRIX_JELLYBEAN_RAINDROPS` |Enables `RGB_MATRIX_JELLYBEAN_RAINDROPS` | |`#define ENABLE_RGB_MATRIX_HUE_BREATHING` |Enables `RGB_MATRIX_HUE_BREATHING` | @@ -702,6 +699,10 @@ You can enable a single effect by defining `ENABLE_[EFFECT_NAME]` in your `confi |`#define ENABLE_RGB_MATRIX_PIXEL_FRACTAL` |Enables `RGB_MATRIX_PIXEL_FRACTAL` | |`#define ENABLE_RGB_MATRIX_PIXEL_FLOW` |Enables `RGB_MATRIX_PIXEL_FLOW` | |`#define ENABLE_RGB_MATRIX_PIXEL_RAIN` |Enables `RGB_MATRIX_PIXEL_RAIN` | +|`#define ENABLE_RGB_MATRIX_STARLIGHT` |Enables `RGB_MATRIX_STARLIGHT` | +|`#define ENABLE_RGB_MATRIX_STARLIGHT_DUAL_HUE` |Enables `RGB_MATRIX_STARLIGHT_DUAL_HUE` | +|`#define ENABLE_RGB_MATRIX_STARLIGHT_DUAL_SAT` |Enables `RGB_MATRIX_STARLIGHT_DUAL_SAT` | +|`#define ENABLE_RGB_MATRIX_RIVERFLOW` |Enables `RGB_MATRIX_RIVERFLOW` | |Framebuffer Defines |Description | |------------------------------------------------------|----------------------------------------------| @@ -875,6 +876,7 @@ These are defined in [`color.h`](https://github.com/qmk/qmk_firmware/blob/master #define RGB_MATRIX_DEFAULT_MODE RGB_MATRIX_CYCLE_LEFT_RIGHT // Sets the default mode, if none has been set #define RGB_MATRIX_DEFAULT_HUE 0 // Sets the default hue value, if none has been set #define RGB_MATRIX_DEFAULT_SAT 255 // Sets the default saturation value, if none has been set +#define RGB_MATRIX_DEFAULT_ON true // Sets the default enabled state, if none has been set #define RGB_MATRIX_DEFAULT_VAL RGB_MATRIX_MAXIMUM_BRIGHTNESS // Sets the default brightness value, if none has been set #define RGB_MATRIX_DEFAULT_SPD 127 // Sets the default animation speed, if none has been set #define RGB_MATRIX_DISABLE_KEYCODES // disables control of rgb matrix by keycodes (must use code functions to control the feature) diff --git a/feature_rgblight.md b/feature_rgblight.md index 0288fb04b2a..8a64454b0db 100644 --- a/feature_rgblight.md +++ b/feature_rgblight.md @@ -102,6 +102,7 @@ Your RGB lighting can be configured by placing these `#define`s in your `config. |`RGBLIGHT_DEFAULT_SAT` |`UINT8_MAX` (255) |The default saturation to use upon clearing the EEPROM | |`RGBLIGHT_DEFAULT_VAL` |`RGBLIGHT_LIMIT_VAL` |The default value (brightness) to use upon clearing the EEPROM | |`RGBLIGHT_DEFAULT_SPD` |`0` |The default speed to use upon clearing the EEPROM | +|`RGBLIGHT_DEFAULT_ON` |`true` |Enable RGB lighting upon clearing the EEPROM | ## Effects and Animations @@ -370,9 +371,9 @@ If you need to change your RGB lighting in code, for example in a macro to chang Example: ```c -sethsv(HSV_WHITE, (LED_TYPE *)&led[0]); // led 0 -sethsv(HSV_RED, (LED_TYPE *)&led[1]); // led 1 -sethsv(HSV_GREEN, (LED_TYPE *)&led[2]); // led 2 +sethsv(HSV_WHITE, (rgb_led_t *)&led[0]); // led 0 +sethsv(HSV_RED, (rgb_led_t *)&led[1]); // led 1 +sethsv(HSV_GREEN, (rgb_led_t *)&led[2]); // led 2 rgblight_set(); // Utility functions do not call rgblight_set() automatically, so they need to be called explicitly. ``` @@ -551,3 +552,33 @@ rgblight_set_clipping_range(3, 4); ## Hardware Modification If your keyboard lacks onboard underglow LEDs, you may often be able to solder on an RGB LED strip yourself. You will need to find an unused pin to wire to the data pin of your LED strip. Some keyboards may break out unused pins from the MCU to make soldering easier. The other two pins, VCC and GND, must also be connected to the appropriate power pins. + +## Velocikey + +Velocikey is a feature that lets you control the speed of lighting effects (like the Rainbow Swirl effect) with the speed of your typing. The faster you type, the faster the lights will go! + +### Usage +For Velocikey to take effect, there are two steps. First, when compiling your keyboard, you'll need to set `VELOCIKEY_ENABLE=yes` in `rules.mk`, e.g.: + +``` +MOUSEKEY_ENABLE = no +STENO_ENABLE = no +EXTRAKEY_ENABLE = yes +VELOCIKEY_ENABLE = yes +``` + +Then, while using your keyboard, you need to also turn it on with the `VK_TOGG` keycode, which toggles the feature on and off. + +The following light effects will all be controlled by Velocikey when it is enabled: + - RGB Breathing + - RGB Rainbow Mood + - RGB Rainbow Swirl + - RGB Snake + - RGB Knight + +Support for LED breathing effects is planned but not available yet. + + As long as Velocikey is enabled, it will control the speed regardless of any other speed setting that your RGB lights are currently on. + + ### Configuration + Velocikey doesn't currently support any configuration via keyboard settings. If you want to adjust something like the speed increase or decay rate, you would need to edit `velocikey.c` and adjust the values there to achieve the kinds of speeds that you like. diff --git a/feature_split_keyboard.md b/feature_split_keyboard.md index 1705ea92221..c67f04995b3 100644 --- a/feature_split_keyboard.md +++ b/feature_split_keyboard.md @@ -298,7 +298,7 @@ This enables transmitting the pointing device status to the master side of the s #define SPLIT_HAPTIC_ENABLE ``` -This enables triggering of haptic feedback on the slave side of the split keyboard. For DRV2605L this will send the mode, but for solenoids it is expected that the desired mode is already set up on the slave. +This enables the triggering of haptic feedback on the slave side of the split keyboard. This will send information to the slave side such as the mode, dwell, and whether buzz is enabled. ```c #define SPLIT_ACTIVITY_ENABLE diff --git a/feature_stenography.md b/feature_stenography.md index df4c9c6ad35..5ca3ea945fc 100644 --- a/feature_stenography.md +++ b/feature_stenography.md @@ -104,7 +104,7 @@ After enabling stenography and optionally selecting a protocol, you may also nee !> If you had *explicitly* set `VIRSTER_ENABLE = no`, none of the serial stenography protocols (GeminiPR, TX Bolt) will work properly. You are expected to either set it to `yes`, remove the line from your `rules.mk` or send the steno chords yourself in an alternative way using the [provided interceptable hooks](#interfacing-with-the-code). -In your keymap, create a new layer for Plover, that you can fill in with the [steno keycodes](#keycode-reference) (you will need to include `keymap_steno.h`, see `planck/keymaps/steno/keymap.c` for an example). Remember to create a key to switch to the layer as well as a key for exiting the layer. +In your keymap, create a new layer for Plover, that you can fill in with the [steno keycodes](#keycode-reference). Remember to create a key to switch to the layer as well as a key for exiting the layer. Once you have your keyboard flashed, launch Plover. Click the 'Configure...' button. In the 'Machine' tab, select the Stenotype Machine that corresponds to your desired protocol. Click the 'Configure...' button on this tab and enter the serial port or click 'Scan'. Baud rate is fine at 9600 (although you should be able to set as high as 115200 with no issues). Use the default settings for everything else (Data Bits: 8, Stop Bits: 1, Parity: N, no flow control). @@ -149,8 +149,6 @@ At the end of this scenario given as an example, `chord` would have five bits se ## Keycode Reference :id=keycode-reference -You must include `keymap_steno.h` to your `keymap.c` with `#include "keymap_steno.h"` before you can use these keycodes - > Note: TX Bolt does not support the full set of keys. The TX Bolt implementation in QMK will map the GeminiPR keys to the nearest TX Bolt key so that one key map will work for both. |GeminiPR|TX Bolt|Steno Key| @@ -198,7 +196,7 @@ You must include `keymap_steno.h` to your `keymap.c` with `#include "keymap_sten |`STN_RES2`||(Reset 2)| |`STN_PWR`||(Power)| -If you do not want to hit two keys with one finger combined keycodes can be used. These are also defined in `keymap_steno.h`, and causes both keys to be reported as pressed or released. To use these keycodes define `STENO_COMBINEDMAP` in your `config.h` file. +If you do not want to hit two keys with one finger combined keycodes can be used. These cause both keys to be reported as pressed or released. To use these keycodes define `STENO_COMBINEDMAP` in your `config.h` file. |Combined key | Key1 | Key 2 | |---------------|--------|----------| diff --git a/feature_velocikey.md b/feature_velocikey.md deleted file mode 100644 index aeb1865e8af..00000000000 --- a/feature_velocikey.md +++ /dev/null @@ -1,29 +0,0 @@ -# Velocikey - -Velocikey is a feature that lets you control the speed of lighting effects (like the Rainbow Swirl effect) with the speed of your typing. The faster you type, the faster the lights will go! - -## Usage -For Velocikey to take effect, there are two steps. First, when compiling your keyboard, you'll need to set `VELOCIKEY_ENABLE=yes` in `rules.mk`, e.g.: - -``` -MOUSEKEY_ENABLE = no -STENO_ENABLE = no -EXTRAKEY_ENABLE = yes -VELOCIKEY_ENABLE = yes -``` - -Then, while using your keyboard, you need to also turn it on with the `VK_TOGG` keycode, which toggles the feature on and off. - -The following light effects will all be controlled by Velocikey when it is enabled: - - RGB Breathing - - RGB Rainbow Mood - - RGB Rainbow Swirl - - RGB Snake - - RGB Knight - -Support for LED breathing effects is planned but not available yet. - - As long as Velocikey is enabled, it will control the speed regardless of any other speed setting that your RGB lights are currently on. - - ## Configuration - Velocikey doesn't currently support any configuration via keyboard settings. If you want to adjust something like the speed increase or decay rate, you would need to edit `velocikey.c` and adjust the values there to achieve the kinds of speeds that you like. diff --git a/i2c_driver.md b/i2c_driver.md index 92b666b5e34..faff0a1d7bf 100644 --- a/i2c_driver.md +++ b/i2c_driver.md @@ -2,6 +2,18 @@ The I2C Master drivers used in QMK have a set of common functions to allow portability between MCUs. +## Usage :id=usage + +In most cases, the I2C Master driver code is automatically included if you are using a feature or driver which requires it, such as [OLED](feature_oled_driver.md). + +However, if you need to use the driver standalone, add the following to your `rules.mk`: + +```make +I2C_DRIVER_REQUIRED = yes +``` + +You can then call the I2C API by including `i2c_master.h` in your code. + ## I2C Addressing :id=note-on-i2c-addresses All of the addresses expected by this driver should be pushed to the upper 7 bits of the address byte. Setting diff --git a/ja/_summary.md b/ja/_summary.md index 4d6f2348d5c..f26665e6143 100644 --- a/ja/_summary.md +++ b/ja/_summary.md @@ -112,7 +112,6 @@ * [分割キーボード](ja/feature_split_keyboard.md) * [速記](ja/feature_stenography.md) * [感熱式プリンタ](ja/feature_thermal_printer.md) - * [Velocikey](ja/feature_velocikey.md) * QMK の開発 * [PR チェックリスト](ja/pr_checklist.md) diff --git a/ja/feature_velocikey.md b/ja/feature_velocikey.md deleted file mode 100644 index b13969a195e..00000000000 --- a/ja/feature_velocikey.md +++ /dev/null @@ -1,34 +0,0 @@ -# Velocikey - - - -Velocikey は入力の速度を使って(レインボー渦巻効果のような)ライト効果の速度を制御できる機能です。速く入力すればするほどライトが速くなります！ - -## 使用法 -Velocikey を使うためには、2つのステップがあります。最初に、キーボードをコンパイルする時に、`rules.mk` に `VELOCIKEY_ENABLE=yes` を設定する必要があります。例えば: - -``` -MOUSEKEY_ENABLE = no -STENO_ENABLE = no -EXTRAKEY_ENABLE = yes -VELOCIKEY_ENABLE = yes -``` - -次に、キーボードの使用中に、VLK_TOG キーコードを使って Velocikey を有効にする必要もあります。これは機能をオンおよびオフにします。 - -以下の全てのライト効果が、Velocikey を有効にすることで制御されます: -- RGB 明滅動作 -- RGB レインボームード -- RGB レインボー渦巻 -- RGB スネーク -- RGB ナイト - -LED 明滅動作の効果のサポートは計画されていますがまだ利用できません。 - -Velocikey が有効になっている限り、現在オンになっている RGB ライトの他の全ての速度設定に関係なく、速度が制御されます。 - -## 設定 -Velocikey は現在のところキーボード設定を介したどのような設定もサポートしません。速度の増加あるいは減少率などを調整したい場合は、`velocikey.c` を編集し、そこで値を調整して、好みの速度を実現する必要があります。 diff --git a/newbs_external_userspace.md b/newbs_external_userspace.md new file mode 100644 index 00000000000..9bdf4b0b185 --- /dev/null +++ b/newbs_external_userspace.md @@ -0,0 +1,96 @@ +# External QMK Userspace + +QMK Firmware now officially supports storing user keymaps outside of the normal QMK Firmware repository, allowing users to maintain their own keymaps without having to fork, modify, and maintain a copy of QMK Firmware themselves. + +External Userspace mirrors the structure of the main QMK Firmware repository, but only contains the keymaps that you wish to build. You can still use `keyboards//keymaps/` to store your keymaps, or you can use the `layouts//` system as before -- they're just stored external to QMK Firmware. + +The build system will still honor the use of `users/` if you rely on the traditional QMK Firmware [userspace feature](feature_userspace.md) -- it's now supported externally too, using the same location inside the External Userspace directory. + +Additionally, there is first-class support for using GitHub Actions to build your keymaps, allowing you to automatically compile your keymaps whenever you push changes to your External Userspace repository. + +!> External Userspace is new functionality and may have issues. Tighter integration with the `qmk` command will occur over time. + +?> Historical keymap.json and GitHub-based firmware build instructions can be found [here](newbs_building_firmware_workflow.md). This document supersedes those instructions, but they should still function correctly. + +## Setting up QMK Locally + +If you wish to build on your local machine, you will need to set up QMK locally. This is a one-time process, and is documented in the [newbs setup guide](https://docs.qmk.fm/#/newbs). + +!> If you wish to use any QMK CLI commands related to manipulating External Userspace definitions, you will currently need a copy of QMK Firmware as well. + +!> Building locally has a much shorter turnaround time than waiting for GitHub Actions to complete. + +## External Userspace Repository Setup (forked on GitHub) + +A basic skeleton External Userspace repository can be found [here](https://github.com/qmk/qmk_userspace). If you wish to keep your keymaps on GitHub (strongly recommended!), you can fork the repository and use it as a base: + +![Userspace Fork](https://i.imgur.com/hcegguh.png) + +Going ahead with your fork will copy it to your account, at which point you can clone it to your local machine and begin adding your keymaps: + +![Userspace Clone](https://i.imgur.com/CWYmsk8.png) + +```sh +cd $HOME +git clone https://github.com/{myusername}/qmk_userspace.git +qmk config user.overlay_dir="$(realpath qmk_userspace)" +``` + +## External Userspace Setup (locally stored only) + +If you don't want to use GitHub and prefer to keep everything local, you can clone a copy of the default External Userspace locally instead: + +```sh +cd $HOME +git clone https://github.com/qmk/qmk_userspace.git +qmk config user.overlay_dir="$(realpath qmk_userspace)" +``` + +## Adding a Keymap + +_These instructions assume you have already set up QMK locally, and have a copy of the QMK Firmware repository on your machine._ + +Keymaps within External Userspace are defined in the same way as they are in the main QMK repository. You can either use the `qmk new-keymap` command to create a new keymap, or manually create a new directory in the `keyboards` directory. + +Alternatively, you can use the `layouts` directory to store your keymaps, using the same layout system as the main QMK repository -- if you choose to do so you'll want to use the path `layouts///keymap.*` to store your keymap files, where `layout name` matches an existing layout in QMK, such as `tkl_ansi`. + +After creating your new keymap, building the keymap matches normal QMK usage: + +```sh +qmk compile -kb -km +``` + +!> The `qmk config user.overlay_dir=...` command must have been run when cloning the External Userspace repository for this to work correctly. + +## Adding the keymap to External Userspace build targets + +Once you have created your keymap, if you want to use GitHub Actions to build your firmware, you will need to add it to the External Userspace build targets. This is done using the `qmk userspace-add` command: + +```sh +# for a keyboard/keymap combo: +qmk userspace-add -kb -km +# or, for a json-based keymap (if kept "loose"): +qmk userspace-add +``` + +This updates the `qmk.json` file in the root of your External Userspace directory. If you're using a git repository to store your keymaps, now is a great time to commit and push to your own fork. + +## Compiling External Userspace build targets + +Once you have added your keymaps to the External Userspace build targets, you can compile all of them at once using the `qmk userspace-compile` command: + +```sh +qmk userspace-compile +``` + +All firmware builds you've added to the External Userspace build targets will be built, and the resulting firmware files will be placed in the root of your External Userspace directory. + +## Using GitHub Actions + +GitHub Actions can be used to automatically build your keymaps whenever you push changes to your External Userspace repository. If you have set up your list of build targets, this is as simple as enabling workflows in the GitHub repository settings: + +![Repo Settings](https://i.imgur.com/EVkxOt1.png) + +Any push will result in compilation of all configured builds, and once completed a new release containing the newly-minted firmware files will be created on GitHub, which you can subsequently download and flash to your keyboard: + +![Releases](https://i.imgur.com/zmwOL5P.png) diff --git a/quantum_painter.md b/quantum_painter.md index 5e399183f8b..e8fa1bdeceb 100644 --- a/quantum_painter.md +++ b/quantum_painter.md @@ -13,22 +13,24 @@ QUANTUM_PAINTER_DRIVERS += ...... You will also likely need to select an appropriate driver in `rules.mk`, which is listed below. -!> Quantum Painter is not currently integrated with system-level operations such as disabling displays after a configurable timeout, or when the keyboard goes into suspend. Users will need to handle this manually at the current time. +!> Quantum Painter is not currently integrated with system-level operations such as when the keyboard goes into suspend. Users will need to handle this manually at the current time. The QMK CLI can be used to convert from normal images such as PNG files or animated GIFs, as well as fonts from TTF files. Supported devices: -| Display Panel | Panel Type | Size | Comms Transport | Driver | -|----------------|--------------------|------------------|-----------------|---------------------------------------------| -| GC9A01 | RGB LCD (circular) | 240x240 | SPI + D/C + RST | `QUANTUM_PAINTER_DRIVERS += gc9a01_spi` | -| ILI9163 | RGB LCD | 128x128 | SPI + D/C + RST | `QUANTUM_PAINTER_DRIVERS += ili9163_spi` | -| ILI9341 | RGB LCD | 240x320 | SPI + D/C + RST | `QUANTUM_PAINTER_DRIVERS += ili9341_spi` | -| ILI9488 | RGB LCD | 320x480 | SPI + D/C + RST | `QUANTUM_PAINTER_DRIVERS += ili9488_spi` | -| SSD1351 | RGB OLED | 128x128 | SPI + D/C + RST | `QUANTUM_PAINTER_DRIVERS += ssd1351_spi` | -| ST7735 | RGB LCD | 132x162, 80x160 | SPI + D/C + RST | `QUANTUM_PAINTER_DRIVERS += st7735_spi` | -| ST7789 | RGB LCD | 240x320, 240x240 | SPI + D/C + RST | `QUANTUM_PAINTER_DRIVERS += st7789_spi` | -| RGB565 Surface | Virtual | User-defined | None | `QUANTUM_PAINTER_DRIVERS += rgb565_surface` | +| Display Panel | Panel Type | Size | Comms Transport | Driver | +|---------------|--------------------|------------------|-----------------|------------------------------------------| +| GC9A01 | RGB LCD (circular) | 240x240 | SPI + D/C + RST | `QUANTUM_PAINTER_DRIVERS += gc9a01_spi` | +| ILI9163 | RGB LCD | 128x128 | SPI + D/C + RST | `QUANTUM_PAINTER_DRIVERS += ili9163_spi` | +| ILI9341 | RGB LCD | 240x320 | SPI + D/C + RST | `QUANTUM_PAINTER_DRIVERS += ili9341_spi` | +| ILI9488 | RGB LCD | 320x480 | SPI + D/C + RST | `QUANTUM_PAINTER_DRIVERS += ili9488_spi` | +| SSD1351 | RGB OLED | 128x128 | SPI + D/C + RST | `QUANTUM_PAINTER_DRIVERS += ssd1351_spi` | +| ST7735 | RGB LCD | 132x162, 80x160 | SPI + D/C + RST | `QUANTUM_PAINTER_DRIVERS += st7735_spi` | +| ST7789 | RGB LCD | 240x320, 240x240 | SPI + D/C + RST | `QUANTUM_PAINTER_DRIVERS += st7789_spi` | +| SH1106 (SPI) | Monochrome OLED | 128x64 | SPI + D/C + RST | `QUANTUM_PAINTER_DRIVERS += sh1106_spi` | +| SH1106 (I2C) | Monochrome OLED | 128x64 | I2C | `QUANTUM_PAINTER_DRIVERS += sh1106_i2c` | +| Surface | Virtual | User-defined | None | `QUANTUM_PAINTER_DRIVERS += surface` | ## Quantum Painter Configuration :id=quantum-painter-config @@ -188,7 +190,8 @@ Writing /home/qmk/qmk_firmware/keyboards/my_keeb/generated/noto11.qff.c... -### ** Common: Standard TFT (SPI + D/C + RST) ** + +### ** LCD ** Most TFT display panels use a 5-pin interface -- SPI SCK, SPI MOSI, SPI CS, D/C, and RST pins. @@ -302,32 +305,6 @@ The maximum number of displays can be configured by changing the following in yo Native color format rgb888 is compatible with ILI9488 -#### ** SSD1351 ** - -Enabling support for the SSD1351 in Quantum Painter is done by adding the following to `rules.mk`: - -```make -QUANTUM_PAINTER_ENABLE = yes -QUANTUM_PAINTER_DRIVERS += ssd1351_spi -``` - -Creating a SSD1351 device in firmware can then be done with the following API: - -```c -painter_device_t qp_ssd1351_make_spi_device(uint16_t panel_width, uint16_t panel_height, pin_t chip_select_pin, pin_t dc_pin, pin_t reset_pin, uint16_t spi_divisor, int spi_mode); -``` - -The device handle returned from the `qp_ssd1351_make_spi_device` function can be used to perform all other drawing operations. - -The maximum number of displays can be configured by changing the following in your `config.h` (default is 1): - -```c -// 3 displays: -#define SSD1351_NUM_DEVICES 3 -``` - -Native color format rgb565 is compatible with SSD1351 - #### ** ST7735 ** Enabling support for the ST7735 in Quantum Painter is done by adding the following to `rules.mk`: @@ -386,62 +363,139 @@ Native color format rgb565 is compatible with ST7789 -### ** Common: Surfaces ** +### ** OLED ** -Quantum Painter has surface drivers which are able to target a buffer in RAM. In general, surfaces keep track of the "dirty" region -- the area that has been drawn to since the last flush -- so that when transferring to the display they can transfer the minimal amount of data to achieve the end result. +OLED displays tend to use 5-pin SPI when at larger resolutions, or when using color -- SPI SCK, SPI MOSI, SPI CS, D/C, and RST pins. Smaller OLEDs may use I2C instead. -!> These generally require significant amounts of RAM, so at large sizes and/or higher bit depths, they may not be usable on all MCUs. +When using these displays, either `spi_master` or `i2c_master` must already be correctly configured for both the platform and panel you're building for. + +For SPI, the pin assignments for SPI CS, D/C, and RST are specified during device construction -- for I2C the panel's address is specified instead. -#### ** RGB565 Surface ** +#### ** SSD1351 ** + +Enabling support for the SSD1351 in Quantum Painter is done by adding the following to `rules.mk`: + +```make +QUANTUM_PAINTER_ENABLE = yes +QUANTUM_PAINTER_DRIVERS += ssd1351_spi +``` + +Creating a SSD1351 device in firmware can then be done with the following API: + +```c +painter_device_t qp_ssd1351_make_spi_device(uint16_t panel_width, uint16_t panel_height, pin_t chip_select_pin, pin_t dc_pin, pin_t reset_pin, uint16_t spi_divisor, int spi_mode); +``` + +The device handle returned from the `qp_ssd1351_make_spi_device` function can be used to perform all other drawing operations. + +The maximum number of displays can be configured by changing the following in your `config.h` (default is 1): + +```c +// 3 displays: +#define SSD1351_NUM_DEVICES 3 +``` + +Native color format rgb565 is compatible with SSD1351 + +#### ** SH1106 ** -Enabling support for RGB565 surfaces in Quantum Painter is done by adding the following to `rules.mk`: +Enabling support for the SH1106 in Quantum Painter is done by adding the following to `rules.mk`: ```make QUANTUM_PAINTER_ENABLE = yes -QUANTUM_PAINTER_DRIVERS += rgb565_surface +# For SPI: +QUANTUM_PAINTER_DRIVERS += sh1106_spi +# For I2C: +QUANTUM_PAINTER_DRIVERS += sh1106_i2c ``` -Creating a RGB565 surface in firmware can then be done with the following API: +Creating a SH1106 device in firmware can then be done with the following APIs: ```c -painter_device_t qp_rgb565_make_surface(uint16_t panel_width, uint16_t panel_height, void *buffer); +// SPI-based SH1106: +painter_device_t qp_sh1106_make_spi_device(uint16_t panel_width, uint16_t panel_height, pin_t chip_select_pin, pin_t dc_pin, pin_t reset_pin, uint16_t spi_divisor, int spi_mode); +// I2C-based SH1106: +painter_device_t qp_sh1106_make_i2c_device(uint16_t panel_width, uint16_t panel_height, uint8_t i2c_address); ``` -The `buffer` is a user-supplied area of memory, and is assumed to be of the size `sizeof(uint16_t) * panel_width * panel_height`. +The device handle returned from the `qp_sh1106_make_???_device` function can be used to perform all other drawing operations. + +The maximum number of displays of each type can be configured by changing the following in your `config.h` (default is 1): + +```c +// 3 SPI displays: +#define SH1106_NUM_SPI_DEVICES 3 +// 3 I2C displays: +#define SH1106_NUM_I2C_DEVICES 3 +``` + +Native color format mono2 is compatible with SH1106 + + + +### ** Surface ** -The device handle returned from the `qp_rgb565_make_surface` function can be used to perform all other drawing operations. +Quantum Painter has a surface driver which is able to target a buffer in RAM. In general, surfaces keep track of the "dirty" region -- the area that has been drawn to since the last flush -- so that when transferring to the display they can transfer the minimal amount of data to achieve the end result. + +!> These generally require significant amounts of RAM, so at large sizes and/or higher bit depths, they may not be usable on all MCUs. + +Enabling support for surfaces in Quantum Painter is done by adding the following to `rules.mk`: + +```make +QUANTUM_PAINTER_ENABLE = yes +QUANTUM_PAINTER_DRIVERS += surface +``` + +Creating a surface in firmware can then be done with the following APIs: + +```c +// 16bpp RGB565 surface: +painter_device_t qp_make_rgb565_surface(uint16_t panel_width, uint16_t panel_height, void *buffer); +// 1bpp monochrome surface: +painter_device_t qp_make_mono1bpp_surface(uint16_t panel_width, uint16_t panel_height, void *buffer); +``` + +The `buffer` is a user-supplied area of memory, which can be statically allocated using `SURFACE_REQUIRED_BUFFER_BYTE_SIZE`: + +```c +// Buffer required for a 240x80 16bpp surface: +uint8_t framebuffer[SURFACE_REQUIRED_BUFFER_BYTE_SIZE(240, 80, 16)]; +``` + +The device handle returned from the `qp_make_?????_surface` function can be used to perform all other drawing operations. Example: ```c static painter_device_t my_surface; -static uint16_t my_framebuffer[320 * 240]; // Allocate a buffer for a 320x240 RGB565 display +static uint8_t my_framebuffer[SURFACE_REQUIRED_BUFFER_BYTE_SIZE(240, 80, 16)]; // Allocate a buffer for a 16bpp 240x80 RGB565 display void keyboard_post_init_kb(void) { - my_surface = qp_rgb565_make_surface(320, 240, my_framebuffer); + my_surface = qp_rgb565_make_surface(240, 80, my_framebuffer); qp_init(my_surface, QP_ROTATION_0); + keyboard_post_init_user(); } ``` -The maximum number of RGB565 surfaces can be configured by changing the following in your `config.h` (default is 1): +The maximum number of surfaces can be configured by changing the following in your `config.h` (default is 1): ```c // 3 surfaces: -#define RGB565_SURFACE_NUM_DEVICES 3 +#define SURFACE_NUM_DEVICES 3 ``` -To transfer the contents of the RGB565 surface to another display, the following API can be invoked: +To transfer the contents of the surface to another display of the same pixel format, the following API can be invoked: ```c -bool qp_rgb565_surface_draw(painter_device_t surface, painter_device_t display, uint16_t x, uint16_t y); +bool qp_surface_draw(painter_device_t surface, painter_device_t display, uint16_t x, uint16_t y); ``` The `surface` is the surface to copy out from. The `display` is the target display to draw into. `x` and `y` are the target location to draw the surface pixel data. Under normal circumstances, the location should be consistent, as the dirty region is calculated with respect to the `x` and `y` coordinates -- changing those will result in partial, overlapping draws. -?> Calling `qp_flush()` on the surface resets its dirty region. Copying the surface contents to the display also automatically resets the dirty region. +!> The surface and display panel must have the same native pixel format. - +?> Calling `qp_flush()` on the surface resets its dirty region. Copying the surface contents to the display also automatically resets the dirty region. @@ -857,13 +911,52 @@ void keyboard_post_init_kb(void) { -#### ** Get Geometry ** +#### ** Gettters ** + +These functions allow external code to retrieve the current width, height, rotation, and drawing offsets. + + + +#### ** Width ** + +```c +uint16_t qp_get_width(painter_device_t device); +``` + +#### ** Height ** + +```c +uint16_t qp_get_height(painter_device_t device); +``` + +#### ** Rotation ** + +```c +painter_rotation_t qp_get_rotation(painter_device_t device); +``` + +#### ** Offset X ** + +```c +uint16_t qp_get_offset_x(painter_device_t device); +``` + +#### ** Offset Y ** + +```c +uint16_t qp_get_offset_y(painter_device_t device); +``` + +##### ** Everything ** + +Convenience function to call all the previous ones at once. +Note: You can pass `NULL` for the values you are not interested in. ```c void qp_get_geometry(painter_device_t device, uint16_t *width, uint16_t *height, painter_rotation_t *rotation, uint16_t *offset_x, uint16_t *offset_y); ``` -The `qp_get_geometry` function allows external code to retrieve the current width, height, rotation, and drawing offsets. + #### ** Set Viewport Offsets ** diff --git a/quantum_painter_lvgl.md b/quantum_painter_lvgl.md index 4d10160baf4..b4f31ad4af8 100644 --- a/quantum_painter_lvgl.md +++ b/quantum_painter_lvgl.md @@ -53,3 +53,11 @@ The `qp_lvgl_detach` function stops the internal LVGL ticks and releases resourc ## Enabling/Disabling LVGL features :id=lvgl-configuring You can overwrite LVGL specific features in your `lv_conf.h` file. + +## Changing the LVGL task frequency + +When LVGL is running, your keyboard's responsiveness may decrease, causing missing keystrokes or encoder rotations, especially during the animation of dynamically-generated content. This occurs because LVGL operates as a scheduled task with a default task rate of five milliseconds. While a fast task rate is advantageous when LVGL is responsible for detecting and processing inputs, it can lead to excessive recalculations of displayed content, which may slow down QMK's matrix scanning. If you rely on QMK instead of LVGL for processing inputs, it can be beneficial to increase the time between calls to the LVGL task handler to better match your preferred display update rate. To do this, add this to your `config.h`: + +```c +#define QP_LVGL_TASK_PERIOD 40 +``` diff --git a/reference_info_json.md b/reference_info_json.md index 91581afc73b..e102b9bfb94 100644 --- a/reference_info_json.md +++ b/reference_info_json.md @@ -60,6 +60,13 @@ You can create `info.json` files at every level under `qmk_firmware/keyboards/RST period between frames. -The default setting is 280 µs, which should work for most cases, but this can be overridden in your config.h. e.g.: +The WS2812 LED communication protocol works by encoding a "1" bit with a long high pulse (T1H), and a "0" bit with a shorter pulse (T0H). The total cycle length of a bit is the same. +The "reset" pulse (TRST) latches the sent RGB data to all of the LEDs and denotes a completed "frame". + +Some WS2812 variants have slightly different timing parameter requirements, which can be accounted for if necessary using the above `#define`s in your `config.h`. + +### Byte Order :id=byte-order + +Some WS2812 variants may have their color components in a different physical or logical order. For example, the WS2812B-2020 has physically swapped red and green LEDs, which causes the wrong color to be displayed, because the default order of the bytes sent over the wire is defined as GRB. +If you find your LED colors are consistently swapped, you may need to change the byte order by adding the following to your `config.h`: ```c -#define WS2812_TRST_US 80 +#define WS2812_BYTE_ORDER WS2812_BYTE_ORDER_GRB ``` -#### Byte Order +Where the byte order may be one of: + +|Byte Order|Known Devices | +|----------|----------------------------| +|`GRB` |Most WS2812s, SK6812, SK6805| +|`RGB` |WS2812B-2020 | +|`BGR` |TM1812 | -Some variants of the WS2812 may have their color components in a different physical or logical order. For example, the WS2812B-2020 has physically swapped red and green LEDs, which causes the wrong color to be displayed, because the default order of the bytes sent over the wire is defined as GRB. -In this case, you can change the byte order by defining `WS2812_BYTE_ORDER` as one of the following values: +## Driver Configuration :id=driver-configuration -| Byte order | Known devices | -| --------------------------------- | ----------------------------- | -| `WS2812_BYTE_ORDER_GRB` (default) | Most WS2812's, SK6812, SK6805 | -| `WS2812_BYTE_ORDER_RGB` | WS2812B-2020 | -| `WS2812_BYTE_ORDER_BGR` | TM1812 | +Driver selection can be configured in `rules.mk` as `WS2812_DRIVER`, or in `info.json` as `ws2812.driver`. Valid values are `bitbang` (default), `i2c`, `spi`, `pwm`, `vendor`, or `custom`. See below for information on individual drivers. +### Bitbang Driver :id=bitbang-driver -### Bitbang -Default driver, the absence of configuration assumes this driver. To configure it, add this to your rules.mk: +This is the default WS2812 driver. It operates by "bit-banging" ie. directly toggling the GPIO. + +Please note that on AVR devices, due to the tight timing requirements longer chains and/or heavy CPU loads may cause visible lag. Unfortunately this driver is usually the only option for AVR. ```make WS2812_DRIVER = bitbang ``` -!> This driver is not hardware accelerated and may not be performant on heavily loaded systems. +### I2C Driver :id=i2c-driver + +A specialized driver mainly used for PS2AVRGB (Bootmapper Client) boards, which possess an ATtiny85 that handles the WS2812 LEDs. + +```make +WS2812_DRIVER = i2c +``` + +The following `#define`s apply only to the `i2c` driver: -#### Adjusting bit timings +|Define |Default|Description | +|--------------------|-------|---------------------------------| +|`WS2812_I2C_ADDRESS`|`0xB0` |The I2C address of the ATtiny85. | +|`WS2812_I2C_TIMEOUT`|`100` |The I2C timeout, in milliseconds.| -The WS2812 LED communication topology depends on a serialized timed window. Different versions of the addressable LEDs have differing requirements for the timing parameters, for instance, of the SK6812. -You can tune these parameters through the definition of the following macros: +### PIO Driver :id=pio-driver -| Macro | Default | AVR | ARM | -| --------------- | ---------------------------- | ------------------ | ------------------ | -| `WS2812_TIMING` | `1250` | :heavy_check_mark: | :heavy_check_mark: | -| `WS2812_T0H` | `350` | :heavy_check_mark: | :heavy_check_mark: | -| `WS2812_T0L` | `WS2812_TIMING - WS2812_T0H` | | :heavy_check_mark: | -| `WS2812_T1H` | `900` | :heavy_check_mark: | :heavy_check_mark: | -| `WS2812_T1L` | `WS2812_TIMING - WS2812_T1H` | | :heavy_check_mark: | +This driver is RP2040-only, and leverages the onboard PIO (programmable I/O) system and DMA to offload processing from the CPU. -### I2C -Targeting boards where WS2812 support is offloaded to a 2nd MCU. Currently the driver is limited to AVR given the known consumers are ps2avrGB/BMC. To configure it, add this to your rules.mk: +The WS2812 PIO program uses one state machine, six instructions and one DMA interrupt handler callback. Due to the implementation the time resolution for this driver is 50 ns - any value not specified in this interval will be rounded to the next matching interval. ```make -WS2812_DRIVER = i2c +WS2812_DRIVER = vendor ``` -Configure the hardware via your config.h: -```c -#define WS2812_I2C_ADDRESS 0xB0 // default: 0xB0 -#define WS2812_I2C_TIMEOUT 100 // default: 100 +### PWM Driver :id=pwm-driver + +This driver is ARM-only, and leverages the onboard PWM peripheral and DMA to offload processing from the CPU. + +```make +WS2812_DRIVER = pwm ``` -### SPI -Targeting STM32 boards where WS2812 support is offloaded to an SPI hardware device. The advantage is that the use of DMA offloads processing of the WS2812 protocol from the MCU. `WS2812_DI_PIN` for this driver is the configured SPI MOSI pin. Due to the nature of repurposing SPI to drive the LEDs, the other SPI pins, MISO and SCK, **must** remain unused. To configure it, add this to your rules.mk: +### SPI Driver :id=spi-driver + +This driver is ARM-only, and leverages the onboard SPI peripheral and DMA to offload processing from the CPU. The DI pin **must** be connected to the MOSI pin on the MCU, and all other SPI pins **must** be left unused. This is also very dependent on your MCU's SPI peripheral clock speed, and may or may not be possible depending on the MCU selected. ```make WS2812_DRIVER = spi ``` -Configure the hardware via your config.h: -```c -#define WS2812_SPI SPID1 // default: SPID1 -#define WS2812_SPI_MOSI_PAL_MODE 5 // MOSI pin "alternate function", see the respective datasheet for the appropriate values for your MCU. default: 5 -#define WS2812_SPI_SCK_PIN B3 // Required for F072, may be for others -- SCK pin, see the respective datasheet for the appropriate values for your MCU. default: unspecified -#define WS2812_SPI_SCK_PAL_MODE 5 // SCK pin "alternate function", see the respective datasheet for the appropriate values for your MCU. default: 5 -``` +## ChibiOS/ARM Configuration :id=arm-configuration -You must also turn on the SPI feature in your halconf.h and mcuconf.h +The following defines apply only to ARM devices: -#### Circular Buffer Mode -Some boards may flicker while in the normal buffer mode. To fix this issue, circular buffer mode may be used to rectify the issue. +|Define |Default |Description | +|------------|------------------------------|---------------------------------------------------------------------------------| +|`WS2812_T1L`|`(WS2812_TIMING - WS2812_T1H)`|The length of a "1" bit's low phase in nanoseconds (bitbang and PIO drivers only)| +|`WS2812_T0L`|`(WS2812_TIMING - WS2812_T0H)`|The length of a "0" bit's low phase in nanoseconds (bitbang and PIO drivers only)| -By default, the circular buffer mode is disabled. +### Push-Pull and Open Drain :id=push-pull-open-drain -To enable this alternative buffer mode, place this into your `config.h` file: -```c -#define WS2812_SPI_USE_CIRCULAR_BUFFER -``` +By default, the GPIO used for data transmission is configured as a *push-pull* output, meaning the pin is effectively always driven either to VCC or to ground. -#### Setting baudrate with divisor -To adjust the baudrate at which the SPI peripheral is configured, users will need to derive the target baudrate from the clock tree provided by STM32CubeMX. +For situations where the logic level voltage is lower than the power supply voltage, however, this can pose an issue. The solution is to configure the pin for *open drain* mode instead, and use a pullup resistor between the DI pin and VCC. In this mode, the MCU can only pull the GPIO *low*, or leave it floating. The pullup resistor is then responsible for pulling the line high, when the MCU is not driving the GPIO. -Only divisors of 2, 4, 8, 16, 32, 64, 128 and 256 are supported by hardware. +To configure the DI pin for open drain configuration, add the following to your `config.h`: -| Define | Default | Description | -| -------------------- | ------- | ----------------------------------- | -| `WS2812_SPI_DIVISOR` | `16` | SPI source clock peripheral divisor | +```c +#define WS2812_EXTERNAL_PULLUP +``` -#### Testing Notes +### SPI Driver :id=arm-spi-driver -While not an exhaustive list, the following table provides the scenarios that have been partially validated: +Depending on the ChibiOS board configuration, you may need to enable SPI at the keyboard level. For STM32, this would look like: -| | SPI1 | SPI2 | SPI3 | -| ---- | ------------------------------------------- | --------------------------------------- | --------------------- | -| f072 | ? | B15 :heavy_check_mark: (needs SCK: B13) | N/A | -| f103 | A7 :heavy_check_mark: | B15 :heavy_check_mark: | N/A | -| f303 | A7 :heavy_check_mark: B5 :heavy_check_mark: | B15 :heavy_check_mark: | B5 :heavy_check_mark: | +`halconf.h`: +```c +#define HAL_USE_SPI TRUE +``` +`mcuconf.h`: +```c +#undef STM32_SPI_USE_SPI1 +#define STM32_SPI_USE_SPI1 TRUE +``` -*Other supported ChibiOS boards and/or pins may function, it will be highly chip and configuration dependent.* +The following `define`s apply only to the `spi` driver: -### PWM +|Define |Default |Description | +|--------------------------------|-------------|-------------------------------------------------------------------------------| +|`WS2812_SPI_DRIVER` |`SPID1` |The SPI driver to use | +|`WS2812_SPI_MOSI_PAL_MODE` |`5` |The MOSI pin alternative function to use | +|`WS2812_SPI_SCK_PIN` |*Not defined*|The SCK pin - required for F072 and possibly others | +|`WS2812_SPI_SCK_PAL_MODE` |`5` |The SCK pin alternative function to use - required for F072 and possibly others| +|`WS2812_SPI_DIVISOR` |`16` |The divisor used to adjust the baudrate | +|`WS2812_SPI_USE_CIRCULAR_BUFFER`|*Not defined*|Enable a circular buffer for improved rendering | -Targeting STM32 boards where WS2812 support is offloaded to an PWM timer and DMA stream. The advantage is that the use of DMA offloads processing of the WS2812 protocol from the MCU. To configure it, add this to your rules.mk: +#### Setting the Baudrate :id=arm-spi-baudrate -```make -WS2812_DRIVER = pwm -``` +To adjust the SPI baudrate, you will need to derive the target baudrate from the clock tree provided by STM32CubeMX, and add the following to your `config.h`: -Configure the hardware via your config.h: ```c -#define WS2812_PWM_DRIVER PWMD2 // default: PWMD2 -#define WS2812_PWM_CHANNEL 2 // default: 2 -#define WS2812_PWM_PAL_MODE 2 // Pin "alternate function", see the respective datasheet for the appropriate values for your MCU. default: 2 -//#define WS2812_PWM_COMPLEMENTARY_OUTPUT // Define for a complementary timer output (TIMx_CHyN); omit for a normal timer output (TIMx_CHy). -#define WS2812_DMA_STREAM STM32_DMA1_STREAM2 // DMA Stream for TIMx_UP, see the respective reference manual for the appropriate values for your MCU. -#define WS2812_DMA_CHANNEL 2 // DMA Channel for TIMx_UP, see the respective reference manual for the appropriate values for your MCU. -#define WS2812_DMAMUX_ID STM32_DMAMUX1_TIM2_UP // DMAMUX configuration for TIMx_UP -- only required if your MCU has a DMAMUX peripheral, see the respective reference manual for the appropriate values for your MCU. +#define WS2812_SPI_DIVISOR 16 ``` -Note that using a complementary timer output (TIMx_CHyN) is possible only for advanced-control timers (TIM1, TIM8, TIM20 on STM32), and the `STM32_PWM_USE_ADVANCED` option in mcuconf.h must be set to `TRUE`. Complementary outputs of general-purpose timers are not supported due to ChibiOS limitations. +Only divisors of 2, 4, 8, 16, 32, 64, 128 and 256 are supported on STM32 devices. Other MCUs may have similar constraints -- check the reference manual for your respective MCU for specifics. + +#### Circular Buffer :id=arm-spi-circular-buffer -You must also turn on the PWM feature in your halconf.h and mcuconf.h +A circular buffer can be enabled if you experience flickering. -#### Testing Notes +To enable the circular buffer, add the following to your `config.h`: -While not an exhaustive list, the following table provides the scenarios that have been partially validated: +```c +#define WS2812_SPI_USE_CIRCULAR_BUFFER +``` -| | Status | -| --------- | ------------------ | -| f072 | ? | -| f103 | :heavy_check_mark: | -| f303 | :heavy_check_mark: | -| f401/f411 | :heavy_check_mark: | +### PIO Driver :id=arm-pio-driver -*Other supported ChibiOS boards and/or pins may function, it will be highly chip and configuration dependent.* +The following `#define`s apply only to the PIO driver: -### PIO +|Define |Default |Description | +|---------------------|-------------|---------------------------------------| +|`WS2812_PIO_USE_PIO1`|*Not defined*|Use the PIO1 peripheral instead of PIO0| -Targeting Raspberry Pi RP2040 boards only where WS2812 support is offloaded to an dedicated PIO implementation. This offloads processing of the WS2812 protocol from the MCU to a dedicated PIO program using DMA transfers. +### PWM Driver :id=arm-pwm-driver -To configure it, add this to your rules.mk: +Depending on the ChibiOS board configuration, you may need to enable PWM at the keyboard level. For STM32, this would look like: -```make -WS2812_DRIVER = vendor +`halconf.h`: +```c +#define HAL_USE_PWM TRUE ``` - -You may optionally switch the PIO peripheral used with the following define in config.h: +`mcuconf.h`: ```c -#define WS2812_PIO_USE_PIO1 // Force the usage of PIO1 peripheral, by default the WS2812 implementation uses the PIO0 peripheral +#undef STM32_PWM_USE_TIM2 +#define STM32_PWM_USE_TIM2 TRUE ``` -The WS2812 PIO programm uses 1 state machine, 6 instructions and one DMA interrupt handler callback. Due to the implementation the time resolution for this drivers is 50ns, any value not specified in this interval will be rounded to the next matching interval. +The following `#define`s apply only to the `pwm` driver: -### Push Pull and Open Drain Configuration -The default configuration is a push pull on the defined pin. -This can be configured for bitbang, PWM and SPI. +|Define |Default |Description | +|---------------------------------|--------------------|------------------------------------------------------------------------------------------| +|`WS2812_PWM_DRIVER` |`PWMD2` |The PWM driver to use | +|`WS2812_PWM_CHANNEL` |`2` |The PWM channel to use | +|`WS2812_PWM_PAL_MODE` |`2` |The pin alternative function to use | +|`WS2812_DMA_STREAM` |`STM32_DMA1_STREAM2`|The DMA Stream for `TIMx_UP` | +|`WS2812_DMA_CHANNEL` |`2` |The DMA Channel for `TIMx_UP` | +|`WS2812_DMAMUX_ID` |*Not defined* |The DMAMUX configuration for `TIMx_UP` - only required if your MCU has a DMAMUX peripheral| +|`WS2812_PWM_COMPLEMENTARY_OUTPUT`|*Not defined* |Whether the PWM output is complementary (`TIMx_CHyN`) | -Note: This only applies to STM32 boards. +?> Using a complementary timer output (`TIMx_CHyN`) is possible only for advanced-control timers (1, 8 and 20 on STM32), and the `STM32_PWM_USE_ADVANCED` option in `mcuconf.h` must be set to `TRUE`. Complementary outputs of general-purpose timers are not supported due to ChibiOS limitations. - To configure the `WS2812_DI_PIN` to open drain configuration add this to your config.h file: -```c -#define WS2812_EXTERNAL_PULLUP -``` +## API :id=api + +### `void ws2812_setleds(rgb_led_t *ledarray, uint16_t number_of_leds)` :id=api-ws2812-setleds + +Send RGB data to the WS2812 LED chain. + +#### Arguments :id=api-ws2812-setleds-arguments + + - `rgb_led_t *ledarray` + A pointer to the LED array. + - `uint16_t number_of_leds` + The length of the LED array. diff --git a/zh-cn/_summary.md b/zh-cn/_summary.md index 0fc92e33d3a..a076f1a8c67 100644 --- a/zh-cn/_summary.md +++ b/zh-cn/_summary.md @@ -121,7 +121,6 @@ * [分体式键盘](zh-cn/feature_split_keyboard.md) * [速记](zh-cn/feature_stenography.md) * [热敏打印机](zh-cn/feature_thermal_printer.md) - * [Velocikey](zh-cn/feature_velocikey.md) * QMK开发 * [PR Checklist](zh-cn/pr_checklist.md)