| Age | Commit message (Collapse) | Author |
|---|
|
Co-authored-by: Drashna Jaelre <drashna@live.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
(#18005)
|
|
|
|
|
|
|
|
Co-authored-by: Drashna Jaelre <drashna@live.com>
|
|
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).
|
|
|
|
Co-authored-by: Drashna Jaelre <drashna@live.com>
|
|
|
|
|
|
-update layout
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Co-authored-by: Ryan <fauxpark@gmail.com>
|
|
|
|
Co-authored-by: Drashna Jaelre <drashna@live.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* aurora65 initial commit
* Add keymap images
* Move USB config to JSON
Co-authored-by: yiancar <yiancar@gmail.com>
|
|
|
|
|
|
|
|
* Initial commit
* testing modes
* working on puckbuddy firmware. This is all working for now but need to clean it up and personalize it.
* needs to be updated from vial build
* prepping for PR
* added rgb mode cycling to fn1 since it isn't on the encoder for these maps
* readme written in preparation for pr
* reverting driver print line
* Removed old reference to OBE in the readme from copypaste error
* applying changes based on review
* applying changes from review
* Update keyboards/mechwild/puckbuddy/puckbuddy.c
* trailing whitespaces removed
* added clear screen condition for switching back to name rendering
* Added uf2 keymap and fixed display glitch for the logo render art.
* Removed extra definition of FEE_PAGE_BASE_ADDRESS
* Removed the uf2 keymap and made it automatic when selecting bootloader instead
* Fixed the bad bootloader check
* moved the uf2 check from rules.mk to post_rules.mk to satisfy lint
* changing it back to stm32-dfu bootloader default
* Fixed RGBLIGHT enable oversight.
* Added persistent dynamic tapping configuration for the cirque touchpad tap term
* new lines at end of files for formatting and diff sanity
* changing default bootloader back to stm32-dfu
* Had to completely redefine the tap keycodes instead of using the DT_UP and DT_DOWN keycodes because I was not able to specify them easily in the via/vial configs and this allows me to keep the original functionality instead of tying it to eeprom like these are.
* Added tap toggling keycodes to quick enable and disable the tapping term
* working out an issue where the tap status keeps turning to off on power cycle
* correcting submodule garbo
* Fixed display issue and rewrote TAP config approach to make it a little easier to control
* removing backup puckbuddy.c code
* Added some comment, removed some commented out old code, removed trailing whitespace
* Changed to handle tinyuf2 by expecting emulated eeprom so that adding other forms of eeprom can be handled for the memory offset separately, and added user oled conditional inside the keyboard oled code block
* Updated default keymaps to have the tap and dpi keys on by default
* Apply suggestions from code review
* Apply suggestions from code review
|
|
|
|
Co-authored-by: Drashna Jaelre <drashna@live.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
|
|
|
|
|
