From b338a4d8867f69bd6a92ec92e306715a4ae41740 Mon Sep 17 00:00:00 2001 From: Drashna Jaelre Date: Tue, 25 Aug 2020 02:08:09 -0700 Subject: Add noeeprom speed function for RGBLIGHT (#9706) * [Docs] Add Speed functions to RGB Light docs * Add noeeprom functions for speed * Fix wording in doc Co-authored-by: Ryan Co-authored-by: Ryan --- docs/feature_rgblight.md | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'docs') diff --git a/docs/feature_rgblight.md b/docs/feature_rgblight.md index a81b50e828..26e01da501 100644 --- a/docs/feature_rgblight.md +++ b/docs/feature_rgblight.md @@ -377,6 +377,17 @@ rgblight_sethsv(HSV_GREEN, 2); // led 2 |`rgblight_sethsv(h, s, v)` |Set effect range LEDs to the given HSV value where `h`/`s`/`v` are between 0 and 255 | |`rgblight_sethsv_noeeprom(h, s, v)` |Set effect range LEDs to the given HSV value where `h`/`s`/`v` are between 0 and 255 (not written to EEPROM) | +#### Speed functions +|Function |Description | +|--------------------------------------------|-------------| +|`rgblight_increase_speed()` |Increases the animation speed | +|`rgblight_increase_speed_noeeprom()` |Increases the animation speed (not written to EEPROM) | +|`rgblight_decrease_speed()` |Decreases the animation speed | +|`rgblight_decrease_speed_noeeprom()` |Decreases the animation speed (not written to EEPROM) | +|`rgblight_set_speed()` |Sets the speed. Value is between 0 and 255 | +|`rgblight_set_speed_noeeprom()` |Sets the speed. Value is between 0 and 255 (not written to EEPROM) | + + #### layer functions |Function |Description | |--------------------------------------------|-------------| -- cgit v1.2.3 From 8a4a0c25fdb2c4d0ac3ac8fd5f6ba14b56f4cd28 Mon Sep 17 00:00:00 2001 From: Ryan Date: Thu, 2 Jul 2020 13:12:34 +1000 Subject: Change analogRead calls to analogReadPin (#9023) * Change analogRead calls to analogReadPin * Add ChangeLog * Update docs, remove mention of `analogRead()` * Retarget changelog for next round --- docs/ChangeLog/20200829/PR9023.md | 5 +++++ docs/adc_driver.md | 39 ++++++++++++++++++--------------------- 2 files changed, 23 insertions(+), 21 deletions(-) create mode 100644 docs/ChangeLog/20200829/PR9023.md (limited to 'docs') diff --git a/docs/ChangeLog/20200829/PR9023.md b/docs/ChangeLog/20200829/PR9023.md new file mode 100644 index 0000000000..79ca2cb2f8 --- /dev/null +++ b/docs/ChangeLog/20200829/PR9023.md @@ -0,0 +1,5 @@ +# Deprecation of `analogRead()` + +[#9023](https://github.com/qmk/qmk_firmware/pull/9023) + +This function takes Arduino pin numbers (eg. `9` vs. `B5`), which is at odds with the rest of the codebase. The replacement for this function is `analogReadPin()`. diff --git a/docs/adc_driver.md b/docs/adc_driver.md index f8fb94094e..6e3d513863 100644 --- a/docs/adc_driver.md +++ b/docs/adc_driver.md @@ -45,9 +45,9 @@ Then place this include at the top of your code: Note that some of these pins are doubled-up on ADCs with the same channel. This is because the pins can be used for either ADC. -Also note that the F0 and F3 use different numbering schemes. The F0 has a single ADC and the channels are 0-based, whereas the F3 has 4 ADCs and the channels are 1 based. This is because the F0 uses the `ADCv1` implementation of the ADC, whereas the F3 uses the `ADCv3` implementation. +Also note that the F0 and F3 use different numbering schemes. The F0 has a single ADC and the channels are 0-indexed, whereas the F3 has 4 ADCs and the channels are 1-indexed. This is because the F0 uses the `ADCv1` implementation of the ADC, whereas the F3 uses the `ADCv3` implementation. -|ADC|Channel|STM32F0XX|STM32F3XX| +|ADC|Channel|STM32F0xx|STM32F3xx| |---|-------|---------|---------| |1 |0 |`A0` | | |1 |1 |`A1` |`A0` | @@ -122,32 +122,29 @@ Also note that the F0 and F3 use different numbering schemes. The F0 has a singl |Function |Description | |----------------------------|-------------------------------------------------------------------------------------------------------------------| |`analogReference(mode)` |Sets the analog voltage reference source. Must be one of `ADC_REF_EXTERNAL`, `ADC_REF_POWER` or `ADC_REF_INTERNAL`.| -|`analogRead(pin)` |Reads the value from the specified Arduino pin, eg. `4` for ADC6 on the ATmega32U4. | -|`analogReadPin(pin)` |Reads the value from the specified QMK pin, eg. `F6` for ADC6 on the ATmega32U4. | -|`pinToMux(pin)` |Translates a given QMK pin to a mux value. If an unsupported pin is given, returns the mux value for "0V (GND)". | +|`analogReadPin(pin)` |Reads the value from the specified pin, eg. `F6` for ADC6 on the ATmega32U4. | +|`pinToMux(pin)` |Translates a given pin to a mux value. If an unsupported pin is given, returns the mux value for "0V (GND)". | |`adc_read(mux)` |Reads the value from the ADC according to the specified mux. See your MCU's datasheet for more information. | ### ARM -Note that care was taken to match all of the functions used for AVR devices, however complications in the ARM platform prevent that from always being possible. For example, the `STM32` chips do not have assigned Arduino pins. We could use the default pin numbers, but those numbers change based on the package type of the device. For this reason, please specify your target pins with their identifiers (`A0`, `F3`, etc.). Also note that there are some variants of functions that accept the target ADC for the pin. Some pins can be used for multiple ADCs, and this specified can help you pick which ADC will be used to interact with that pin. - -|Function |Description | -|----------------------------|--------------------------------------------------------------------------------------------------------------------| -|`analogReadPin(pin)` |Reads the value from the specified QMK pin, eg. `A0` for channel 0 on the STM32F0 and ADC1 channel 1 on the STM32F3. Note that if a pin can be used for multiple ADCs, it will pick the lower numbered ADC for this function. eg. `C0` will be channel 6 of ADC 1 when it could be used for ADC 2 as well.| -|`analogReadPinAdc(pin, adc)`|Reads the value from the specified QMK pin and ADC, eg. `C0, 1` will read from channel 6, ADC 2 instead of ADC 1. Note that the ADCs are 0-indexed for this function.| -|`pinToMux(pin)` |Translates a given QMK pin to a channel and ADC combination. If an unsupported pin is given, returns the mux value for "0V (GND)".| -|`adc_read(mux)` |Reads the value from the ADC according to the specified pin and adc combination. See your MCU's datasheet for more information.| +|Function |Description | +|----------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +|`analogReadPin(pin)` |Reads the value from the specified pin, eg. `A0` for channel 0 on the STM32F0 and ADC1 channel 1 on the STM32F3. Note that if a pin can be used for multiple ADCs, it will pick the lower numbered ADC for this function. eg. `C0` will be channel 6 of ADC 1 when it could be used for ADC 2 as well.| +|`analogReadPinAdc(pin, adc)`|Reads the value from the specified pin and ADC, eg. `C0, 1` will read from channel 6, ADC 2 instead of ADC 1. Note that the ADCs are 0-indexed for this function. | +|`pinToMux(pin)` |Translates a given pin to a channel and ADC combination. If an unsupported pin is given, returns the mux value for "0V (GND)". | +|`adc_read(mux)` |Reads the value from the ADC according to the specified pin and ADC combination. See your MCU's datasheet for more information. | ## Configuration ## ARM -The ARM implementation of the ADC has a few additional options that you can override in your own keyboards and keymaps to change how it operates. +The ARM implementation of the ADC has a few additional options that you can override in your own keyboards and keymaps to change how it operates. Please consult the corresponding `hal_adc_lld.h` in ChibiOS for your specific microcontroller for further documentation on your available options. -|`#define` |Type |Default |Description| -|-------------------|------|---------------------|-----------| -|ADC_CIRCULAR_BUFFER|`bool`|`false` |If `TRUE`, then the implementation will use a circular buffer.| -|ADC_NUM_CHANNELS |`int` |`1` |Sets the number of channels that will be scanned as part of an ADC operation. The current implementation only supports `1`.| -|ADC_BUFFER_DEPTH |`int` |`2` |Sets the depth of each result. Since we are only getting a 12-bit result by default, we set this to `2` bytes so we can contain our one value. This could be set to 1 if you opt for a 8-bit or lower result.| -|ADC_SAMPLING_RATE |`int` |`ADC_SMPR_SMP_1P5` |Sets the sampling rate of the ADC. By default, it is set to the fastest setting. Please consult the corresponding `hal_adc_lld.h` in ChibiOS for your specific microcontroller for further documentation on your available options.| -|ADC_RESOLUTION |`int` |`ADC_CFGR1_RES_12BIT`|The resolution of your result. We choose 12 bit by default, but you can opt for 12, 10, 8, or 6 bit. Please consult the corresponding `hal_adc_lld.h` in ChibiOS for your specific microcontroller for further documentation on your available options.| +|`#define` |Type |Default |Description | +|---------------------|------|---------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +|`ADC_CIRCULAR_BUFFER`|`bool`|`false` |If `true`, then the implementation will use a circular buffer. | +|`ADC_NUM_CHANNELS` |`int` |`1` |Sets the number of channels that will be scanned as part of an ADC operation. The current implementation only supports `1`. | +|`ADC_BUFFER_DEPTH` |`int` |`2` |Sets the depth of each result. Since we are only getting a 12-bit result by default, we set this to 2 bytes so we can contain our one value. This could be set to 1 if you opt for an 8-bit or lower result.| +|`ADC_SAMPLING_RATE` |`int` |`ADC_SMPR_SMP_1P5` |Sets the sampling rate of the ADC. By default, it is set to the fastest setting. | +|`ADC_RESOLUTION` |`int` |`ADC_CFGR1_RES_12BIT`|The resolution of your result. We choose 12 bit by default, but you can opt for 12, 10, 8, or 6 bit. | -- cgit v1.2.3 From c6b7a0d386c347f20117943831a0215659d37c47 Mon Sep 17 00:00:00 2001 From: Nick Brassel Date: Thu, 16 Jul 2020 16:39:49 +1000 Subject: Add support for DMAMUX-capable MCU configuration with WS2812 PWM driver. (#9471) --- docs/ws2812_driver.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'docs') diff --git a/docs/ws2812_driver.md b/docs/ws2812_driver.md index 941e1bde08..c1b96329e9 100644 --- a/docs/ws2812_driver.md +++ b/docs/ws2812_driver.md @@ -92,6 +92,7 @@ Configure the hardware via your config.h: #define WS2812_PWM_PAL_MODE 2 // Pin "alternate function", see the respective datasheet for the appropriate values for your MCU. default: 2 #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. ``` You must also turn on the PWM feature in your halconf.h and mcuconf.h @@ -117,5 +118,5 @@ Note: This only applies to STM32 boards. To configure the `RGB_DI_PIN` to open drain configuration add this to your config.h file: ```c - #define WS2812_EXTERNAL_PULLUP +#define WS2812_EXTERNAL_PULLUP ``` -- cgit v1.2.3 From 93e7a8f74cc2c9c7bc50b413654642a0347a55d2 Mon Sep 17 00:00:00 2001 From: Nick Brassel Date: Thu, 16 Jul 2020 16:58:14 +1000 Subject: Add dual-bank STM32 bootloader support, given GPIO toggle on BOOT0 to charge RC circuit. (#8778) --- docs/platformdev_chibios_earlyinit.md | 19 +++++++++++++++---- 1 file changed, 15 insertions(+), 4 deletions(-) (limited to 'docs') diff --git a/docs/platformdev_chibios_earlyinit.md b/docs/platformdev_chibios_earlyinit.md index 699c223771..5fd78bb336 100644 --- a/docs/platformdev_chibios_earlyinit.md +++ b/docs/platformdev_chibios_earlyinit.md @@ -4,17 +4,28 @@ This page describes a part of QMK that is a somewhat advanced concept, and is on QMK uses ChibiOS as the underlying layer to support a multitude of Arm-based devices. Each ChibiOS-supported keyboard has a low-level board definition which is responsible for initializing hardware peripherals such as the clocks, and GPIOs. -Older QMK revisions required duplication of these board definitions inside your keyboard's directory in order to override such early initialization points; this is now abstracted into the following APIs, and allows usage of the board definitions supplied with ChibiOS itself. Check `/lib/chibios/os/hal/boards` for the list of official definitions. If your keyboard needs extra initialization at a very early stage, consider providing keyboard-level overrides of the following APIs: +Older QMK revisions required duplication of these board definitions inside your keyboard's directory in order to override such early initialization points; this is now abstracted into the following APIs, and allows usage of the board definitions supplied with ChibiOS itself. Check `/lib/chibios/os/hal/boards` for the list of official definitions. If your keyboard needs extra initialization at a very early stage, consider providing keyboard-level overrides of the following APIs instead of duplicating the board definitions: ## `early_hardware_init_pre()` :id=early-hardware-init-pre The function `early_hardware_init_pre` is the earliest possible code that can be executed by a keyboard firmware. This is intended as a replacement for the ChibiOS board definition's `__early_init` function, and is the equivalent of executing at the start of the function. -This is executed before RAM gets cleared, and before clocks or GPIOs are configured; any delays or preparation using GPIOs is not likely to work at this point. After executing this function, RAM on the MCU may be zero'ed. Assigning values to variables during execution of this function may be overwritten. +This is executed before RAM gets cleared, and before clocks or GPIOs are configured; for example, ChibiOS delays are not likely to work at this point. After executing this function, RAM on the MCU may be zero'ed. Assigning values to variables during execution of this function may be overwritten. -As such, if you wish to override this API consider limiting use to writing to low-level registers. The default implementation of this function can be configured to jump to bootloader if a `RESET` key was pressed, by ensuring `#define EARLY_INIT_PERFORM_BOOTLOADER_JUMP TRUE` is in the keyboard's `config.h` file. +As such, if you wish to override this API consider limiting use to writing to low-level registers. The default implementation of this function can be configured to jump to bootloader if a `RESET` key was pressed: -To implement your own version of this function, in your keyboard's source files: +| `config.h` override | Description | Default | +|-----------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------| +| `#define EARLY_INIT_PERFORM_BOOTLOADER_JUMP` | Whether or not bootloader is to be executed during the early initialisation code of QMK. | `FALSE` | +| `#define STM32_BOOTLOADER_ADDRESS` | Relevant for single-bank STM32 MCUs, signifies the memory address to jump to bootloader. Consult [AN2606](https://www.st.com/content/st_com/en/search.html#q=an2606-t=resources-page=1) for the _System Memory_ address for your MCU. This value should be of the format `0x11111111`. | `` | +| `#define STM32_BOOTLOADER_DUAL_BANK` | Relevant for dual-bank STM32 MCUs, signifies that a GPIO is to be toggled in order to enter bootloader mode. | `FALSE` | +| `#define STM32_BOOTLOADER_DUAL_BANK_GPIO` | Relevant for dual-bank STM32 MCUs, the pin to toggle when attempting to enter bootloader mode, e.g. `B8` | `` | +| `#define STM32_BOOTLOADER_DUAL_BANK_POLARITY` | Relevant for dual-bank STM32 MCUs, the value to set the pin to in order to trigger charging of the RC circuit. e.g. `0` or `1`. | `0` | +| `#define STM32_BOOTLOADER_DUAL_BANK_DELAY` | Relevant for dual-bank STM32 MCUs, an arbitrary measurement of time to delay before resetting the MCU. Increasing number increases the delay. | `100000` | + +Kinetis MCUs have no configurable options. + +Alternatively, to implement your own version of this function, in your keyboard's source files: ```c void early_hardware_init_pre(void) { -- cgit v1.2.3 From b0335b273142ead24cb4177893fafdf2fda88810 Mon Sep 17 00:00:00 2001 From: Pete Sevander Date: Thu, 16 Jul 2020 15:39:01 +0300 Subject: Bigger combo index (#9318) * Add change log * Change combo index from uint8_t to uint16_t --- docs/ChangeLog/20200829/PR9318.md | 11 +++++++++++ 1 file changed, 11 insertions(+) create mode 100644 docs/ChangeLog/20200829/PR9318.md (limited to 'docs') diff --git a/docs/ChangeLog/20200829/PR9318.md b/docs/ChangeLog/20200829/PR9318.md new file mode 100644 index 0000000000..c238f6e449 --- /dev/null +++ b/docs/ChangeLog/20200829/PR9318.md @@ -0,0 +1,11 @@ +### Bigger integer type when looping over combos. + +[#9318](https://github.com/qmk/qmk_firmware/pull/9318) + +Changes `uint8_t` to `uint16_t` so it is possible have more than 256 combos. + +Any fork that uses `process_combo_event` needs to update the function's first argument to `uint16_t`. + +| Old function | New Function | +|---------------------------------------------------------------|----------------------------------------------------------------| +| `void process_combo_event(uint8_t combo_index, bool pressed)` | `void process_combo_event(uint16_t combo_index, bool pressed)` | -- cgit v1.2.3 From 9d3b26a47543d9898a2af2cee5f6ef53b4995e9f Mon Sep 17 00:00:00 2001 From: Drashna Jaelre Date: Fri, 24 Jul 2020 20:05:27 -0700 Subject: Update features to use Custom Tapping Term when appropriate (#6259) * Update Space Cadet to use Custom Tapping Term functionality * Detect correct keycode for space cadet tapping term * Update tap dancing to use global custom tapping term * Update documentation for Tap Dances * formatting pass * Apply suggestions from code review Co-Authored-By: fauxpark * Update docs/feature_tap_dance.md Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com> * Update for future * Update user keymaps for space cadet * Fix typos * Clean up tapping term stuff * Fix compiler issue if NO_ACTION_TAPPING is enabled Co-authored-by: fauxpark Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com> --- docs/feature_tap_dance.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'docs') diff --git a/docs/feature_tap_dance.md b/docs/feature_tap_dance.md index 877c37336e..d2da39ad2b 100644 --- a/docs/feature_tap_dance.md +++ b/docs/feature_tap_dance.md @@ -28,7 +28,9 @@ After this, you'll want to use the `tap_dance_actions` array to specify what act * `ACTION_TAP_DANCE_LAYER_TOGGLE(kc, layer)`: Sends the `kc` keycode when tapped once, or toggles the state of `layer`. (this functions like the `TG` layer keycode). * `ACTION_TAP_DANCE_FN(fn)`: Calls the specified function - defined in the user keymap - with the final tap count of the tap dance action. * `ACTION_TAP_DANCE_FN_ADVANCED(on_each_tap_fn, on_dance_finished_fn, on_dance_reset_fn)`: Calls the first specified function - defined in the user keymap - on every tap, the second function when the dance action finishes (like the previous option), and the last function when the tap dance action resets. -* `ACTION_TAP_DANCE_FN_ADVANCED_TIME(on_each_tap_fn, on_dance_finished_fn, on_dance_reset_fn, tap_specific_tapping_term)`: This functions identically to the `ACTION_TAP_DANCE_FN_ADVANCED` function, but uses a custom tapping term for it, instead of the predefined `TAPPING_TERM`. +* ~~`ACTION_TAP_DANCE_FN_ADVANCED_TIME(on_each_tap_fn, on_dance_finished_fn, on_dance_reset_fn, tap_specific_tapping_term)`~~: This functions identically to the `ACTION_TAP_DANCE_FN_ADVANCED` function, but uses a custom tapping term for it, instead of the predefined `TAPPING_TERM`. + * This is deprecated in favor of the Per Key Tapping Term functionality, as outlined [here](custom_quantum_functions.md#Custom_Tapping_Term). You'd want to check for the specific `TD()` macro that you want to use (such as `TD(TD_ESC_CAPS)`) instead of using this specific Tap Dance function. + The first option is enough for a lot of cases, that just want dual roles. For example, `ACTION_TAP_DANCE_DOUBLE(KC_SPC, KC_ENT)` will result in `Space` being sent on single-tap, `Enter` otherwise. -- cgit v1.2.3 From d4be07dad368c57669c88ead6c093c9e23086855 Mon Sep 17 00:00:00 2001 From: a-chol Date: Sat, 25 Jul 2020 14:01:15 +0200 Subject: Hid joystick interface (#4226) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * add support for hid gamepad interface add documentation for HID joystick Add joystick_task to read analog axes values even when no key is pressed or release. update doc Update docs/feature_joystick.md Manage pin setup and read to maintain matrix scan after analog read * Incorporates patches and changes to HID reporting There are some patches provided by @a-chol incorporated on this commit, and also some changes I made to the HID Report structure. The most interesting is the one dealing with number of buttons: Linux doesn't seem to care, but Windows requires the HID structure to be byte aligned (that's in the spec). So if one declares 8/16/32... buttons they should not have any issues, but this is what happens when you have 9 buttons: ``` bits |0|1|2|3|4|5|6|7| |*|*|*|*|*|*|*|*| axis 0 (report size 8) |*|*|*|*|*|*|*|*| ... |*|*|*|*|*|*|*|*| |*|*|*|*|*|*|*|*| |*|*|*|*|*|*|*|*| |*|*|*|*|*|*|*|*| |*|*|*|*|*|*|*|*| axis 6 |*|*|*|*|*|*|*|*| first 8 buttons (report size 1) |*| | | | | | | | last of 9 buttons, not aligned ``` So for that I added a conditonal that will add a number of reports with size 1 to make sure it aligns to the next multiple of 8. Those reports send dummy inputs that don't do anything aside from aligning the data. Tested on Linux, Windows 10 and Street Fighter (where the joystick is recognized as direct-input) * Add save and restore of each pin used in reading joystick (AVR). Allow output pin to be JS_VIRTUAL_AXIS if the axis is connected to Vcc instead of an output pin from the MCU. Fix joystick report id Fix broken v-usb hid joystick interface. Make it more resilient to unusual settings (none multiple of eight button count, 0 buttons or 0 axes) Correct adc reading for multiple axes. Piecewise range conversion for uncentered raw value range. Input, output and ground pin configuration per axis. Documentation fixes * Fix port addressing for joystick analog read * The other required set of changes As per the PR, the changes still holding it up. Add onekey for testing. Fix ARM builds. Fix device descriptor when either axes or buttons is zero. Add compile-time check for at least one axis or button. Move definition to try to fix conflict. PR review comments. qmk cformat * avoid float functions to compute range mapping for axis adc reading * Remove V-USB support for now. Updated docs accordingly. * Update tmk_core/protocol/lufa/lufa.c Co-Authored-By: Ryan * Update tmk_core/protocol/usb_descriptor.c Co-Authored-By: Ryan * Update tmk_core/protocol/usb_descriptor.c Co-Authored-By: Ryan * Update tmk_core/protocol/usb_descriptor.c Co-Authored-By: Ryan * Add support for joystick adc reading for stm32 MCUs. Fix joystick hid report sending for chibios * Fix HID joystick report sending for ChibiOS. Add one analog axis to the onekey:joystick keymap. Fix pin state save and restore during joystick analog read for STM32 MCUs. * Update tmk_core/protocol/chibios/usb_main.c Co-Authored-By: Ryan * Update tmk_core/protocol/lufa/lufa.c Co-Authored-By: Ryan * Add missing mcuconf.h and halconf.h to onekey:joystick keymap. Add suggested fixes from PR. * Switch saveState and restoreState signature to use pin_t type. onekey:joystick : add a second axis, virtual and programmatically animated. * Update docs/feature_joystick.md Co-Authored-By: Ryan * Update docs/feature_joystick.md Co-Authored-By: Ryan * Add PR corrections * Remove halconf.h and mcuconf.h from onekey keymaps * Change ADC_PIN to A0 Co-authored-by: achol Co-authored-by: José Júnior Co-authored-by: a-chol Co-authored-by: Nick Brassel Co-authored-by: Ryan --- docs/_summary.md | 1 + docs/feature_joystick.md | 145 +++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 146 insertions(+) create mode 100644 docs/feature_joystick.md (limited to 'docs') diff --git a/docs/_summary.md b/docs/_summary.md index 9ed55a3d06..0c43712159 100644 --- a/docs/_summary.md +++ b/docs/_summary.md @@ -103,6 +103,7 @@ * [DIP Switch](feature_dip_switch.md) * [Encoders](feature_encoders.md) * [Haptic Feedback](feature_haptic_feedback.md) + * [Joystick](feature_joystick.md) * [Proton C Conversion](proton_c_conversion.md) * [PS/2 Mouse](feature_ps2_mouse.md) * [Split Keyboard](feature_split_keyboard.md) diff --git a/docs/feature_joystick.md b/docs/feature_joystick.md new file mode 100644 index 0000000000..58dfc7b8df --- /dev/null +++ b/docs/feature_joystick.md @@ -0,0 +1,145 @@ +## Joystick + +The keyboard can be made to be recognized as a joystick HID device by the operating system. + +This is enabled by adding the following to `rules.mk`: + +```makefile +JOYSTICK_ENABLE = yes +``` + +!> Joystick support is not currently available on V-USB devices. + +The joystick feature provides two services: + * reading analog input devices (eg. potentiometers) + * sending gamepad HID reports + +Both services can be used without the other, depending on whether you just want to read a device but not send gamepad reports (for volume control for instance) +or send gamepad reports based on values computed by the keyboard. + +### Analog Input + +An analog device such as a potentiometer found on a gamepad's analog axes is based on a [voltage divider](https://en.wikipedia.org/wiki/Voltage_divider). +It is composed of three connectors linked to the ground, the power input and power output (usually the middle one). The power output holds the voltage that varies based on the position of the cursor, +which value will be read using your MCU's [ADC](https://en.wikipedia.org/wiki/Analog-to-digital_converter). +Depending on which pins are already used by your keyboard's matrix, the rest of the circuit can get a little bit more complicated, +feeding the power input and ground connection through pins and using diodes to avoid bad interactions with the matrix scanning procedures. + +### Configuring the Joystick + +By default, two axes and eight buttons are defined. This can be changed in your `config.h`: + +```c +// Max 32 +#define JOYSTICK_BUTTON_COUNT 16 +// Max 6: X, Y, Z, Rx, Ry, Rz +#define JOYSTICK_AXES_COUNT 3 +``` + +When defining axes for your joystick, you have to provide a definition array. You can do this from your keymap.c file. +A joystick will either be read from an input pin that allows the use of the ADC, or can be virtual, so that its value is provided by your code. +You have to define an array of type ''joystick_config_t'' and of proper size. + +There are three ways for your circuit to work with the ADC, that relies on the use of 1, 2 or 3 pins of the MCU: + * 1 pin: your analog device is directly connected to your device GND and VCC. The only pin used is the ADC pin of your choice. + * 2 pins: your analog device is powered through a pin that allows toggling it on or off. The other pin is used to read the input value through the ADC. + * 3 pins: both the power input and ground are connected to pins that must be set to a proper state before reading and restored afterwards. + +The configuration of each axis is performed using one of four macros: + * `JOYSTICK_AXIS_VIRTUAL`: no ADC reading must be performed, that value will be provided by keyboard/keymap-level code + * `JOYSTICK_AXIS_IN(INPUT_PIN, LOW, REST, HIGH)`: a voltage will be read on the provided pin, which must be an ADC-capable pin. + * `JOYSTICK_AXIS_IN_OUT(INPUT_PIN, OUTPUT_PIN, LOW, REST, HIGH)`: the provided `OUTPUT_PIN` will be set high before `INPUT_PIN` is read. + * `JOYSTICK_AXIS_IN_OUT_GROUND(INPUT_PIN, OUTPUT_PIN, GROUND_PIN, LOW, REST, HIGH)`: the `OUTPUT_PIN` will be set high and `GROUND_PIN` will be set low before reading from `INPUT_PIN`. + +In any case where an ADC reading takes place (when `INPUT_PIN` is provided), additional `LOW`, `REST` and `HIGH` parameters are used. +These implement the calibration of the analog device by defining the range of read values that will be mapped to the lowest, resting position and highest possible value for the axis (-127 to 127). +In practice, you have to provide the lowest/highest raw ADC reading, and the raw reading at resting position, when no deflection is applied. You can provide inverted `LOW` and `HIGH` to invert the axis. + +For instance, an axes configuration can be defined in the following way: + +```c +//joystick config +joystick_config_t joystick_axes[JOYSTICK_AXES_COUNT] = { + [0] = JOYSTICK_AXIS_IN_OUT_GROUND(A4, B0, A7, 900, 575, 285), + [1] = JOYSTICK_AXIS_VIRTUAL +}; +``` + +When the ADC reads 900 or higher, the returned axis value will be -127, whereas it will be 127 when the ADC reads 285 or lower. Zero is returned when 575 is read. + +In this example, the first axis will be read from the `A4` pin while `B0` is set high and `A7` is set low, using `analogReadPin()`, whereas the second axis will not be read. + +In order to give a value to the second axis, you can do so in any customizable entry point: as an action, in `process_record_user()` or in `matrix_scan_user()`, or even in `joystick_task()` which is called even when no key has been pressed. +You assign a value by writing to `joystick_status.axes[axis_index]` a signed 8-bit value (ranging from -127 to 127). Then it is necessary to assign the flag `JS_UPDATED` to `joystick_status.status` in order for an updated HID report to be sent. + +The following example writes two axes based on keypad presses, with `KC_P5` as a precision modifier: + +```c +#ifdef JOYSTICK_ENABLE +static uint8_t precision_val = 70; +static uint8_t axesFlags = 0; +enum axes { + Precision = 1, + Axis1High = 2, + Axis1Low = 4, + Axis2High = 8, + Axis2Low = 16 +}; +#endif + +bool process_record_user(uint16_t keycode, keyrecord_t *record) { + switch(keycode) { +#ifdef JOYSTICK_ENABLE + // virtual joystick +# if JOYSTICK_AXES_COUNT > 1 + case KC_P8: + if (record->event.pressed) { + axesFlags |= Axis2Low; + } else { + axesFlags &= ~Axis2Low; + } + joystick_status.status |= JS_UPDATED; + break; + case KC_P2: + if (record->event.pressed) { + axesFlags |= Axis2High; + } else { + axesFlags &= ~Axis2High; + } + joystick_status.status |= JS_UPDATED; + break; +# endif + case KC_P4: + if (record->event.pressed) { + axesFlags |= Axis1Low; + } else { + axesFlags &= ~Axis1Low; + } + joystick_status.status |= JS_UPDATED; + break; + case KC_P6: + if (record->event.pressed) { + axesFlags |= Axis1High; + } else { + axesFlags &= ~Axis1High; + } + joystick_status.status |= JS_UPDATED; + break; + case KC_P5: + if (record->event.pressed) { + axesFlags |= Precision; + } else { + axesFlags &= ~Precision; + } + joystick_status.status |= JS_UPDATED; + break; +#endif + } + return true; +} +``` + +### Triggering Joystick Buttons + +Joystick buttons are normal Quantum keycodes, defined as `JS_BUTTON0` to `JS_BUTTON31`, depending on the number of buttons you have configured. +To trigger a joystick button, just add the corresponding keycode to your keymap. -- cgit v1.2.3 From 4b74f985ec7b14f5517df4e591f0c36b24f85f5c Mon Sep 17 00:00:00 2001 From: Max Rumpf Date: Sun, 26 Jul 2020 01:00:33 +0200 Subject: Tweak the Christmas animation effect to be less harsh on the eyes (#7648) * Tweak the Christmas animation effect to be less harsh on the eyes * Further improve the tweaked Christmas animation code - Use constants where it makes sense - Instead of complicated math, use a static variable to keep track if it's animating from or to red - Don't use pow (but a simple macro instead) - Using floating point math is necessary for the fraction in the cubic bezier function to work * Update docs for the tweaked Christmas animation effect * Further improve memory usage - Don't use floats, but 32 bit ints instead (where needed) - Replace limits.h with constant * Fix typo --- docs/feature_rgblight.md | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) (limited to 'docs') diff --git a/docs/feature_rgblight.md b/docs/feature_rgblight.md index 26e01da501..23b2886edb 100644 --- a/docs/feature_rgblight.md +++ b/docs/feature_rgblight.md @@ -126,19 +126,19 @@ Use these defines to add or remove animations from the firmware. When you are ru The following options are used to tweak the various animations: -|Define |Default |Description | -|------------------------------------|-------------|-------------------------------------------------------------------------------------| +|Define |Default |Description | +|------------------------------------|-------------|-----------------------------------------------------------------------------------------------| |`RGBLIGHT_EFFECT_BREATHE_CENTER` |*Not defined*|If defined, used to calculate the curve for the breathing animation. Valid values are 1.0 to 2.7 | -|`RGBLIGHT_EFFECT_BREATHE_MAX` |`255` |The maximum brightness for the breathing mode. Valid values are 1 to 255 | -|`RGBLIGHT_EFFECT_CHRISTMAS_INTERVAL`|`1000` |How long to wait between light changes for the "Christmas" animation, in milliseconds| -|`RGBLIGHT_EFFECT_CHRISTMAS_STEP` |`2` |The number of LEDs to group the red/green colors by for the "Christmas" animation | -|`RGBLIGHT_EFFECT_KNIGHT_LED_NUM` |`RGBLED_NUM` |The number of LEDs to have the "Knight" animation travel | -|`RGBLIGHT_EFFECT_KNIGHT_LENGTH` |`3` |The number of LEDs to light up for the "Knight" animation | -|`RGBLIGHT_EFFECT_KNIGHT_OFFSET` |`0` |The number of LEDs to start the "Knight" animation from the start of the strip by | -|`RGBLIGHT_RAINBOW_SWIRL_RANGE` |`255` |Range adjustment for the rainbow swirl effect to get different swirls | -|`RGBLIGHT_EFFECT_SNAKE_LENGTH` |`4` |The number of LEDs to light up for the "Snake" animation | -|`RGBLIGHT_EFFECT_TWINKLE_LIFE` |`75` |Adjusts how quickly each LED brightens and dims when twinkling (in animation steps) | -|`RGBLIGHT_EFFECT_TWINKLE_PROBABILITY`|`1/127` |Adjusts how likely each LED is to twinkle (on each animation step) | +|`RGBLIGHT_EFFECT_BREATHE_MAX` |`255` |The maximum brightness for the breathing mode. Valid values are 1 to 255 | +|`RGBLIGHT_EFFECT_CHRISTMAS_INTERVAL`|`40` |How long (in milliseconds) to wait between animation steps for the "Christmas" animation | +|`RGBLIGHT_EFFECT_CHRISTMAS_STEP` |`2` |The number of LEDs to group the red/green colors by for the "Christmas" animation | +|`RGBLIGHT_EFFECT_KNIGHT_LED_NUM` |`RGBLED_NUM` |The number of LEDs to have the "Knight" animation travel | +|`RGBLIGHT_EFFECT_KNIGHT_LENGTH` |`3` |The number of LEDs to light up for the "Knight" animation | +|`RGBLIGHT_EFFECT_KNIGHT_OFFSET` |`0` |The number of LEDs to start the "Knight" animation from the start of the strip by | +|`RGBLIGHT_RAINBOW_SWIRL_RANGE` |`255` |Range adjustment for the rainbow swirl effect to get different swirls | +|`RGBLIGHT_EFFECT_SNAKE_LENGTH` |`4` |The number of LEDs to light up for the "Snake" animation | +|`RGBLIGHT_EFFECT_TWINKLE_LIFE` |`75` |Adjusts how quickly each LED brightens and dims when twinkling (in animation steps) | +|`RGBLIGHT_EFFECT_TWINKLE_PROBABILITY`|`1/127` |Adjusts how likely each LED is to twinkle (on each animation step) | ### Example Usage to Reduce Memory Footprint 1. Remove `RGBLIGHT_ANIMATIONS` from `config.h`. -- cgit v1.2.3 From e34eca361fdd9ff61b8827fec545202da179648c Mon Sep 17 00:00:00 2001 From: Tynan Beatty <38031130+tynanbe@users.noreply.github.com> Date: Fri, 7 Aug 2020 16:43:57 -0500 Subject: Noeeprom functions for rgb_matrix (#9487) * Add eeprom_helpers for toggle, mode, sethsv, speed; add set_speed; add noeeprom versions of toggle, step, hue, sat, val, and speed * qmk cformat rgb_matrix * Add rgb_matrix_set_speed and *_noeeprom functions * Do not expose rgb_matrix_*_eeprom_helper functions --- docs/feature_rgb_matrix.md | 20 ++++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-) (limited to 'docs') diff --git a/docs/feature_rgb_matrix.md b/docs/feature_rgb_matrix.md index 2cde3ec569..a8fad59a19 100644 --- a/docs/feature_rgb_matrix.md +++ b/docs/feature_rgb_matrix.md @@ -422,8 +422,8 @@ Where `28` is an unused index from `eeconfig.h`. |`rgb_matrix_toggle_noeeprom()` |Toggle effect range LEDs between on and off (not written to EEPROM) | |`rgb_matrix_enable()` |Turn effect range LEDs on, based on their previous state | |`rgb_matrix_enable_noeeprom()` |Turn effect range LEDs on, based on their previous state (not written to EEPROM) | -|`rgb_matrix_disable()` |Turn effect range LEDs off | -|`rgb_matrix_disable_noeeprom()` |Turn effect range LEDs off (not written to EEPROM) | +|`rgb_matrix_disable()` |Turn effect range LEDs off, based on their previous state | +|`rgb_matrix_disable_noeeprom()` |Turn effect range LEDs off, based on their previous state (not written to EEPROM) | ### Change Effect Mode :id=change-effect-mode |Function |Description | @@ -431,19 +431,31 @@ Where `28` is an unused index from `eeconfig.h`. |`rgb_matrix_mode(mode)` |Set the mode, if RGB animations are enabled | |`rgb_matrix_mode_noeeprom(mode)` |Set the mode, if RGB animations are enabled (not written to EEPROM) | |`rgb_matrix_step()` |Change the mode to the next RGB animation in the list of enabled RGB animations | +|`rgb_matrix_step_noeeprom()` |Change the mode to the next RGB animation in the list of enabled RGB animations (not written to EEPROM) | |`rgb_matrix_step_reverse()` |Change the mode to the previous RGB animation in the list of enabled RGB animations | -|`rgb_matrix_increase_speed()` |Increases the speed of the animations | -|`rgb_matrix_decrease_speed()` |Decreases the speed of the animations | +|`rgb_matrix_step_reverse_noeeprom()` |Change the mode to the previous RGB animation in the list of enabled RGB animations (not written to EEPROM) | +|`rgb_matrix_increase_speed()` |Increase the speed of the animations | +|`rgb_matrix_increase_speed_noeeprom()` |Increase the speed of the animations (not written to EEPROM) | +|`rgb_matrix_decrease_speed()` |Decrease the speed of the animations | +|`rgb_matrix_decrease_speed_noeeprom()` |Decrease the speed of the animations (not written to EEPROM) | +|`rgb_matrix_set_speed(speed)` |Set the speed of the animations to the given value where `speed` is between 0 and 255 | +|`rgb_matrix_set_speed_noeeprom(speed)` |Set the speed of the animations to the given value where `speed` is between 0 and 255 (not written to EEPROM) | ### Change Color :id=change-color |Function |Description | |--------------------------------------------|-------------| |`rgb_matrix_increase_hue()` |Increase the hue for effect range LEDs. This wraps around at maximum hue | +|`rgb_matrix_increase_hue_noeeprom()` |Increase the hue for effect range LEDs. This wraps around at maximum hue (not written to EEPROM) | |`rgb_matrix_decrease_hue()` |Decrease the hue for effect range LEDs. This wraps around at minimum hue | +|`rgb_matrix_decrease_hue_noeeprom()` |Decrease the hue for effect range LEDs. This wraps around at minimum hue (not written to EEPROM) | |`rgb_matrix_increase_sat()` |Increase the saturation for effect range LEDs. This wraps around at maximum saturation | +|`rgb_matrix_increase_sat_noeeprom()` |Increase the saturation for effect range LEDs. This wraps around at maximum saturation (not written to EEPROM) | |`rgb_matrix_decrease_sat()` |Decrease the saturation for effect range LEDs. This wraps around at minimum saturation | +|`rgb_matrix_decrease_sat_noeeprom()` |Decrease the saturation for effect range LEDs. This wraps around at minimum saturation (not written to EEPROM) | |`rgb_matrix_increase_val()` |Increase the value for effect range LEDs. This wraps around at maximum value | +|`rgb_matrix_increase_val_noeeprom()` |Increase the value for effect range LEDs. This wraps around at maximum value (not written to EEPROM) | |`rgb_matrix_decrease_val()` |Decrease the value for effect range LEDs. This wraps around at minimum value | +|`rgb_matrix_decrease_val_noeeprom()` |Decrease the value for effect range LEDs. This wraps around at minimum value (not written to EEPROM) | |`rgb_matrix_sethsv(h, s, v)` |Set LEDs to the given HSV value where `h`/`s`/`v` are between 0 and 255 | |`rgb_matrix_sethsv_noeeprom(h, s, v)` |Set LEDs to the given HSV value where `h`/`s`/`v` are between 0 and 255 (not written to EEPROM) | -- cgit v1.2.3 From d00ac5dfb6388957d51f2666d8bd223bd3529151 Mon Sep 17 00:00:00 2001 From: Sergey Vlasov Date: Wed, 12 Aug 2020 18:53:53 +0300 Subject: Add `st-flash` flash target (#9964) * Add `st-flash` flash target Add support for flashing the firmware via the `st-flash` utility from the STLink Tools package (https://github.com/stlink-org/stlink). * Add `st-flash` to the `qmk flash -b` output --- docs/flashing.md | 1 + 1 file changed, 1 insertion(+) (limited to 'docs') diff --git a/docs/flashing.md b/docs/flashing.md index 1f71c253c3..5c245c5675 100644 --- a/docs/flashing.md +++ b/docs/flashing.md @@ -239,3 +239,4 @@ There are a number of DFU commands that you can use to flash firmware to a STM32 * `:dfu-util-split-left` - This flashes the normal firmware, just like the default option (`:dfu-util`). However, this also configures the "Left Side" EEPROM setting for split keyboards. * `:dfu-util-split-right` - This flashes the normal firmware, just like the default option (`:dfu-util`). However, this also configures the "Right Side" EEPROM setting for split keyboards. * `:st-link-cli` - This allows you to flash the firmware via ST-LINK's CLI utility, rather than dfu-util. +* `:st-flash` - This allows you to flash the firmware via the `st-flash` utility from [STLink Tools](https://github.com/stlink-org/stlink), rather than dfu-util. -- cgit v1.2.3 From 568cae28ec41acc84a4a60bc3e20120e33ebee89 Mon Sep 17 00:00:00 2001 From: Greg Wright Date: Sat, 15 Aug 2020 16:55:13 -0400 Subject: #define AUTO_SHIFT_SETUP (#8441) * #define AUTO_SHIFT_SETUP * Clarification Changed `#ifndef` to `#ifdef` and moved enable disable outside AUTO_SHIFT_SETUP * AUTO_SHIFT_NO_SETUp --- docs/feature_auto_shift.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'docs') diff --git a/docs/feature_auto_shift.md b/docs/feature_auto_shift.md index f0b507bc61..b21a7690d9 100644 --- a/docs/feature_auto_shift.md +++ b/docs/feature_auto_shift.md @@ -139,7 +139,7 @@ completely normal and with no intention of shifted keys. `KC_ASRP`. The keyboard will type by itself the value of your `AUTO_SHIFT_TIMEOUT`. 7. Update `AUTO_SHIFT_TIMEOUT` in your `config.h` with the value reported. -8. Remove `AUTO_SHIFT_SETUP` from your `config.h`. +8. Add `AUTO_SHIFT_NO_SETUP` to your `config.h`. 9. Remove the key bindings `KC_ASDN`, `KC_ASUP` and `KC_ASRP`. 10. Compile and upload your new firmware. -- cgit v1.2.3 From 15b5ff1dc229703c86053ada87f6511a4efbded9 Mon Sep 17 00:00:00 2001 From: Joel Challis Date: Sun, 16 Aug 2020 11:13:45 +0100 Subject: Remove f072 backlight warning (#10040) * Remove f072 backlight warning * Remove f072 backlight warning from docs --- docs/feature_backlight.md | 2 -- 1 file changed, 2 deletions(-) (limited to 'docs') diff --git a/docs/feature_backlight.md b/docs/feature_backlight.md index 9e467c708a..6bb2bbed84 100644 --- a/docs/feature_backlight.md +++ b/docs/feature_backlight.md @@ -160,8 +160,6 @@ See the ST datasheet for your particular MCU to determine these values. Unless y Currently only hardware PWM is supported, not timer assisted, and does not provide automatic configuration. -?> Backlight support for STM32F072 has had limited testing, so YMMV. If unsure, set `BACKLIGHT_ENABLE = no` in your `rules.mk`. - ### Software PWM Driver :id=software-pwm-driver In this mode, PWM is "emulated" while running other keyboard tasks. It offers maximum hardware compatibility without extra platform configuration. The tradeoff is the backlight might jitter when the keyboard is busy. To enable, add this to your `rules.mk`: -- cgit v1.2.3 From 92385b3fb617326b129609726020453c8949c7f8 Mon Sep 17 00:00:00 2001 From: Drashna Jaelre Date: Sat, 22 Aug 2020 01:21:06 -0700 Subject: Better handle LTO_ENABLE (#9832) * Better handle LTO_ENABLE Especially when calling from command line * Replace LINK_TIME_OPTIMIZATION_ENABLE with LTO_ENABLE * Remove long for LTO from show_options.mk --- docs/config_options.md | 4 +--- docs/ja/config_options.md | 4 +--- 2 files changed, 2 insertions(+), 6 deletions(-) (limited to 'docs') diff --git a/docs/config_options.md b/docs/config_options.md index 81a3b4b61c..a323741c2a 100644 --- a/docs/config_options.md +++ b/docs/config_options.md @@ -324,11 +324,9 @@ This is a [make](https://www.gnu.org/software/make/manual/make.html) file that i ``` * `LAYOUTS` * A list of [layouts](feature_layouts.md) this keyboard supports. -* `LINK_TIME_OPTIMIZATION_ENABLE` +* `LTO_ENABLE` * Enables Link Time Optimization (LTO) when compiling the keyboard. This makes the process take longer, but it can significantly reduce the compiled size (and since the firmware is small, the added time is not noticeable). However, this will automatically disable the legacy TMK Macros and Functions features, as these break when LTO is enabled. It does this by automatically defining `NO_ACTION_MACRO` and `NO_ACTION_FUNCTION`. (Note: This does not affect QMK [Macros](feature_macros.md) and [Layers](feature_layers.md).) -* `LTO_ENABLE` - * Has the same meaning as `LINK_TIME_OPTIMIZATION_ENABLE`. You can use `LTO_ENABLE` instead of `LINK_TIME_OPTIMIZATION_ENABLE`. ## AVR MCU Options * `MCU = atmega32u4` diff --git a/docs/ja/config_options.md b/docs/ja/config_options.md index b4cf3c888c..6ba7f6f1f3 100644 --- a/docs/ja/config_options.md +++ b/docs/ja/config_options.md @@ -322,11 +322,9 @@ QMK での全ての利用可能な設定にはデフォルトがあります。 ``` * `LAYOUTS` * このキーボードがサポートする[レイアウト](ja/feature_layouts.md)のリスト -* `LINK_TIME_OPTIMIZATION_ENABLE` +* `LTO_ENABLE` * キーボードをコンパイルする時に、Link Time Optimization (LTO) を有効にします。これは処理に時間が掛かりますが、コンパイルされたサイズを大幅に減らします (そして、ファームウェアが小さいため、追加の時間は分からないくらいです)。 ただし、LTO が有効な場合、古い TMK のマクロと関数の機能が壊れるため、自動的にこれらの機能を無効にします。これは `NO_ACTION_MACRO` と `NO_ACTION_FUNCTION` を自動的に定義することで行われます。(メモ: これは QMK の [マクロ](ja/feature_macros.md) と [レイヤー](ja/feature_layers.md) には影響を与えません。) -* `LTO_ENABLE` - * LINK_TIME_OPTIMIZATION_ENABLE と同じ意味です。`LINK_TIME_OPTIMIZATION_ENABLE` の代わりに `LTO_ENABLE` を使うことができます。 ## AVR MCU オプション * `MCU = atmega32u4` -- cgit v1.2.3 From fa6cf8572736f16d2fe076c21546d08f258e145f Mon Sep 17 00:00:00 2001 From: Richard Date: Mon, 24 Aug 2020 07:40:45 -0700 Subject: Add a method to read the OLED display buffer from user space (#8777) * Adding extern and declaration * Change to mediated buffer read * Adding raw byte read * Restore write raw... D'Oh * Working struct return * Pack that struct * Remove conditional packing and add example to docs * Cleanup tab/spaces * Update docs/feature_oled_driver.md Prettify formatting * Update drivers/oled/oled_driver.h Prettify formatting --- docs/feature_oled_driver.md | 41 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 41 insertions(+) (limited to 'docs') diff --git a/docs/feature_oled_driver.md b/docs/feature_oled_driver.md index 5f3095198f..d106d3d13e 100644 --- a/docs/feature_oled_driver.md +++ b/docs/feature_oled_driver.md @@ -72,6 +72,43 @@ static void render_logo(void) { } ``` +## Buffer Read Example +For some purposes, you may need to read the current state of the OLED display +buffer. The `oled_read_raw` function can be used to safely read bytes from the +buffer. + +In this example, calling `fade_display` in the `oled_task_user` function will +slowly fade away whatever is on the screen by turning random pixels black over +time. +```c +//Setup some mask which can be or'd with bytes to turn off pixels +const uint8_t single_bit_masks[8] = {127, 191, 223, 239, 247, 251, 253, 254}; + +static void fade_display(void) { + //Define the reader structure + oled_buffer_reader_t reader; + uint8_t buff_char; + if (random() % 30 == 0) { + srand(timer_read()); + // Fetch a pointer for the buffer byte at index 0. The return structure + // will have the pointer and the number of bytes remaining from this + // index position if we want to perform a sequential read by + // incrementing the buffer pointer + reader = oled_read_raw(0); + //Loop over the remaining buffer and erase pixels as we go + for (uint16_t i = 0; i < reader.remaining_element_count; i++) { + //Get the actual byte in the buffer by dereferencing the pointer + buff_char = *reader.current_element; + if (buff_char != 0) { + oled_write_raw_byte(buff_char & single_bit_masks[rand() % 8], i); + } + //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 OLED displays that each render different content and are oriented or flipped differently. You can do this by switching which content to render by using the return value from `is_keyboard_master()` or `is_keyboard_left()` found in `split_util.h`, e.g: @@ -238,6 +275,10 @@ void oled_write_P(const char *data, bool invert); // Remapped to call 'void oled_write_ln(const char *data, bool invert);' on ARM void oled_write_ln_P(const char *data, bool invert); +// Returns a pointer to the requested start index in the buffer plus remaining +// buffer length as struct +oled_buffer_reader_t oled_read_raw(uint16_t start_index); + // Writes a string to the buffer at current cursor position void oled_write_raw(const char *data, uint16_t size); -- cgit v1.2.3 From 0f596881b36587a298568192078f9b467c51c109 Mon Sep 17 00:00:00 2001 From: Ryan Date: Tue, 25 Aug 2020 19:03:45 +1000 Subject: Remove support for Adafruit EZ-Key (#10103) * Remove support for Adafruit EZ-Key * Update docs/ja/feature_bluetooth.md Co-authored-by: Takeshi ISHII <2170248+mtei@users.noreply.github.com> Co-authored-by: Takeshi ISHII <2170248+mtei@users.noreply.github.com> --- docs/config_options.md | 4 +--- docs/feature_bluetooth.md | 7 +------ docs/getting_started_make_guide.md | 4 ---- docs/ja/config_options.md | 4 +--- docs/ja/feature_bluetooth.md | 8 +------- docs/ja/getting_started_make_guide.md | 4 ---- 6 files changed, 4 insertions(+), 27 deletions(-) (limited to 'docs') diff --git a/docs/config_options.md b/docs/config_options.md index a323741c2a..f9b1cc6578 100644 --- a/docs/config_options.md +++ b/docs/config_options.md @@ -371,10 +371,8 @@ Use these to enable or disable building certain features. The more you have enab * MIDI controls * `UNICODE_ENABLE` * Unicode -* `BLUETOOTH_ENABLE` - * Legacy option to Enable Bluetooth with the Adafruit EZ-Key HID. See BLUETOOTH * `BLUETOOTH` - * Current options are AdafruitEzKey, AdafruitBLE, RN42 + * Current options are AdafruitBLE, RN42 * `SPLIT_KEYBOARD` * Enables split keyboard support (dual MCU like the let's split and bakingpy's boards) and includes all necessary files located at quantum/split_common * `CUSTOM_MATRIX` diff --git a/docs/feature_bluetooth.md b/docs/feature_bluetooth.md index 6cd5c3c6cf..7b450b1ac8 100644 --- a/docs/feature_bluetooth.md +++ b/docs/feature_bluetooth.md @@ -2,11 +2,10 @@ ## Bluetooth Known Supported Hardware -Currently Bluetooth support is limited to AVR based chips. For Bluetooth 2.1, QMK has support for RN-42 modules and the Bluefruit EZ-Key, the latter of which is not produced anymore. For more recent BLE protocols, currently only the Adafruit Bluefruit SPI Friend is directly supported. BLE is needed to connect to iOS devices. Note iOS does not support mouse input. +Currently Bluetooth support is limited to AVR based chips. For Bluetooth 2.1, QMK has support for RN-42 modules. For more recent BLE protocols, currently only the Adafruit Bluefruit SPI Friend is directly supported. BLE is needed to connect to iOS devices. Note iOS does not support mouse input. |Board |Bluetooth Protocol |Connection Type |rules.mk |Bluetooth Chip| |----------------------------------------------------------------|----------------------------|----------------|---------------------------|--------------| -|[Adafruit EZ-Key HID](https://www.adafruit.com/product/1535) |Bluetooth Classic | UART |`BLUETOOTH = AdafruitEZKey` | | |Roving Networks RN-42 (Sparkfun Bluesmirf) |Bluetooth Classic | UART |`BLUETOOTH = RN42` | RN-42 | |[Bluefruit LE SPI Friend](https://www.adafruit.com/product/2633)|Bluetooth Low Energy | SPI |`BLUETOOTH = AdafruitBLE` | nRF51822 | @@ -24,16 +23,12 @@ Currently The only bluetooth chipset supported by QMK is the Adafruit Bluefruit A Bluefruit UART friend can be converted to an SPI friend, however this [requires](https://github.com/qmk/qmk_firmware/issues/2274) some reflashing and soldering directly to the MDBT40 chip. -## Adafruit EZ-Key hid -This requires [some hardware changes](https://www.reddit.com/r/MechanicalKeyboards/comments/3psx0q/the_planck_keyboard_with_bluetooth_guide_and/?ref=search_posts), but can be enabled via the Makefile. The firmware will still output characters via USB, so be aware of this when charging via a computer. It would make sense to have a switch on the Bluefruit to turn it off at will. - ## Bluetooth Rules.mk Options Use only one of these * BLUETOOTH_ENABLE = yes (Legacy Option) * BLUETOOTH = RN42 -* BLUETOOTH = AdafruitEZKey * BLUETOOTH = AdafruitBLE ## Bluetooth Keycodes diff --git a/docs/getting_started_make_guide.md b/docs/getting_started_make_guide.md index df82a001f0..a89dc73d01 100644 --- a/docs/getting_started_make_guide.md +++ b/docs/getting_started_make_guide.md @@ -101,10 +101,6 @@ This allows you to send Unicode characters by inputting a mnemonic corresponding For further details, as well as limitations, see the [Unicode page](feature_unicode.md). -`BLUETOOTH_ENABLE` - -This allows you to interface with a Bluefruit EZ-key to send keycodes wirelessly. It uses the D2 and D3 pins. - `AUDIO_ENABLE` This allows you output audio on the C6 pin (needs abstracting). See the [audio page](feature_audio.md) for more information. diff --git a/docs/ja/config_options.md b/docs/ja/config_options.md index 6ba7f6f1f3..2a64f2ba2a 100644 --- a/docs/ja/config_options.md +++ b/docs/ja/config_options.md @@ -369,10 +369,8 @@ QMK での全ての利用可能な設定にはデフォルトがあります。 * MIDI 制御 * `UNICODE_ENABLE` * Unicode -* `BLUETOOTH_ENABLE` - * Adafruit EZ-Key HID で Bluetooth を有効にするレガシーオプション。BLUETOOTH を見てください * `BLUETOOTH` - * 現在のオプションは、AdafruitEzKey、AdafruitBLE、RN42 + * 現在のオプションは、AdafruitBLE、RN42 * `SPLIT_KEYBOARD` * 分割キーボード (let's split や bakingpy のキーボードのようなデュアル MCU) のサポートを有効にし、quantum/split_common にある全ての必要なファイルをインクルードします * `CUSTOM_MATRIX` diff --git a/docs/ja/feature_bluetooth.md b/docs/ja/feature_bluetooth.md index 4443a4e3ea..f7835dd548 100644 --- a/docs/ja/feature_bluetooth.md +++ b/docs/ja/feature_bluetooth.md @@ -7,11 +7,10 @@ ## Bluetooth の既知のサポートハードウェア -現在のところ Bluetooth のサポートは AVR ベースのチップに限られます。Bluetooth 2.1 については、QMK は RN-42 モジュールと、Bluefruit EZ-Key をサポートしますが、後者はもう生産されていません。より最近の BLE プロトコルについては、現在のところ Adafruit Bluefruit SPI Friend のみが直接サポートされています。iOS デバイスに接続するには、BLE が必要です。iOS はマウス入力をサポートしないことに注意してください。 +現在のところ Bluetooth のサポートは AVR ベースのチップに限られます。Bluetooth 2.1 については、QMK は RN-42 モジュールをサポートします。より最近の BLE プロトコルについては、現在のところ Adafruit Bluefruit SPI Friend のみが直接サポートされています。iOS デバイスに接続するには、BLE が必要です。iOS はマウス入力をサポートしないことに注意してください。 | ボード | Bluetooth プロトコル | 接続タイプ | rules.mk | Bluetooth チップ | |----------------------------------------------------------------|----------------------------|----------------|---------------------------|--------------| -| [Adafruit EZ-Key HID](https://www.adafruit.com/