Apa102 PR #1
Apa102 PR #1
Conversation
Update readme.md
The matrix_col_t type was added in commit 0284431 (part of qmk#3449), but then the code which used that type was removed in qmk#6140, and no other users were added since that time. The presence of that type, however, limits MATRIX_ROWS to 32, which probably does not matter for a real keyboard, but prevents doing things like making a firmware to test all existing pins on a board like Teensy++ 2.0 (which has 46 GPIOs).
* Add support for soft serial to ATmega32U2 * Update drivers/avr/serial.c * Update drivers/avr/serial.c * Update drivers/avr/serial.c * Fix comment * Update drivers/avr/serial.c
…ty value (qmk#9940) * Initial changes to expose "real" MIDI velocity * Change MI_VELU and MI_VELD to fit new logic * Apply cleanups from fauxpark's review my bad on the errant whitespace and else {} placements * Slight changes to MI_VELD to match values when velocity is falling to when it is rising * Add keycode MI_VEL_0 * Update compute_velocity() to handle MI_VEL_0 * Store velocity as 7 bits to hard cap value at 127
* Joystick 16-bit support * Add variable joystick axes resolution * Moved #define statements to .h files * Moved definitions to quantum/joystick.h Removed duplicate definitions from usb_descriptor.h and process_joysick.h Adjust process_joystick.c and usb_descriptor.c to use the pre-computed "JOYSTICK_RESOLUTION" value which contains the logical maximum value of a joystick axis * Cleaning up unnecessary code * Update docs/feature_joystick.md Co-authored-by: Ryan <fauxpark@gmail.com> * Workaround to joystick.h not being included to report.h * Removed unnecessary newlines, updated report.h Changed JOYSTICK_AXES_RESOLUTION conditional in report.h Co-authored-by: Ryan <fauxpark@gmail.com>
* Per-encoder resolutions * Resolutions for right hand
* Branch point for 2020 November 28 Breaking Change Update readme.md * Share button state from mousekey to pointing_device Co-authored-by: Nick Brassel <nick@tzarc.org> Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com> Co-authored-by: Nick Brassel <nick@tzarc.org>
* Add Advanced RGB Matrix effects Add a new option, so that we can better handle custom indicators * Switch to led min/max instead of params Because params has already been incremented and is wrong now * Add indicator color function for use with advanced indicator functions * Add docs and helper macros * Add comment for explanations * Fix macro variables * Fix typo * Run clang-format on rgb_matrix.h
* Add GPIOF/GPIOH. * Also add GPIOI,GPIOJ,GPIOK, to match ChibiOS 20.x. * Make GPIOK opt-in, describe what a keyboard designer needs to do in order to gain access.
* Add milc as a dependency and remove the installed milc * update doctor.py too * pyformat * remove rather than shim questions
* Migrate at_at/660m to use new ChibiOS early initialisation code, use generic F072 board. * Migrate cannonkeys/satisfaction75 to use new ChibiOS early initialisation code, use generic F072 board. * Migrate nebula12 to use new ChibiOS early initialisation code, use generic F072 board. * Defer GENERIC_STM32_F072XB board files to ChibiOS. * Create generic mcuconf.h file for GENERIC_STM32_F072XB. * Create generic mcuconf.h file for STM32_F103_STM32DUINO. * Create generic mcuconf.h file for GENERIC_STM32_F042X6. * Allow boards to override EARLY_INIT_PERFORM_BOOTLOADER_JUMP.
* Initial commit for ChibiOS conf migration. * Modify paths, normalise chconf.h and halconf.h to be common. * Allow deletion of non-overridden files.
* solenoid: remove two functions that do nothing. These functions modify the argument, and so they do nothing. Note: versions of these functions exist in mtdjr's user folder, however to core solenoid support and mtdjr user-specific solenoid support are exclusive (only one can be used at a time). So removing these confusing functions does no harm. * solenoid: bugfix: don't allow dwell time to go 1ms below minimum time. The previous code allowed dwell time to go 1ms below the configured minimum. This change corrects it. * solenoid: bugfix: when incrementing above maximum dwell time, jump back to minimum, not to 1 The previous code used to jump back to 1, which might be way under the configured minimum setting. * solenoid: bugfix: on startup actually use the eeprom-stored dwell-time This is because the dwell time is stored in two variables. * solenoid: bugfix: on haptic_reset, actually use the newly set default dwell time. This is needed because dwell time is configured in two variables. * solenoid: on HPT_RST set buzz to a default value * solenoid: buzz: reworked to make more configurable. Previous behaviour maintained. * solenoid: documentation: clarify meaning of dwell time * solenoid: add feature SOLENOID_DWELL_STEP_SIZE * solenoid: documentation: added note about the precision of the solenoid time settings * haptic: Correctly call haptic_reset when eeprom is corrupt. * haptic: improve what happens if haptic is enabled without erasing eeprom * haptic: improve what happens if solenoid is enabled without erasing eeprom * drivers/haptic: fix compilation issue, when haptic is enabled, but solenoid isn't
* XD75 cleanup * LAYOUT-ify keymaps
* add OLED_UPDATE_INTERVAL_MS support * update docs/feature_oled_driver.md * Update docs/feature_oled_driver.md Co-authored-by: Joel Challis <git@zvecr.com> * Update drivers/oled/oled_driver.c * Update drivers/oled/oled_driver.c Co-authored-by: Joel Challis <git@zvecr.com>
* Add definition based on currently-selected serial driver. * Apply suggestions from code review Suggestions from zvecr. Co-authored-by: Joel Challis <git@zvecr.com> Co-authored-by: Joel Challis <git@zvecr.com>
… of executing code for each main loop iteration. (qmk#10530)
* modify helix config. 'helix/rev2' always OLED on * reduce helix build variation pattern * helix/rev2/keymaps/xulkal/rules.mk: Explicitly disable helix standard post-processing **Compilation result does not change** * helix readmes update * add temporary test script * test end. -- Revert "add temporary test script" This reverts commit 6229ed41f2ff8bac52015150837eaa51d9815e13. * rename rev2/split_common/rules.mk -> rev2/sc/rules.mk * rename pico/split_common/rules.mk -> pico/sc/rules.mk * update keymaps/default/reademe.md * add 'helix/pico/qmk_conf' and 'helix/rev2/qmk_conf' target * add ChangeLog for Helix: PR 8669 * fix helix/pico/qmk_conf compile error Co-authored-by: mtei <2170248+mtei@users.noreply.github.com>
* Changed the processing of select_xxx()/unselect_xxx() in quantum/matrix.c to be atomic. * Changed the processing of select_xxx()/unselect_xxx() in quantum/split_common/matrix.c to be atomic. * update matrix.c * add ATOMIC_BLOCK_FORCEON macro to quantum/quantum_atomic_extend.h * quantum_atomic_extend.h's contents move into quantum.h * update ATOMIC_BLOCK_xxx for unknown platform * ATOMIC_BLOCK macro support PROTOCOL_ARM_ATSAM * Add Atomic Operation section in docs/internals_gpio_control.md
* Update the Speedo firmware for v3.0 * Cleanup recommendations from the PR checklist * Address PR feedback * Update build instructions in readme * Restructure folders and restore v2 firmware * Clean up layouts in info.json * Remove unnecessary files * Address more PR feedback
* sequencer: create togglable feature * sequencer: add support for steps * sequencer: add support for tempo and resolutions * sequencer: schedule a message print at the right frequency * sequencer: send a hardcoded note * sequencer: add support for 8 tracks * sequencer: play several notes simultaneously * sequencer: only play the active tracks for a given step * sequencer: change the default behavior of the track toggler * sequencer: make number of tracks and track notes customizable * sequencer: move the keycodes down Not adding them at the end of the list apparently risks breaking compatibility with VIA. Source: qmk#9703 (comment) * sequencer: add unit tests * sequencer: add unit test for matrix_scan_sequencer * sequencer: expose internal state for better unit-testability * sequencer: add unit tests for matrix_scan_sequencer
The APA102 source was broken by commit 16a15c1 as it did not include the quantum header. This commit addresses that, as well as other issues with transferring bytes over the SPI interface, i.e. it was not setting the clock pin back to low after sending a bit. The deviation when sending the end frame is kept, but updated to the latest from the referenced project. Finally, these changes expose the global LED brightness parameter of the APA102. Brightness values are configurable through `APA102_DEFAULT_BRIGHTNESS` and `APA102_MAX_BRIGHTNESS`.
|
This has been tested and works on a proton-c :) |
|
Oh and I'm not sure about changing the multiple calls of |
|
It should be noted that the delay is meassured at slightly over 200ns on AVR, however on ARM it's ~20us with no delay, which is slow enough to be seen. I'll be testing your your latest commit :) |
|
Latest push implements a shaved down version of your wait macro. It was also shaved down to avoid conflicting with defines from ws2812 leds, in case anyone ever runs ws2812s and apa102s on the same board. This gives me ~70 ns delay on a proton-c (stm32f303) |
|
I can't believe I didn't see this until now. I will try out your updates and get back to you, they look promising. Thanks! |
aldehir
force-pushed
the
apa102-develop
branch
from
a906bed to
0abf464
Compare
|
@Duckle29 It looks like the upstream repo force pushed to the develop branch so the commit history is all over the place. I cannot merge in your PR with my branch because of this, but I have cherry-picked your changes onto my branch. bf249d6 Experimental APA102 support on AVR and ARM I appreciate the Makefile updates. It looks like the qmk repo split the driver from the enable option, so I did the same to your changes. I see you moved the driver to the I moved the I initially had unrolled my operations, which is an optimization technique. I mainly did it to reduce variances in the timings, although I doubt it really matters. For the I definitely like the Take a look and let me know what you think! Overall, I'm liking these changes. I appreciate your help. |
|
Awesome, yeah we just got ready for a |
Hi there.
There was a good bit of changes I couldn't request on your PR, because it was changes to files you hadn't changed and moving files around.
I'll open a PR against your fork instead :)
The changes are: