| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
* Set up Bonsai C4 as a platform board file
* corrections and improvements based on testing and feedback
* Added VBUS sensing as default capability for improved split support using Bonsai C4
* Update clock divisor for SPI flash
Co-authored-by: Nick Brassel <nick@tzarc.org>
Co-authored-by: Nick Brassel <nick@tzarc.org>
|
| |\ |
|
| | | |
|
| | | |
|
| | | |
|
| |/
|
| |
Co-authored-by: Joy <chang.li@westberrytech.com>
|
| |
|
|
|
| |
Co-authored-by: Mariappan Ramasamy <947300+Mariappan@users.noreply.github.com>
Co-authored-by: Mariappan Ramasamy <maari@basis-ai.com>
Co-authored-by: Sadek Baroudi <sadekbaroudi@gmail.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).
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Disable RESET keycode because of naming conflicts
* Add Pico SDK as submodule
* Add RP2040 build support to QMK
* Adjust USB endpoint structs for RP2040
* Add RP2040 bootloader and double-tap reset routine
* Add generic and pro micro RP2040 boards
* Add RP2040 onekey keyboard
* Add WS2812 PIO DMA enabled driver and documentation
Supports regular and open-drain output configuration. RP2040 GPIOs are
sadly not 5V tolerant, so this is a bit use-less or needs extra hardware
or you take the risk to fry your hardware.
* Adjust SIO Driver for RP2040
* Adjust I2C Driver for RP2040
* Adjust SPI Driver for RP2040
* Add PIO serial driver and documentation
* Add general RP2040 documentation
* Apply suggestions from code review
Co-authored-by: Nick Brassel <nick@tzarc.org>
Co-authored-by: Nick Brassel <nick@tzarc.org>
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
* Add non blackpill F4x1 config files
* Move ld files
* Remove f401 i2c bodges
* more bodge?
* Update to recommended defaults
|
| |
|
|
|
|
|
|
|
| |
* Refactor CTPC logic to allow future converters
* Update builddefs/converters.mk
Co-authored-by: Stefan Kerkmann <karlk90@pm.me>
Co-authored-by: Stefan Kerkmann <karlk90@pm.me>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* ChibiOS 21.11.1 update.
* `uf2-tinyuf2` => `tinyuf2`
* Updated chibios-contrib, fixup preprocessor for tinyuf2 bootloader.
* Fixup keychron L433 boards.
* Makefile cleanup.
* RISC-V build fixes.
* Fixup RISC-V build.
|
| | |
|
| | |
|
| |
|
|
|
| |
* Modified config.h default configuration
* Modified config.h default configuration
|
| | |
|
| |
|
|
|
| |
* Config migration with removal of unnecessary items.
* Removed as per suggestion.
|
| |
|
|
|
|
|
| |
* Added support for WB32 MCU
* Modified eeprom_wb32.c
* Remove the eeprom_wb32-related code
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Add support for building against ChibiOS svn/trunk.
* Swap to 21.6.x
* Update to latest branch revision as released version is broken.
* Updated configs.
* Conf updates.
* Updated ChibiOS
* Convert STM32L422 to actual L422 ChibiOS platform.
* Downgrade to 20.3.4 as ChibiOS 21.6.x is being aborted.
* Rollback L422-based boards.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Add support for RISC-V builds and GD32VF103 MCU
* Add toolchain selection in chibios.mk based on the mcu selected in
mcu_selection.mk
* Reorder and added comments to chibios.mk to have a streamlined makefile
* Add GD32VF103 mcu to possible targets for QMK.
* Add STM32 compatibility for GD32VF103 MCU, this is hacky but more efficent
then rewriting every driver.
* Add GigaDevice DFU bootloader as flash target, please note that
dfu-util of at least version 0.10 is needed.
* Add analog driver compatibility
* Add apa102 bitbang driver compatibility
* Add ws2812 bitbang driver compatibility
* Add eeprom in flash emulation compatibility
* Allow faster re-builds with ccache
* Add SiPeed Longan Nano to platform files
* Add SiPeed Longan Nano Onekeys
* Make quine compatible with other bootloaders
* Support builds with picolibc
* Add risc-v toolchain to arch and debian/ubuntu scripts
|
| | |
|
| |
|
|
|
|
|
|
|
| |
* Initial pass of F405 support
* remove some conf files
* docs
* clang
|
| |
|
|
|
| |
* Add i2c defaults for Convert to Proton C
* Hide default defines behing CTPC check
|
| | |
|
| | |
|
|
|
* Move board files
* fix up after rebase
|
