* 52 Keymap.json: Set for Hillside 52
- Change script rows
* 52 Keymap.c: mirror .json
CAPSWORD, QK_BOOT, readme cleanup, EE_RST
* 52 Keymap.json: Initial files copy from 56
* 52 Keymap.json nav/edit lay, thumb shift, syms
- Del in backspace spot on sym layer
- Thumb shift OSM instead of extra space
- Nav/edit on num/fn: arrows cut copy paste undo redo, page up/down
- Fn keys bottom row to allow nav edit keys
- App and AltGr on lower row, on their layer
- Braces on index, so more common -= on middle ring.
- Adjust has Ctrl/GUI swap
- EE_RST, CAPSWORD, QK_BOOT, SPLIT_DETECT
* 52 Family: readme image and folder link
* 52 Board: initial copy from 56
* 52 Keymap via
* 52 Board: remove keys, cant columns, better ids
- .json: vid: MM, pid: H52
* 52 Keymap.c: initial.c copy from 48
* QK_BOOT EE_CLR, not ANY(), as config.qmk supports
- CAPSWRD instead of ANY, though config.qmk still converts to ANY()
* Cleanup readme
* 52 Keymap: Remove redundant key, cleanup script
* 52 Keymap: Fix template
* 52 Readme: Link lower res image better for readme
Co-authored-by: Drashna Jaelre <drashna@live.com>
* 52 Keymap: Move pretty-print script to GitHub wiki
* 52 Keymap: Link to 1024 res image thumbnails
* 52 Keymap: fix whitespace before image link
* Family: Fix image link to 1024 thumb
Co-authored-by: Drashna Jaelre <drashna@live.com>
* 52: Keymap: Caps word on a layer home row
* 52: Keymap: Arrows on right. Symmetric layer keys.
- Nav:
- Arrows on right so up/down more intuitive. Page up/down on ends
- Cut on home row, as more common
- Sym:
- Layer mods on activate hand, extras symbols on left
- Common digits on lower row
- Base:
- Layer keys symmetric, on most extended, not resting, thumb
- Mute on util key for easy use
- Swap layers 3 and 4 to match swapped thumbs
Co-authored-by: mmccoyd <mmccoyd@cs.berkley.edu>
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).
* PMW33XX drivers overhaul
This combines the PMW3389 and PM3360 drivers as they only differ in the
firmware blobs and CPI get and set functions. The following changes have
been made:
* PMW3389 now gets the same multi-sensor feature that is already available on the
PMW3360.
* Introduced a shared pmw33xx_report_t struct is now directly readable via SPI
transactions instead of individual byte-sized reads, saving multiple
copies and bitshift operations.
* pmw33(89/60)_get_report functions had unreachable branches in their motion
detection logic these have been simplied as much as possible.
* The fast firmware upload option has been removed as this becomes obsolete by
the newly introduced polled waiting functions for ChibiOS polled waiting
* PMW33(60/89)_SPI_LSBFIRST and PMW33(60/89)_SPI_MODE config options
have been removed as they don't need to be configurable.
* All PMW3389 and PMW3360 defines have been unified to a PMW33XX prefix
to reduce code duplication and make the defines interchangeable
* Adjust keyboards to PMW33XX naming scheme
* Use polled waiting on platforms that support it
Due to context switching overhead waiting a very short amount of time on
a sleeping thread is often not accurate and in fact not usable for timing
critical usage i.e. in a driver. Thus we use polled waiting for ranges
in the us range on platforms that support it instead. The fallback is
the thread sleeping mechanism.
This includes:
* ARM platforms with CYCCNT register (ARMv7, ARMv8) this is
incremented at CPU clock frequency
* GD32VF103 RISC-V port with CSR_MCYCLE register this is incremented at
CPU clock frequency
* RP2040 ARMv6 port which uses the integrated timer peripheral which is
incremented with a fixed 1MHz frequency
* Use wait_us() instead of chSysPolledDelayX
...as it is powered by busy waiting now.
* Add chibios waiting methods test bench
* Add missing '(' to print_bin_reverse32 declaration
* Fix insufficient character buffers on satisfaction75
* Remove \0 character in format string and use corrected offset math
instead on rocketboard 16
* Replace snprintf_ with snprintf for djinn
* Explicitly ignore format checks for tracktyl manuform that uses %b
specifier
* Print properly escaped version string in command.c, as PRODUCT or
other defines can contain constructs like 'Vendor keyboard 66%' which
will be interpreted as a format specifier
* Tentative Teensy 3.5 support
* Set firmware format to .hex for ARM Teensys
* Got to "device descriptor failed" by comparing with Teensy 3.6 code
* Drop down to 96MHz...
* Bump back up to 120MHz
* 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>
Co-authored-by: Drashna Jaelre <drashna@live.com>
Co-authored-by: Joel Challis <git@zvecr.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
