summaryrefslogtreecommitdiffstats
path: root/keyboards/handwired/onekey
Commit message (Collapse)AuthorAgeFilesLines
* onekey: Enable ADC for STM32F072 Discovery (#18592)Ryan2022-10-052-0/+5
|
* [Core] PWM Backlight for RP2040 (#17706)Stefan Kerkmann2022-10-047-1/+28
|
* Merge remote-tracking branch 'origin/master' into developQMK Bot2022-10-011-3/+2
|\
| * onekey: fix quine keymap (#18555)Ryan2022-10-011-3/+2
| |
* | onekey: enable ADC for Bluepill and Blackpill (#18545)Ryan2022-09-3010-0/+26
| |
* | Merge remote-tracking branch 'upstream/master' into developfauxpark2022-09-3069-335/+259
|\|
| * Onekey: migrate some stuff to data driven (#18502)Ryan2022-09-3069-335/+259
| |
* | Further refactoring of joystick feature (#18437)Ryan2022-09-271-5/+1
| |
* | Use a macro to compute the size of arrays at compile time (#18044)Jeff Epler2022-08-301-2/+2
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Add ARRAY_SIZE and CEILING utility macros * Apply a coccinelle patch to use ARRAY_SIZE * fix up some straggling items * Fix 'make test:secure' * Enhance ARRAY_SIZE macro to reject acting on pointers The previous definition would not produce a diagnostic for ``` int *p; size_t num_elem = ARRAY_SIZE(p) ``` but the new one will. * explicitly get definition of ARRAY_SIZE * Convert to ARRAY_SIZE when const is involved The following spatch finds additional instances where the array is const and the division is by the size of the type, not the size of the first element: ``` @ rule5a using "empty.iso" @ type T; const T[] E; @@ - (sizeof(E)/sizeof(T)) + ARRAY_SIZE(E) @ rule6a using "empty.iso" @ type T; const T[] E; @@ - sizeof(E)/sizeof(T) + ARRAY_SIZE(E) ``` * New instances of ARRAY_SIZE added since initial spatch run * Use `ARRAY_SIZE` in docs (found by grep) * Manually use ARRAY_SIZE hs_set is expected to be the same size as uint16_t, though it's made of two 8-bit integers * Just like char, sizeof(uint8_t) is guaranteed to be 1 This is at least true on any plausible system where qmk is actually used. Per my understanding it's universally true, assuming that uint8_t exists: https://stackoverflow.com/questions/48655310/can-i-assume-that-sizeofuint8-t-1 * Run qmk-format on core C files touched in this branch Co-authored-by: Stefan Kerkmann <karlk90@pm.me>
* Move keyboard USB IDs and strings to data driven: develop (#18152)Ryan2022-08-248-6/+12
| | | | | * Move keyboard USB IDs and strings to data driven: develop * Also do new onekeys
* RESET -> QK_BOOT user keymaps (#17940)Joel Challis2022-08-211-1/+1
|
* Merge remote-tracking branch 'origin/master' into developQMK Bot2022-08-2035-39/+57
|\
| * Move keyboard USB IDs and strings to data driven, pass 2: handwired (#18079)Ryan2022-08-2035-39/+57
| |
* | Merge remote-tracking branch 'origin/master' into developQMK Bot2022-08-151-0/+1
|\|
| * Migrate more F4x1 board files (#18054)Joel Challis2022-08-151-0/+1
| |
* | Add minimal STM32F103C6 support (#17853)Sergey Vlasov2022-08-116-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).
* | Remove `UNUSED_PINS` (#17931)Nick Brassel2022-08-0618-18/+0
| |
* | Add kb2040 onkey keyboard that works with the oled keymap (#17786)Jeff Epler2022-08-054-0/+72
| |
* | Merge remote-tracking branch 'origin/master' into developQMK Bot2022-07-261-5/+3
|\|
| * Update README.md for teensy lc onekey (#17797)Diogo Sergio2022-07-251-5/+3
| |
* | [Core] Use polled waiting on ChibiOS platforms that support it (#17607)Stefan Kerkmann2022-07-117-2/+78
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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
* | Tentative Teensy 3.5 support (#14420)Ryan2022-07-035-0/+146
| | | | | | | | | | | | | | | | | | | | | | * 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
* | Merge remote-tracking branch 'origin/master' into developQMK Bot2022-07-012-0/+2
|\|
| * Specify blackpill board files where relevant (#17521)Joel Challis2022-07-012-0/+2
| |
* | [Core] Add Raspberry Pi RP2040 support (#14877)Stefan Kerkmann2022-06-304-0/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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>
* | Do not enable PERMISSIVE_HOLD when TAPPING_TERM exceeds 500ms (#15674)precondition2022-06-241-0/+1
|/
* Add WB32 evaluation board onekey targets. (#17330)Nick Brassel2022-06-086-0/+46
|
* [Feature] Add support for multiple switchs/solenoids to Haptic Feedback ↵Drashna Jaelre2022-05-153-0/+17
| | | | engine (#15657)
* [Core] Add Reboot keycode to core (#15990)Drashna Jaelre2022-05-141-0/+5
|
* Provide better config defaults for bluepill boards (#16909)Joel Challis2022-04-221-28/+0
|
* Expose API for hardware unique ID (#16869)Joel Challis2022-04-181-0/+28
|
* Add non blackpill F4x1 config files (#16600)Joel Challis2022-04-061-23/+0
| | | | | | | | | | | * Add non blackpill F4x1 config files * Move ld files * Remove f401 i2c bodges * more bodge? * Update to recommended defaults
* Joystick feature updates (#16732)Ryan2022-03-261-2/+0
| | | | | | | * Joystick feature updates * Move new functions to joystick.h * Docs
* Remove `NO_ACTION_MACRO` and `NO_ACTION_FUNCTION` from keyboard config.h ↵Ryan2022-03-151-4/+0
| | | | (#16655)
* Add L432, L442. (#16016)Nick Brassel2022-01-243-0/+31
|
* Merge remote-tracking branch 'origin/master' into developQMK Bot2022-01-051-1/+1
|\
| * [Keymap] Fix onekey oled keymap (#15751)Drashna Jaelre2022-01-051-1/+1
| |
* | Refactor `bootloader_jump()` implementations (#15450)Ryan2021-12-272-0/+6
|/ | | | | | | * Refactor `bootloader_jump()` implementations * Fix tests? * Rename `atmel-samba` to `md-boot`
* Tidy up NKRO_ENABLE rules (#15382)Ryan2021-12-091-2/+1
|
* Tidy up `SLEEP_LED_ENABLE` rules (#15362)Ryan2021-12-011-2/+0
|
* [Core] Change OLED task function to be boolean (#14864)Drashna Jaelre2021-11-021-1/+2
| | | | | | | | | | | | | * [Core] Add kb level callbacks to OLED driver * Update keyboards and keymaps * Update docs * Update userspace configs * Add fix for my keymap ... * update lefty
* [Core] Add support for RISC-V builds and GD32VF103 MCU (#12508)Stefan Kerkmann2021-10-188-2/+129
| | | | | | | | | | | | | | | | | | | | | | | | | | | * 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 (#14584)Joel Challis2021-09-253-0/+40
| | | | | | | | | * Initial pass of F405 support * remove some conf files * docs * clang
* Align ChibiOS I2C defs with other drivers (#14399)Joel Challis2021-09-123-5/+5
| | | | | | | | | * Align ChibiOS I2C defs with other drivers * Update keyboards/xelus/valor_frl_tkl/config.h Co-authored-by: Ryan <fauxpark@gmail.com> Co-authored-by: Ryan <fauxpark@gmail.com>
* Remove BLUETOOTH_ENABLE from keyboard-level rules.mk (#14379)Ryan2021-09-121-1/+0
|
* Remove width, height and key_count from info.json (#14274)Ryan2021-09-121-2/+0
|
* Remove bootloader listings from rules.mk (#14330)Ryan2021-09-101-1/+1
|
* Bugfix for Joystick and JSON schema (#14295)Ryan2021-09-091-1/+1
|
* [Core] Refactor OLED to allow easy addition of other types (#13454)Xelus222021-08-241-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * add docs * core changes * update keyboards to new OLED * updated users to new OLED * update layouts to new OLED * fixup docs * drashna's suggestion * fix up docs * new keyboards with oled * core split changes * remaining keyboard files * Fix The Helix keyboards oled options * reflect develop Co-authored-by: Drashna Jaelre <drashna@live.com> Co-authored-by: mtei <2170248+mtei@users.noreply.github.com>
* Digitizer HID interface : absolute coordinates for mouse cursor (#12851)a-chol2021-08-182-0/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Add digitizer HID interface for setting the mouse cursor position at absolute screen coordinates. Tested on Pro Micro, Proton C and Blackpill. * Update docs/feature_digitizer.md Co-authored-by: Ryan <fauxpark@gmail.com> * Update tmk_core/protocol/usb_descriptor.c Co-authored-by: Ryan <fauxpark@gmail.com> * Add missing copyrights Add V-USB support * Add support for digitizer dedicated endpoint for lufa and chibios. Fix formatting issues Move digitizer_task definition to the feature's base implementation file * Run cformat on modified files * Change digitizer report usage to Digitizer instead of Pen to avoid pointer disappearing on Windows. * Update tmk_core/protocol/vusb/vusb.c Co-authored-by: Ryan <fauxpark@gmail.com> * Run cformat from docker image * Remove send_digitizer from host_driver_t and instead rely on the declaration being the interface to the implementation in each HW-specific usb implementation. * Fix build : send_digitizer shouldn't be static in vusb and add weak-linkage implementation for tests without usb implementation * Change digitizer user interface to match pointing device's * Update documentation with new API Co-authored-by: a-chol <nothing@none.com> Co-authored-by: Ryan <fauxpark@gmail.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-23 23:44:49 +0000