qmk_firmware - [no description]

	Commit message (Collapse)	Author	Age	Files	Lines
*	Remove CORTEX_ENABLE_WFI_IDLE from keyboards. (#21353)	Nick Brassel	2023-06-23	1	-3/+0
\| \| \| \| \|	* Remove CORTEX_ENABLE_WFI_IDLE from the codebase. * Turn on CORTEX_ENABLE_WFI_IDLE by default.
*	Migrate `rgblight.pin` and `RGB_DI_PIN` to `ws2812.pin` (#20303)	Ryan	2023-04-06	1	-1/+1
\|
*	Clean up APA102 config and add DD mapping (#20159)	Ryan	2023-03-20	2	-2/+4
\|
*	Fixup CI build for F103C6 onekey. (#20188)	Nick Brassel	2023-03-19	1	-1/+1
\|
*	Add some missing `#pragma once`s (#19902)	Ryan	2023-02-21	1	-0/+3
\|
*	Remove usages of config_common.h from config.h files. (#19714)	Nick Brassel	2023-01-31	1	-1/+0
\|
*	Merge remote-tracking branch 'origin/master' into develop	QMK Bot	2022-11-18	1	-1/+1
\|\
\| *	Disable onekey console by default (#19104)	Joel Challis	2022-11-18	1	-1/+1
\| \|
* \|	onekey: disable NKRO and mousekeys by default (#19038)	Ryan	2022-11-12	1	-4/+0
\| \|
* \|	onekey: enable ADC for Bluepill and Blackpill (#18545)	Ryan	2022-09-30	2	-0/+5
\|/
*	Onekey: migrate some stuff to data driven (#18502)	Ryan	2022-09-30	3	-12/+15
\|
*	Move keyboard USB IDs and strings to data driven: develop (#18152)	Ryan	2022-08-24	2	-2/+3
\| \| \| \| \|	* Move keyboard USB IDs and strings to data driven: develop * Also do new onekeys
*	Add minimal STM32F103C6 support (#17853)	Sergey Vlasov	2022-08-11	6	-0/+136
	Unfortunately, the crippled versions of “Bluepill” boards with STM32F103C6xx chips instead of STM32F103C8xx are now sold all over the place, sometimes advertised in a confusing way to make the difference not noticeable until too late. Add minimal support for these MCUs in the common “Bluepill with stm32duino” configuration, so that it could be possible to make something useful from those boards (although fitting QMK into the available 24 KiB of flash may be rather hard). (In fact, I'm not sure whether the “STM32” part of the chip name is actually correct for those boards of uncertain origin, so the onekey board name is `bluepill_f103c6`; another reason for that name is to match the existing `blackpill_f401` and `blackpill_f411`.) The EEPROM emulation support is not included on purpose, because enabling it without having a working firmware size check would be irresponsible with such flash size (the chance that someone would build a firmware where the EEPROM backing store ends up overlapping some firmware code is really high). Other than that, enabling the EEPROM emulation code is mostly trivial (the `wear_leveling` driver with the `embedded_flash` backing store even works without any custom configuration, although its code is significantly larger than the `vendor` driver, which may also be important for such flash size).