* 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
- Use normal ChibiOS I2C driver.
- Move drawing code to housekeeping -- previously it was during matrix
scan, which gets executed during bootmagic checks. However, bootmagic
is invoked before QWIIC subsystem is enabled, which means I2C isn't
configured yet. All I2C calls to the OLED fail with timeouts while
bootmagic is being checked. Housekeeping ensures this is executed once
the system has initialised and settled.
- QWIIC OLED driver: properly clear out OLED buffer when clearing screen.
* 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>
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.
* ws2812: Fix number of nops for AVR at 8 MHz
When trying to calculate the number of nops for AVR running at 8 MHz,
the value of `w3` is expected to be negative; however, because `F_CPU`
is defined in tmk_core/avr.mk with the `UL` suffix, the preprocessor
performs its calculations using `unsigned long`, getting a very large
positive number instead of the expected negative number; this then
results in generating code with a huge number of nops. Fix the broken
calculations by performing a comparison before subtraction, so that the
unsigned number wraparound does not occur.
The keyboard which triggers the problem is `handwired/promethium`; the
buggy code silently compiles, but the resulting timings would be
completely wrong.
* ws2812: Clean up the code after the 8 MHz fix
Remove old code which was unsuccessfully trying to clamp negative w1, w2
and w3 values to 0, and set w1_nops, w2_nops and w3_nops directly.
* at90usb162 support
* fix missing bracket
* Apply suggestions from code review
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* add byte order bgr for ws2812
* update docs for driver change
* Update ws2812_driver.md
* Update docs/ws2812_driver.md
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* Rewrite APA102 support
The APA102 source was broken by commit 16a15c1cfc 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`.
* Fix typo in led brightness extern
* Move driver out of AVR directory and add delay for ARM
* Experimental APA102 support on AVR and ARM
Co-authored-by: Alde Rojas <hello@alde.io>
* Refactor apa102_send_byte() calls to a loop
* Implement io_wait function for ARM
* Move APA102 drivers to own directory, fix copyright notice
* Add APA102 keymap to handwired/onekey
* Simplify RGBLIGHT_ENABLE/DRIVER option handling
Co-authored-by: Mikkel Jeppesen <2756925+Duckle29@users.noreply.github.com>
