The rev3 boards use RGBLIGHT_ENABLE now instead of BACKLIGHT_ENABLE.
This resolves the issue of flashing and losing functionality with the default keymap.
Added missing closing comment bit */
This seems to cause the QMK configurator to break when clicking the compile button:
Compiling: keyboards/handwired/split89/split89.c In file included from [K:
ent]
/* COL2ROW, ROW2COL */
[K
cc1: all warnings being treated as errors
|
|
|
make: *** ine/keyboards/handwired/split89/split89.o] Error 1
* Extensible split data sync capability through transactions.
- Split common transport has been split up between the transport layer
and data layer.
- Split "transactions" model used, with convergence between I2C and
serial data definitions.
- Slave matrix "generation count" is used to determine if the full slave
matrix needs to be retrieved.
- Encoders get the same "generation count" treatment.
- All other blocks of data are synchronised when a change is detected.
- All transmissions have a globally-configurable deadline before a
transmission is forced (`FORCED_SYNC_THROTTLE_MS`, default 100ms).
- Added atomicity for all core-synced data, preventing partial updates
- Added retries to AVR i2c_master's i2c_start, to minimise the number of
failed transactions when interrupts are disabled on the slave due to
atomicity checks.
- Some keyboards have had slight modifications made in order to ensure
that they still build due to firmware size restrictions.
* Fixup LED_MATRIX compile.
* Parameterise ERROR_DISCONNECT_COUNT.
* Intended usage is data validation in split transport code.
* Default space efficient algorithm.
* Opt-in fast table based algorithmn with #define CRC8_USE_TABLE switch.
* Define switches for size and speed optimized versions, the default is size
optimized by using uint_least8_t as datatype for calculations.
* #define CRC8_OPTIMIZE_SPEED uses uint_fast8_t as datatype for
calculations, this only affects 32-bit Archs like ARM and RISC-V.
* Placeholder crc_init() function for hardware backed crc calculation,
not implemented yet.
This binary keymap for ANAVI Macro Pad 2 helps with 0 and 1:
left key: 0
right key: 1
Combo press both keys to control the backlit.
Suggested-by: Chris <christopher.walker@crowdsupply.com>
Signed-off-by: Leon Anavi <leon@anavi.org>
* Top level heading for common config
Prior to this, the some of the common config looks like a detail of the APA102 driver
* Change heading to Common Config (RGB Matrix)
This commit makes atmel-dfu and chibios-dfu bootloaders retry to detect the bootloader
every 0,5 seconds (now configurable via the BOOTLOADER_RETRY_TIME makefile variable),
and a period is printed after every try. This is a much more pleasant behaviour than
the 5s retry timeout.
* Set saturation limit to jellybean_raindrops_anim.h
* Use faster bit-shift maths and qadd8
* Remove extra parenthesis
* Single bitmask operation is sufficient.
Co-authored-by: filterpaper <filterpaper@localhost>
This keymap for ANAVI Macro Pad 2 contains a couple of Skype
shortcuts for MS Windows and GNU/Linux distributions:
- Ctrl+M: Mute/unmute microphone
- Ctrl+Shift+K: Start/stop camera
Signed-off-by: Leon Anavi <leon@anavi.org>
* Enable SPI1 for GMMK pro
* Setup initial boilerplate for new LED driver
* RGB matrix minimally functional
* Map full LED matrix
* Return keymap to default
* Fix printscreen LED mapping
* Reduce max brightness
* Default values for AW20216
* Add documentation for AW20216
* Disable console and warnings
* Run cformat
* Update drivers/awinic/aw20216.h
Co-authored-by: Drashna Jaelre <drashna@live.com>
* make aw struct match issi struct
Co-authored-by: Drashna Jaelre <drashna@live.com>
* add led location defines
Co-authored-by: Drashna Jaelre <drashna@live.com>
* Use led pin definitions in keyboard.c
* Add driver indices to led map
* Fix elif typo
* Run cformat
* Update docs
* Fix typo in docs
* Document global brightness limits
Co-authored-by: Drashna Jaelre <drashna@live.com>
* Add fast_timer_t that is 16-bit or 32-bit based on architecture
A 16-bit timer will overflow sooner but be faster to compare on AVR.
* Avoid 8-bit timer overflows in debounce algorithms
Count down remaining elapsed time instead of trying to do 8-bit timer
comparisons.
Add a "none" implementation that is automatically used if DEBOUNCE is
0 otherwise it will break the _pk/_pr count down.
* Avoid unnecessary polling of the entire matrix in sym_eager_pk
The matrix only needs to be updated when a debounce timer expires.
* Avoid unnecessary polling of the entire matrix in sym_eager_pr
The matrix only needs to be updated when a debounce timer expires.
The use of the "needed_update" variable is trying to do what
"matrix_need_update" was added to fix but didn't work because it only
applied when all keys finished debouncing.
* Fix sym_defer_g timing inconsistency compared to other debounce algorithms
DEBOUNCE=5 should process the key after 5ms, not 6ms
* Add debounce tests
* Use memcmp to determine if matrix changed.
* Firmware size issues.
* Add documentation for the lack of need of MATRIX_ROW_PINS/MATRIX_COL_PINS, when overriding low-level matrix functions.
* add readPort() and some API to 'tmk_core/common/*/gpio.h'
The following macros have been added to gpio.h.
* readPort(port)
* setPortBitInput(port, bit)
* setPortBitInputHigh(port, bit)
* setPortBitOutput(port, bit)
* writePortBitLow(port, bit)
* writePortBitHigh(port, bit)
* add data type 'port_data_t' into gpio.h
* rename qmk_pin to pin
Debian bullseye (testing at the moment, but seems close to release) has
avr-libc 1:2.0.0+Atmel3.6.2-1.1 with some changes taken from the
Atmel-distributed toolchain. In particular, the <avr/io.h> header for
ATmega32A (avr/iom32a.h) now defines the FLASHEND constant as `0x7FFFU`,
and that `U` suffix breaks the firmware size check code, because the
shell arithmetic expansion that is used to calculate `MAX_SIZE` does not
support those C-specific suffixes.
As a workaround, add `-D__ASSEMBLER__` to the C preprocessor invocation
that is used to expand those macros; in this case avr/iom32a.h defines
`FLASHEND` without the `U` suffix, and everything works as it did before
with older avr-libc versions.
The exact same code is present in two places; they are both changed,
even though the code in `tmk_core/avr.mk` is actually never used for
ATmega32A (and the header for ATmega32U4 does not add that `U` suffix to
`FLASHEND` for some reason).
* Update ChibiOS, ChibiOS-Contrib.
* Add instructions.
* Wrong remote name
* Explicit version tag.
* Add link to procedure on the breaking changes page.
I noticed this discrepancy (last row of the matrix treated differently than the
others) when optimizing the input latency of my keyboard controller, see also
https://michael.stapelberg.ch/posts/2021-05-08-keyboard-input-latency-qmk-kinesis/
Before this commit, when tuning the delays I noticed ghost key presses when
pressing the F2 key, which is on the last row of the keyboard matrix: the
dead_grave key, which is on the first row of the keyboard matrix, would be
incorrectly detected as pressed.
After this commit, all keyboard matrix rows are interpreted correctly.
I suspect that my setup is more susceptible to this nuance than others because I
use GPIO_INPUT_PIN_DELAY=0 and hence don’t have another delay that might mask
the problem.
* Implement function rgblight_blink_layer_repeat to allow repeated blinking of one layer at a time
* Update doc
* Rework rgblight blinking according to requested change
* optimize storage
This converts the array that the Swap Hands feature uses to use PROGMEM,
and to read from that array, as such. Since this array never changes at
runtime, there is no reason to keep it in memory. Especially for AVR
boards, as memory is a precious resource.
* stash poc
* stash
* tidy up implementation
* Tidy up slightly for review
* Tidy up slightly for review
* Bodge environment to make tests pass
* Refactor away from asyncio due to windows issues
* Filter devices
* align vid/pid printing
* Add hidapi to the installers
* start preparing for multiple hid_listeners
* udev rules for hid_listen
* refactor to move closer to end state
* very basic implementation of the threaded model
* refactor how vid/pid/index are supplied and parsed
* windows improvements
* read the report directly when usage page isn't available
* add per-device colors, the choice to show names or numbers, and refactor
* add timestamps
* Add support for showing bootloaders
* tweak the color for bootloaders
* Align bootloader disconnect with connect color
* add support for showing all bootloaders
* fix the pyusb check
* tweaks
* fix exception
* hide a stack trace behind -v
* add --no-bootloaders option
* add documentation for qmk console
* Apply suggestions from code review
Co-authored-by: Ryan <fauxpark@gmail.com>
* pyformat
* clean up and flesh out KNOWN_BOOTLOADERS
Co-authored-by: zvecr <git@zvecr.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* Add support for MCU = STM32F446
* Update platforms/chibios/GENERIC_STM32_F446XE/configs/config.h
Co-authored-by: Nick Brassel <nick@tzarc.org>
* Restore mcuconf.h to the one used by RT-STM32F446RE-NUCLEO64
* stm32f446: update mcuconf.h and board.h for 16MHz operation, with USB enabled, and other peripherals disabled.
Co-authored-by: Nick Brassel <nick@tzarc.org>
* Fix default ADC_RESOLUTION for ADCv3 (and ADCv4)
Recent ChibiOS update removed ADC_CFGR1_RES_10BIT from the ADCv3 headers
(that macro should not have been there, because ADCv3 has CFGR instead of
CFGR1). Fix the default value for ADC_RESOLUTION to use ADC_CFGR_RES_10BITS
if it is defined (that name is used for ADCv3 and ADCv4).
* Update ADC docs to match the actually used resolution
ADC driver for ChibiOS actually uses the 10-bit resolution by default
(probably to match AVR); fix the documentation accordingly. Also add
both ADC_CFGR_RES_10BITS and ADC_CFGR1_RES_10BIT constants (these names
differ according to the ADC implementation in the particular MCU).
* Fix pinToMux() for B12 and B13 on STM32F3xx
Testing on STM32F303CCT6 revealed that the ADC mux values for B12 and
B13 pins were wrong.
* Add support for all possible analog pins on STM32F1xx
Added ADC mux values for pins A0...A7, B0, B1, C0...C5 on STM32F1xx
(they are the same at least for STM32F103x8 and larger F103 devices, and
also F102, F105, F107 families). Actually tested on STM32F103C8T6
(therefore pins C0...C5 were not tested).
Pins F6...F10, which are present on STM32F103x[C-G] in 144-pin packages,
cannot be supported at the moment, because those pins are connected only
to ADC3, but the ChibiOS ADC driver for STM32F1xx supports only ADC1.
* Add support for all possible analog pins on STM32F4xx
Added ADC mux values for pins A0...A7, B0, B1, C0...C5 and optionally
F3...F10 (if STM32_ADC_USE_ADC3 is enabled). These mux values are
apparently the same for all F4xx devices, except some smaller devices may
not have ADC3.
Actually tested on STM32F401CCU6, STM32F401CEU6, STM32F411CEU6 (using
various WeAct “Blackpill” boards); only pins A0...A7, B0, B1 were tested.
Pins F3...F10 are inside `#if STM32_ADC_USE_ADC3` because some devices
which don't have ADC3 also don't have the GPIOF port, therefore the code
which refers to Fx pins does not compile.
* Fix STM32F3xx ADC mux table in documentation
The ADC driver documentation had some errors in the mux table for STM32F3xx.
Fix this table to match the datasheet and the actual code (mux settings for
B12 and B13 were also tested on a real STM32F303CCT6 chip).
* Add STM32F1xx ADC pins to the documentation
* Add STM32F4xx ADC pins to the documentation
This moves the config_common.h into the files that include ../config.h,
so that the kint36/config.h does not include it (which would cause
compilation errors).
* In split keyboards fix connection issue when slave and OLED are connected via I2C. Fix#9335
* Revert "In split keyboards fix connection issue when slave and OLED are connected via I2C. Fix#9335"
This reverts commit 3ee639e1f3.
* In split keyboards fix connection issue when slave and OLED are connected via I2C. Fix#9335
* Update drivers/oled/oled_driver.c
Co-authored-by: Drashna Jaelre <drashna@live.com>
Co-authored-by: osenchenko <osechenko@chiefmate.io>
Co-authored-by: Drashna Jaelre <drashna@live.com>
* Durgod keyboard refactor in preparation for adding additional durgod keyboards
* Moving Durgod board configuration into a common location
* Reformatting layout macro whitespace
* Moving TGUI key functionality to the keyboard level
* Replacing default keymap.c with keymap.json
* Changing default and default_toggle_mac_windows keymaps to LAYOUT_all
* Increasing EEPROM size to support more VIA layers
* Fixing media keys; KC_MRWD/KC_MFFD => KC_MPRV/KC_NXT
* Move ISO Enter key to the correct row in Durgod K320
* Minor whitespace and readme cleanup for K320
* Changing durgod/k320 debounce back to default
* Simplifying DURGOD_STM32_F070's chconf.h
Co-authored-by: Simon Arlott <sa.me.uk>
Co-authored-by: Tyler Tidman <tyler.tidman@draak.ca>
Because the matrix scanning is slower for splits, in general,
the frequent updating of the OLEDs can slow down the matrix scanning.
To help prevent that, set the update interval for the OLEDs to not
update as frequently.
* Initial refactor of ARM SLEEP_LED to enable more platforms
* fix build issues
* Disable SLEEP_LED for boards with no caps lock code
* Enable GPT14 for boards with caps lock code and SLEEP_LED enabled
* Enable GPT for boards with caps lock code and SLEEP_LED enabled
ChibiOS and ChibiOS-Contrib need to be updated in tandem -- the latter has a branch tied to the ChibiOS version in use and should not be mixed with different versions.
## Getting ChibiOS
*`svn` Initialisation:
* Only needed to be done once
* You might need to separately install `git-svn` package in your OS's package manager
@@ -51,8 +51,10 @@ This is a C header file that is one of the first things included, and will persi
* the number of columns in your keyboard's matrix
*`#define MATRIX_ROW_PINS { D0, D5, B5, B6 }`
* pins of the rows, from top to bottom
* may be omitted by the keyboard designer if matrix reads are handled in an alternate manner. See [low-level matrix overrides](custom_quantum_functions.md?id=low-level-matrix-overrides) for more information.
* may be omitted by the keyboard designer if matrix reads are handled in an alternate manner. See [low-level matrix overrides](custom_quantum_functions.md?id=low-level-matrix-overrides) for more information.
*`#define MATRIX_IO_DELAY 30`
* the delay in microseconds when between changing matrix pin state and reading values
*`#define UNUSED_PINS { D1, D2, D3, B1, B2, B3 }`
@@ -272,7 +274,7 @@ There are a few different ways to set handedness for split keyboards (listed in
### Other Options
*`#define USE_I2C`
* For using I2C instead of Serial (defaults to serial)
* For using I2C instead of Serial (default is serial; serial transport is supported on ARM -- I2C is AVR-only)
*`#define SOFT_SERIAL_PIN D0`
* When using serial, define this. `D0` or `D1`,`D2`,`D3`,`E6`.
@@ -280,6 +282,7 @@ There are a few different ways to set handedness for split keyboards (listed in
*`#define MATRIX_ROW_PINS_RIGHT { <row pins> }`
*`#define MATRIX_COL_PINS_RIGHT { <col pins> }`
* If you want to specify a different pinout for the right half than the left half, you can define `MATRIX_ROW_PINS_RIGHT`/`MATRIX_COL_PINS_RIGHT`. Currently, the size of `MATRIX_ROW_PINS` must be the same as `MATRIX_ROW_PINS_RIGHT` and likewise for the definition of columns.
* may be omitted by the keyboard designer if matrix reads are handled in an alternate manner. See [low-level matrix overrides](custom_quantum_functions.md?id=low-level-matrix-overrides) for more information.
* If you want to specify a different direct pinout for the right half than the left half, you can define `DIRECT_PINS_RIGHT`. Currently, the size of `DIRECT_PINS` must be the same as `DIRECT_PINS_RIGHT`.
@@ -300,7 +303,7 @@ There are a few different ways to set handedness for split keyboards (listed in
*`#define SPLIT_USB_DETECT`
* Detect (with timeout) USB connection when delegating master/slave
* Default behavior for ARM
* Required for AVR Teensy
* Required for AVR Teensy (without hardware mods)
*`#define SPLIT_USB_TIMEOUT 2000`
* Maximum timeout when detecting master/slave when using `SPLIT_USB_DETECT`
@@ -308,6 +311,28 @@ There are a few different ways to set handedness for split keyboards (listed in
*`#define SPLIT_USB_TIMEOUT_POLL 10`
* Poll frequency when detecting master/slave when using `SPLIT_USB_DETECT`
*`#define FORCED_SYNC_THROTTLE_MS 100`
* Deadline for synchronizing data from master to slave when using the QMK-provided split transport.
*`#define SPLIT_TRANSPORT_MIRROR`
* Mirrors the master-side matrix on the slave when using the QMK-provided split transport.
*`#define SPLIT_LAYER_STATE_ENABLE`
* Ensures the current layer state is available on the slave when using the QMK-provided split transport.
*`#define SPLIT_LED_STATE_ENABLE`
* Ensures the current host indicator state (caps/num/scroll) is available on the slave when using the QMK-provided split transport.
*`#define SPLIT_MODS_ENABLE`
* Ensures the current modifier state (normal, weak, and oneshot) is available on the slave when using the QMK-provided split transport.
*`#define SPLIT_WPM_ENABLE`
* Ensures the current WPM is available on the slave when using the QMK-provided split transport.
*`#define SPLIT_TRANSACTION_IDS_KB .....`
*`#define SPLIT_TRANSACTION_IDS_USER .....`
* Allows for custom data sync with the slave when using the QMK-provided split transport. See [custom data sync between sides](feature_split_keyboard.md#custom-data-sync) for more information.
# The `rules.mk` File
This is a [make](https://www.gnu.org/software/make/manual/make.html) file that is included by the top-level `Makefile`. It is used to set some information about the MCU that we will be compiling for as well as enabling and disabling certain features.
* This needs to perform the low-level initialisation of all row and column pins. By default this will initialise the input/output state of each of the GPIO pins listed in `MATRIX_ROW_PINS` and `MATRIX_COL_PINS`, based on whether or not the keyboard is set up for `ROW2COL`, `COL2ROW`, or `DIRECT_PINS`. Should the keyboard designer override this function, no initialisation of pin state will occur within QMK itself, instead deferring to the keyboard's override.
* These three functions need to perform the low-level retrieval of matrix state of relevant input pins, based on the matrix type. Only one of the functions should be implemented, if needed. By default this will iterate through `MATRIX_ROW_PINS` and `MATRIX_COL_PINS`, configuring the inputs and outputs based on whether or not the keyboard is set up for `ROW2COL`, `COL2ROW`, or `DIRECT_PINS`. Should the keyboard designer override this function, no manipulation of matrix GPIO pin state will occur within QMK itself, instead deferring to the keyboard's override.
@@ -131,12 +131,14 @@ You can override the default songs by doing something like this in your `config.
```c
#ifdef AUDIO_ENABLE
#define STARTUP_SONG SONG(STARTUP_SOUND)
#define STARTUP_SONG SONG(STARTUP_SOUND)
#endif
```
A full list of sounds can be found in [quantum/audio/song_list.h](https://github.com/qmk/qmk_firmware/blob/master/quantum/audio/song_list.h) - feel free to add your own to this list! All available notes can be seen in [quantum/audio/musical_notes.h](https://github.com/qmk/qmk_firmware/blob/master/quantum/audio/musical_notes.h).
Additionally, if you with to maintain your own list of songs (such as ones that may be copyrighted) and not have them added to the repo, you can create a `user_song_list.h` file and place it in your keymap (or userspace) folder. This file will be automatically included, it just needs to exist.
To play a custom sound at a particular time, you can define a song like this (near the top of the file):
@@ -121,16 +121,16 @@ DEBOUNCE_TYPE = <name of algorithm>
Where name of algorithm is one of:
* ```sym_defer_g``` - debouncing per keyboard. On any state change, a global timer is set. When ```DEBOUNCE``` milliseconds of no changes has occurred, all input changes are pushed.
* This is the current default algorithm. This is the highest performance algorithm with lowest memory usage, and it's also noise-resistant.
* ```sym_eager_pr``` - debouncing per row. On any state change, response is immediate, followed by locking the row ```DEBOUNCE``` milliseconds of no further input for that row.
* ```sym_eager_pr``` - debouncing per row. On any state change, response is immediate, followed by locking the row ```DEBOUNCE``` milliseconds of no further input for that row.
For use in keyboards where refreshing ```NUM_KEYS``` 8-bit counters is computationally expensive / low scan rate, and fingers usually only hit one row at a time. This could be
appropriate for the ErgoDox models; the matrix is rotated 90°, and hence its "rows" are really columns, and each finger only hits a single "row" at a time in normal use.
* ```sym_eager_pk``` - debouncing per key. On any state change, response is immediate, followed by ```DEBOUNCE``` milliseconds of no further input for that key
* ```sym_defer_pk``` - debouncing per key. On any state change, a per-key timer is set. When ```DEBOUNCE``` milliseconds of no changes have occurred on that key, the key status change is pushed.
* ```asym_eager_defer_pk``` - debouncing per key. On a key-down state change, response is immediate, followed by ```DEBOUNCE``` milliseconds of no further input for that key. On a key-up state change, a per-key timer is set. When ```DEBOUNCE``` milliseconds of no changes have occurred on that key, the key-up status change is pushed.
### A couple algorithms that could be implemented in the future:
* ```sym_defer_pr```
* ```sym_eager_g```
* ```asym_eager_defer_pk```
### Use your own debouncing code
You have the option to implement you own debouncing algorithm. To do this:
@@ -162,4 +162,28 @@ This will set what sequence HPT_RST will set as the active mode. If not defined,
### DRV2605L Continuous Haptic Mode
This mode sets continuous haptic feedback with the option to increase or decrease strength.
This mode sets continuous haptic feedback with the option to increase or decrease strength.
## Haptic Key Exclusion
The Haptic Exclusion is implemented as `__attribute__((weak)) bool get_haptic_enabled_key(uint16_t keycode, keyrecord_t *record)` in haptic.c. This allows a re-definition at the required level with the specific requirement / exclusion.
### NO_HAPTIC_MOD
With the entry of `#define NO_HAPTIC_MOD` in config.h, modifiers from Left Control to Right GUI will not trigger a feedback. This also includes modifiers in a Mod Tap configuration.
### NO_HAPTIC_FN
With the entry of `#define NO_HAPTIC_FN` in config.h, layer keys will not rigger a feedback.
### NO_HAPTIC_ALPHA
With the entry of `#define NO_HAPTIC_ALPHA` in config.h, none of the alpha keys (A ... Z) will trigger a feedback.
### NO_HAPTIC_PUNCTUATION
With the entry of `#define NO_HAPTIC_PUNCTUATION` in config.h, none of the following keys will trigger a feedback: Enter, ESC, Backspace, Space, Minus, Equal, Left Bracket, Right Bracket, Backslash, Non-US Hash, Semicolon, Quote, Grave, Comma, Slash, Dot, Non-US Backslash.
### NO_HAPTIC_LOCKKEYS
With the entry of `#define NO_HAPTIC_LOCKKEYS` in config.h, none of the following keys will trigger a feedback: Caps Lock, Scroll Lock, Num Lock.
### NO_HAPTIC_NAV
With the entry of `#define NO_HAPTIC_NAV` in config.h, none of the following keys will trigger a feedback: Print Screen, Pause, Insert, Delete, Page Down, Page Up, Left Arrow, Up Arrow, Right Arrow, Down Arrow, End, Home.
### NO_HAPTIC_NUMERIC
With the entry of `#define NO_HAPTIC_NUMERIC` in config.h, none of the following keys between 0 and 9 (KC_1 ... KC_0) will trigger a feedback.
@@ -67,6 +67,8 @@ Where `Cx_y` is the location of the LED in the matrix defined by [the datasheet]
---
## Common Configuration :id=common-configuration
From this point forward the configuration is the same for all the drivers. The `led_config_t` struct provides a key electrical matrix to led index lookup table, what the physical position of each LED is on the board, and what type of key or usage the LED if the LED represents. Here is a brief example:
@@ -228,6 +228,76 @@ Configure the hardware via your `config.h`:
```
---
### AW20216 :id=aw20216
There is basic support for addressable RGB matrix lighting with the SPI AW20216 RGB controller. To enable it, add this to your `rules.mk`:
```makefile
RGB_MATRIX_ENABLE= yes
RGB_MATRIX_DRIVER= AW20216
```
You can use up to 2 AW20216 IC's. Do not specify `DRIVER_<N>_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 | |
| `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 | |
| `DRIVER_LED_TOTAL` | (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 |
Here is an example using 2 drivers.
```c
#define DRIVER_1_CS B13
#define DRIVER_2_CS B14
// Hardware enable lines may be connected to the same pin
!> Note the parentheses, this is so when `DRIVER_LED_TOTAL` 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`.
Define these arrays listing all the LEDs in your `<keyboard>.c`:
```c
constaw_ledg_aw_leds[DRIVER_LED_TOTAL]={
/* Each AW20216 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
* driver pin locations.
* driver
* | R location
* | | G location
* | | | B location
* | | | | */
{0,CS1_SW1,CS2_SW1,CS3_SW1},
{0,CS4_SW1,CS5_SW1,CS6_SW1},
{0,CS7_SW1,CS8_SW1,CS9_SW1},
{0,CS10_SW1,CS11_SW1,CS12_SW1},
{0,CS13_SW1,CS14_SW1,CS15_SW1},
...
{1,CS1_SW1,CS2_SW1,CS3_SW1},
{1,CS13_SW1,CS14_SW1,CS15_SW1},
{1,CS16_SW1,CS17_SW1,CS18_SW1},
{1,CS4_SW2,CS5_SW2,CS6_SW2},
...
};
```
---
## Common Configuration :id=common-configuration
From this point forward the configuration is the same for all the drivers. The `led_config_t` struct provides a key electrical matrix to led index lookup table, what the physical position of each LED is on the board, and what type of key or usage the LED if the LED represents. Here is a brief example:
@@ -8,8 +8,7 @@ QMK Firmware has a generic implementation that is usable by any board, as well a
For this, we will mostly be talking about the generic implementation used by the Let's Split and other keyboards.
!> ARM is not yet fully supported for Split Keyboards and has many limitations. Progress is being made, but we have not yet reached 100% feature parity.
!> ARM split supports most QMK subsystems when using the 'serial' and 'serial_usart' drivers. I2C slave is currently unsupported.
## Compatibility Overview
@@ -60,6 +59,7 @@ The 3 wires of the TRS/TRRS cable need to connect GND, VCC, and D0/D1/D2/D3 (aka
The 4 wires of the TRRS cable need to connect GND, VCC, and SCL and SDA (aka PD0/pin 3 and PD1/pin 2, respectively) between the two Pro Micros.
The pull-up resistors may be placed on either half. If you wish to use the halves independently, it is also possible to use 4 resistors and have the pull-ups in both halves.
Note that the total resistance for the connected system should be within spec at 2.2k-10kOhm, with an 'ideal' at 4.7kOhm, regardless of the placement and number.
@@ -168,7 +168,7 @@ Because not every split keyboard is identical, there are a number of additional
#define USE_I2C
```
This enables I<sup>2</sup>C support for split keyboards. This isn't strictly for communication, but can be used for OLED or other I<sup>2</sup>C-based devices.
This configures the use of I<sup>2</sup>C support for split keyboard transport (AVR only).
```c
#define SOFT_SERIAL_PIN D0
@@ -192,20 +192,115 @@ If you're having issues with serial communication, you can change this value, as
* **`5`**: about 20kbps
```c
#define SPLIT_MODS_ENABLE
#define FORCED_SYNC_THROTTLE_MS 100
```
This enables transmitting modifier state (normal, weak and oneshot) to the non
primary side of the split keyboard. This adds a few bytes of data to the split
communication protocol and may impact the matrix scan speed when enabled.
The purpose of this feature is to support cosmetic use of modifer state (e.g.
displaying status on an OLED screen).
This sets the maximum number of milliseconds before forcing a synchronization of data from master to slave. Under normal circumstances this sync occurs whenever the data _changes_, for safety a data transfer occurs after this number of milliseconds if no change has been detected since the last sync.
```c
#define SPLIT_TRANSPORT_MIRROR
```
This mirrors the master side matrix to the slave side for features that react or require knowledge of master side key presses on the slave side. This adds a few bytes of data to the split communication protocol and may impact the matrix scan speed when enabled. The purpose of this feature is to support cosmetic use of key events (e.g. RGB reacting to Keypresses).
This mirrors the master side matrix to the slave side for features that react or require knowledge of master side key presses on the slave side. The purpose of this feature is to support cosmetic use of key events (e.g. RGB reacting to keypresses). This adds overhead to the split communication protocol and may negatively impact the matrix scan speed when enabled.
```c
#define SPLIT_LAYER_STATE_ENABLE
```
This enables syncing of the layer state between both halves of the split keyboard. The main purpose of this feature is to enable support for use of things like OLED display of the currently active layer. This adds overhead to the split communication protocol and may negatively impact the matrix scan speed when enabled.
```c
#define SPLIT_LED_STATE_ENABLE
```
This enables syncing of the Host LED status (caps lock, num lock, etc) between both halves of the split keyboard. The main purpose of this feature is to enable support for use of things like OLED display of the Host LED status. This adds overhead to the split communication protocol and may negatively impact the matrix scan speed when enabled.
```c
#define SPLIT_MODS_ENABLE
```
This enables transmitting modifier state (normal, weak and oneshot) to the non primary side of the split keyboard. The purpose of this feature is to support cosmetic use of modifer state (e.g. displaying status on an OLED screen). This adds overhead to the split communication protocol and may negatively impact the matrix scan speed when enabled.
```c
#define SPLIT_WPM_ENABLE
```
This enables transmitting the current WPM to the slave side of the split keyboard. The purpose of this feature is to support cosmetic use of WPM (e.g. displaying the current value on an OLED screen). This adds overhead to the split communication protocol and may negatively impact the matrix scan speed when enabled.
### Custom data sync between sides :id=custom-data-sync
QMK's split transport allows for arbitrary data transactions at both the keyboard and user levels. This is modelled on a remote procedure call, with the master invoking a function on the slave side, with the ability to send data from master to slave, process it slave side, and send data back from slave to master.
To leverage this, a keyboard or user/keymap can define a comma-separated list of _transaction IDs_:
The master side can then invoke the slave-side handler - for normal keyboard functionality to be minimally affected, any keyboard- or user-level code attempting to sync data should be throttled:
dprintf("Slave value: %d\n",s2m.s2m_data);// this will now be 11, as the slave adds 5
}else{
dprint("Slave sync failed!\n");
}
}
}
}
```
!> It is recommended that any data sync between halves happens during the master side's _housekeeping task_. This ensures timely retries should failures occur.
If only one-way data transfer is needed, helper methods are provided:
For some purposes, you may need to read the current state of the display buffer. The `st7565_read_raw` function can be used to safely read bytes from the buffer.
In this example, calling `fade_display` in the `st7565_task_user` function will slowly fade away whatever is on the screen by turning random pixels off over time.
```c
//Setup some mask which can be or'd with bytes to turn off pixels
//increment the pointer to fetch a new byte during the next loop
reader.current_element++;
}
}
}
```
## Other Examples
In split keyboards, it is very common to have two displays that each render different content and are oriented or flipped differently. You can do this by switching which content to render by using the return value from `is_keyboard_master()` or `is_keyboard_left()` found in `split_util.h`, e.g:
Linux では、ブートローダデバイスと通信するには適切な権限が必要です。ファームウェアを書き込む時に `sudo` を使うか(非推奨)、`/etc/udev/rules.d/` に[このファイル](https://github.com/qmk/qmk_firmware/tree/master/util/udev/50-qmk.rules)を配置することで、通信することができます。
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Zach White