vim, git, aws and other three-letter words

Software Development Notes

Keyboards Links

Keyboards!

My keyboards (past and current)   folded

Voyager   folded

Moonlander   folded

Planck   folded

clipboard-20261109T000020.png
  • there are TERM_ON / TERM_OFF mappings on the adjust layer - is this for terminal feature? check it
  • PCB extensions
    • (from website) Footprints for add-ons to expand functionality:
    • (from reddit post) Along with lots of footprints and breakouts (every pin/row/col on the chip has been broken-out)!
      • 9x footprints for WS2812B RGB LEDs (COM-12667)
      • Footprint for a 4-channel DIP switch that can be used to configure custom flags in QMK (210-4ES sorry for the only non-Sparkfun link)
      • Footprint for a 2-pin JST-PH (commonly used for batteries) (PRT-09749)
      • Footprint for a 4-pin Qwiic (I2C) JST-SH connector (PRT-14417)
        • This will allow you to hook up any of Sparkfun's Qwiic breakouts (QMK support will be coming!) but also other keyboards with the same port as split boards (have this working now)
        • Footprint for a clickable (worked into the matrix) rotary encoder in one of four positions along the left side (COM-09117, et al)
        • Footprint for a 6-pin male/female header (PRT-09015 or PRT-12590, et al)
  • default layout: QMK Configurator
  • (advanced planck keymap with sounds) [Keymap] tk planck keymap (#11400) · qmk/qmk_firmware@0e7e52c

Dactyl Minidox.   folded

Ajazz shortcuts   folded

  • FN+B = desktop / home screen
  • FN+alt,?,ctr - arrows
  • Fn+numbers = Fn keys
  • Fn+Z/X/C = Media Prev/Play-Pause/Next
  • Fn+V = Lock Screen Win-L
    • Opens calendar on Android
    • Fn+Esc=` (backtick)
    • Fn+Space, hold 4s = reset settings
  • Ajazz settings
    • Fn+Q/W/E - bluetooth device
    • Fn+ | - rgb mode cycle
    • Fn+] - rgb speed
    • Fn+[ = rgb brightness
    • Fn+Right Shift - arrows/keys exchange (make arrows work without Fn)
    • Fn+Left Ctr - Number row/Fn row exchange
  • Android shortcuts
    • Ctrl+Space - Language
    • Space - scroll down / Shift+Space - up
    • Alt-Tab - switch windows
    • Browser back/forward - Alt+Left/Right arrows

Mitosis   folded

Mitosis

Hardware

Firmware

  • mitosis-docs/[[http://mitosis-README.md][mitosis-README.md at master · babarrett/mitosis-docs]]
  • mitosis-hardware/bom at master · reversebias/mitosis-hardware
  • mitosis (radio channel instead of bluetooth, receiver on the computer side)
    • Wireless + Split + QMK = Mitosis : MechanicalKeyboards
    • Parts list with suppliers
    • As I understand, the design is this (and is quite different from what I thought initially)
      • Both parts are independent and each talks to a radio receiver
      • The radio receiver, together with microprocessor are connected to the computer
      • 1: this is not bluetooth, this is radio channel
      • 2: the keyboard firmware (QMK) is inside the receiver block, not on halves of the keyboard
      • Vs the design I kept in mind: both halves are loaded with QMK and both have bluetooth chip to communicate with each other (master / slave) and with the computer
        • According to the mitosis author, this leads to a much higer energy consumption
        • While his design can hold for 2.5 months on a set of CR2032 batteries (one for each half)
        • It is also much cheaper than bluetooth implementation
        • Also lighter, since big battery is not needed
      • The disadvantage of the design: requires connecting a receiver to the computer
        • Not a big problem, but still, it is more convenient with bluetooth
    • Hmm, interesting. The main issue with a direct transfer over to the TS65 layout is the number of pins required. The nrf51822 has 31 GPIOs, and the mitosis has 23 keys. This left a few GPIOs leftover for configuration and testing LED. It looks like the TS65 keyboard right half has 32 keys in the minimal cofiguration, which means that you'd need to have some matrix and scanning to read all the keys. Which means adding diodes, power consumption, and firmware complexity. The current design doesn't handle any of those things, because it simply didn't need to. So it might be a lot more work than a simple transfer over, sorry.
      • so it connects keys to the pins directly, with no scanning? I thought this is QMK's work, while from what he says, it would be his job (or maybe this is a "custom" part of every QMK-based firmware, what actually differs each board?)
    • Ok, breakdown in US dollars:
      • PCBs/plates: $25 for 10 (used 4)
      • Switches: $33 for 110 (used 46)
      • Keycaps: $28 for a 108key PBT set (used 46)
      • Neoprene: $16 for a meter (used ~1/10th of the roll)
      • Headers/FETs: couple of cents, but had them in stock
      • Wireless modules: $20 for 3
      • ST LINK V2 clone: $2
      • Pro micro: $3
      • Receiver PCB: $5.40 for 3 (used 1)
      • Regulator/RGB LED/buttons: couple of cents, had in stock
      • CR2032: $1 for 5 from china (dubious quality), or $2 for 8 from IKEA
      • That comes up to 134$ just adding those up. But it also sounds like you can pretty much make two keyboards at that price.
      • (so actually, it is < $100)
    • So do the two halves pair to each other? How is the latency between them? Is the pairing address for each half hardcoded into the other half?
      • Both halves only talk to the receiver, there's no low power way for either of the halves to be awake and listening for messages, at least not without unacceptable latency.
        • Worst latency I've seen over the wireless link was 3ms, usually it's below 1.5. Add this to the 5ms debouncing and ~1ms of the USB polling. It's completely imperceptible, I wouldn't use a wireless keyboard if I could notice it.
        • I've been using hardcoded addressing for testing, but I'm currently working on a dynamic pairing system for the future.
        • Oh! That makes more sense. I managed to misunderstand the part about the receiver. I thought you were doing like a master half and a slave half and was worried about the latency between halves, but using a receiver should largely solve that issue. You will obviously still have some amount of latency, but it should be roughly the same between halves so probably not that big of a deal.
    • how are you measuring latency?
      • Using an oscilloscope, I can trigger on a keypress, see the 5 milliseconds of debounce, then the spike in current as the packet is sent, then the output from the receiver module into QMK. I haven't been decoding the USB, but the point is, the wireless system adds 1-3ms of latency above a normal QMK keyboard.
    • Holy crap! Looks like a project that I'd do if I was smart. How do the halves communicate with each other? I mean there should be a second communication channel, are there like three nrf51822s, one for the computer and two for the halves? You can't pair both halves independently, because key combinations would not work, can you?
      • OMG it works even if halves are paired independently or even with different keyboards and different connections (USB/BT/etc.). I've just paired HHKB Pro 2 with Hasu controller and HHKB BT with bt 3.0 to the same machine and key combinations worked just fine. Shift on the first keyboard activates caps mode on the second and Ctrl on the first with A on the second fires "Ctrl+A". Figures you can have two halves paired independently without a need for a dedicated communication channel between the halves. That's kind of cool, I didn't know that until now.
        • reverse_bias: Yeah, what you described works for system modifiers, as the OS keeps track of the state of those keys. Really, all the keyboard is sending is a stream of keyPress and keyRelease events, which means you can use modifiers across keyboards. What you can't do however, is use any function or keymap layers, hence this design using a centralised dongle that handles the keymap and USB communication. The nice things about this method is the super low power keyboard halves, as they never need to be actively listening, and updating keymaps is a single upload to the dongle without having to re-pair or lose connection.
        • Also, the hell is receiver? Don't you use a standard Bluetooth-HID stack and firmware? I've tried a bunch of those for nrf51822 https://geekhack.org/index.php?topic=40514.msg2244694#msg2244694 it's much more convenient than using a dedicated receiver device. Why even use such a thing (especially on laptops with built-in bluetooth and a lack of usb ports)?
          • reverse_bias Nope, not using Bluetooth here, even though yes, the modules support it.
            • There's no low power way of doing a split Bluetooth keyboard with layers, at least nowhere near the battery life of this design where it lasts 6-12 months on a single coin cell. Non-split Bluetooth keyboards can become lower power by buffering key events to minimise airtime, not possible with a split design as you'd get synchronisation issues between the halves. You may suggest that the halves can communicate the layer state between themselves, but having an RF receiver turned on listening for a packet consumes way too much power, and timesharing the receive only increases latency.
            • I'm using a protocol called Gazell, which supports all the frequency hopping for coexistence, pairing and encryption benefits of Bluetooth while allowing for a no-compromise split design. For me low power, low latency, intelligent layers and macros were much more important.
        • Oh right, how do you press F1-F12 without dedicated keys then? There are independent Fn keys on both halves? That's still kind of a downside though considering I'm using a single Fn key on my HHKB.
          • reverse_bias I meant that the system here uses a centralised dongle, so layers across halves works perfectly fine. All keys and modifiers work as you would expect on a non-split board.
            • I am wondering if firmware could be modified to handle rf and bt communtication in the same time using only two nrf51822 modules so you won't need a receiver at all, is it doable?
  • bluetosis/[[http://README.md][README.md at d48f097cf91a4ac7e4b1535a771427ad46acf202 · joric/bluetosis]]
  • reversebias/mitosis: Firmware for nordic MCUs used in the Mitosis Keyboard
  • (flashquark's version) repne/mitosis: Firmware for nordic MCUs used in the Mitosis Keyboard
  • joric/bluetosis: Bluetooth firmware for the Mitosis keyboard (no dedicated receiver needed)
  • qmk_firmware/keyboards/mitosis at master · qmk/qmk_firmware

Layouts

Microdox   folded

Microdox

Hardware

Firmware

Layout

  • Ergodox EZ Configurator - Minidox AutoShift
    • it can actually be reduced even more
    • The , . / can be moved to the Sym layer (same positions) and, probably, alt can be moved to the layer too
    • extra layers (3, 4, 5) are available from the Sym layer
  • CMD layer can be removed: regular CMD key is enough and CMD+1,2,… combos can be done on the sym layer (so space+cmd+1,…)
    • but need to move arrow keys somewhere
    • Can remove media layer too, I don't use it much
    • Can I do a sane OSM version for Minidox? Probably, will have to put OSM Shifts to the second thumb key (instead of tab and enter)
  • I feel like OSM might be the best speed typing option
    • dual function keys introduce some delays to deal with and can interfer with regular typing
    • AutoShift is nice, but Every Capital Letter require a longer Keypress, so it slows the typing down.

Problems (and some solutions)

  • How to debug and fix LEDs
    • how to debug this? some might be not soldered properly, some might be burnt
      • solder conroller first, so the board has power
        • LEDs have common VSS (power) and GND (ground)
        • LEDs are connected in a row
          • Controller pin -> LED 1 IN - LED 1 OUT - LED 2 IN - LED 2 OUT - …
            • Controller pin is TX/D0 - can be checked in QMK, config.h for the keyboard (but all boards that I’ve checked use D0 to control backlight LEDs)
            • Controller sends a data package containing commands for all LEDs, one by one - first LED takes out its data and passes the rest to the output (there is a controller inside the LED too)
            • So if one LED does not work, all LEDs after it won’t work too
          • If nothing works: it is possible to check if there is a signal with LED strip (I used 6 LEDs) by soldering it to controller legs (VSS, GND, TX)
            • Make sure to connect TX to DIN (data IN) on the LED strip - I first connected it to DOUT and was wondering why it does not work
            • Do not connect long strip - it consumes too much current
      • solder first LED, check it it works, then next one and so on
        • cover all pads with solder, then add flux on top, then put the LED on top
        • for SK6812 mini, it is possible to heat two pads at the same time
      • if LED does not work
        • it can be the output of the previous LED that has bad joint
        • try to gently press over the corners of the LED to see if it lights up, often the bad joint can be found this way
        • measure the voltage with multimeter with power on (measure between any GND controller leg and LED pads)
          • VDD (power) leg should have around 4.8V
          • VSS (ground) should have around zero
          • IN will have small value, near 0.10, when measuring in 600mv range, we can see that the value changes when the brightness changes (I tested with breath effect)
          • OUT - same (and same as IN for the next LED)
          • Note that SK6812 does not have legs, so we can only do measurements on PCB pads, but can not check on LED pads (so can not make sure if the solder joint is good)
        • make a visual tester out of LED strip
          • I had 6 LEDs, but one led should be enough
          • it is easy to solder wires to the strip pads
          • I connected power and ground wires to controller legs and used IN wire as a tester, by toching the IN and OUT pad for installed LEDs (so I can find where the signal breaks)
      • Easy way: use LED strip instead of soldering LEDs onto PCB
        • The strip can be cut in smaller pieces that can be connected together with wries
    • katiekat12/20/2020
      • Well I'm all out of leds. still only 2 work
      • Tried replacing the second one that was working too
      • kdb42412/20/2020
      • You have a multimeter?
      • You can validate solder joints with them.
      • Curious if you are on the easy solder LED's or the older ones with no legs.
    • katiekat12/20/2020
      • there has to be something I'm doing wrong here. I've been through 15 leds just to get 2 of them working so far
      • and I'm following all the tips in that pinned message. low temp and everything
      • kdb42412/20/2020
      • It's possible that you are not killing them, but they just aren't making a solid connection. If the previous LED has it's DOUT pin not properly connected, it can make you think that the led after it is wrong, when it's not.
    • Barrington C12/05/2020
      • Hey peeps, do you guys possibly know why my strip doesn't work on startup but I can jump individual LEDs by pressing the Din/Do slot to the opposite strips +5V
      • I assume it's a short, but why would the LEDs stay lit after jumping
    • crkbd/[[http://buildguide_en.md][buildguide_en.md at master · foostan/crkbd]]
      • Some LEDs not turning on
      • If some LEDs aren't turning on, check the first LED not turning on or the one before it.
      • Here are some things to try out:
        • Make sure the LED is soldered correctly. Check the pads to see if it looks like they have a proper connection.
        • Check the LED orientation. Use the pictures above the see the correct orientation. Since the first LED is soldered with its back against the PCB, you might have to determinewhat the orientation should look like from the front using LEDs 7-27 (just double check that they are oriented correctly first).
        • If both of the above looks good, chances are the LED was damaged during soldering. Either replace it directly or use the diod mode of a multimeter to test the connectivity. One way to do this is by simply comparing to some of the other LEDs you have soldered. Choose two of the LED's pads (out of the four available) and compare the reading to that of some of the other LEDs (taking care to measure the same pads with the same needles of your multimeter). Work your way through all combinations of pads and needles. If the differ, you either have a broken LED or bad connectivity. Or simply desolder the LED directly, might be quicker. :)
    • Help with adding RGB strip : olkb
  • No rgb LEDs are on the right side
    • on the right side - also checked with multimeter, resoldered problematic places, but still no leds were working, sometimes the third one lighted red, but that was not stable
      • tried to debug this by removing them one-by-one, no luck, even when only one has left
      • resoldered this one (the first, under the controller) a few times and one of the pads on the PCB went off
      • so left it without the backlight for now. I saw a video with some tips on how to restore the pad, may try that later.
        • the basic idea - wire from the controller's leg to one of the LED pads, but in this case it is better to get LEDs with legs (there are similar LEDs, but with legs that should be easier to solder)
        • See "katiekat12/20/2020" above: Curious if you are on the easy solder LED's or the older ones with no legs.
        • Boardsource - LED (SK6812 Mini-e)
        • and I have these - Boardsource - LED (WS2812B)
          • or maybe just SK6812 (not Mini-e) which seem to be similar to WS2812B
          • note: in the firmware there is a WS2812B comment, some adjustments might be needed
          • It is also possible that the controller leg that works with LEDs is not soldered properly. Need to check which leg it is and try to verify with multimeter. Or just resolder it.
          • tried soldering mini-e with wires, doesn't work (one led)
          • tried to solder 6x led strip directly to elite c - doesn't work
    • next: socket another pro micro, try how it works with pro micro
      • I have an impression this is either a software problem
      • or this pin does not work on elite c (D3/TX0 as I understand)
      • or this is a wrong pin
      • Also: try led strip on the other half
      • Also: try connecting the led strip to arduino
  • Only two LEDs are working on the left side, no leds on the right
    • on the left side - using multimeter found all problematic connections, resoldered them and now all leds are working
      • multimeter is in the diode testing mode
      • black multimeter pin to GND (either on the controller or on the GND LED leg), check other legs with red multimeter pin - two of them are showing something like 1.6 and the third is 1.4 (values can wary)
      • One or more RGB LEDs do not work properly or at all – [[http://splitkb.com][splitkb.com]]
        • the GND and VSS is common for all diodes
        • Some keys were not working on the left side - forgot to solder the switch sockets on one side (easily fixed by soldering them)
  • TRRS jacks were not soldered properly - one went off when I unplugged the cable from it and I was able to take off the other one with hands, shaking it back and forth a bit, resoldered, seems to be good now
    • Not really, went off again
    • Resoldered, this time first added flux onto the jack legs and covered with solder, then soldered to the PCB
  • OLEDs were showing the upside down images, fixed in firmware:
    • in keymaps/cole/keymap.c
    • #ifdef OLED_DRIVER_ENABLE
    • oled_rotation_t oled_init_user(oled_rotation_t rotation) {
      • if (!is_keyboard_master()) // <-–— added ! before is_keyboard_master()
        • return OLED_ROTATION_180;
        • return rotation;
        • }
        • Will need to copy cole`s keymap and make my own with these changes
        • Probably this is also a result of making the right half to be main
        • nice!nano
  • the third row on the left half stopped working
    • looks like one of the nice!nano pins does not work anymore (did I burn it?)
      • I think something did burn when I tried to investigate power consumption
    • the row is controlled with B4
      • in QMK for microdox MATRIX_ROW_PINS { B2, B6, B4, B5 }
      • in ZMK for microdox - pro_micro_d 16, 10, 8, 9
      • B4 = 8 (see pinout below)
      • testing with multimeter, voltage on row pins is 2.7 when key in this row is down, but for the broken pin, it is 0.27 (so it kind of still works, but incorrectly)
    • option: reroute B4 to E6 (near B4, unused) -> no B4 is in use
      • Used pins
        • #define MATRIX_ROW_PINS { B2, B6, B4, B5 }
        • #define MATRIX_COL_PINS { F4, F5, F6, F7, B1 }
        • #define SOFT_SERIAL_PIN D2
        • #define RGB_DI_PIN D3
      • Used pins (zmk)
        • = <&pro_micro_d 16 (GPIO_ACTIVE_HIGH | GPIO_PULL_DOWN)>
        • , <&pro_micro_d 10 (GPIO_ACTIVE_HIGH | GPIO_PULL_DOWN)>
        • , <&pro_micro_d 8  (GPIO_ACTIVE_HIGH | GPIO_PULL_DOWN)>
        • , <&pro_micro_d 9  (GPIO_ACTIVE_HIGH | GPIO_PULL_DOWN)>
    • option: use this nice!nano for Kyria -> no, B4 is in use
      • #define MATRIX_ROW_PINS { B4, E6, D7, D4 }
      • #define MATRIX_COL_PINS { B6, B2, B3, B1, F7, F6, F5, F4 }
      • so not an option, Kyria also uses B4
    • option: use this nice!nano for Planck -> no, B4 is in use
      • #define MATRIX_ROW_PINS { A10, A9, A8, B15, C13, C14, C15, A2 }
      • #define MATRIX_COL_PINS { B11, B10, B2, B1, A7, B0 }
    • solved: changed B4 (6 in ZMK) to E6 (7 in ZMK) in firmware code, disconnected pin
      • app/boards/shields/microdox/microdox_left.overlay
      • row-gpios
        • = <&pro_micro_d 16 (GPIO_ACTIVE_HIGH | GPIO_PULL_DOWN)>
        • , <&pro_micro_d 10 (GPIO_ACTIVE_HIGH | GPIO_PULL_DOWN)>
        • // change pin D8 to D7 as output 8 (B4) is broken on the left side.
        • // Note that it is still 8 on the right side
        • , <&pro_micro_d 7 (GPIO_ACTIVE_HIGH | GPIO_PULL_DOWN)>
        • , <&pro_micro_d 9 (GPIO_ACTIVE_HIGH | GPIO_PULL_DOWN)>
        • ;
  • And now the first column on the right side does not work too
    • Seems to be similar: the pin (B1, 15, marked 113 on nice!nano) only outputs 0.5V (other pins output 3.3V)
    • Can move it to B3? Why this keeps happening?
    • solved: cut off B1 pin, added a jumpter to B3, changed accordingly in firmware
      • app/boards/shields/microdox/microdox_right.overlay
      • col-gpios
        • // = <&pro_micro_d 15 GPIO_ACTIVE_HIGH>
        • // change pin D15 to D14 as output D15 (B1) is broken on the right side.
        • = <&pro_micro_d 14 GPIO_ACTIVE_HIGH>
        • , <&pro_micro_a 0 GPIO_ACTIVE_HIGH>
        • , <&pro_micro_a 1 GPIO_ACTIVE_HIGH>
        • , <&pro_micro_a 2 GPIO_ACTIVE_HIGH>
        • , <&pro_micro_a 3 GPIO_ACTIVE_HIGH>
        • ;
  • And OLED stopped working on the left side, looks like something is wrong with VCC connection, multimeter shows 0.6 (it is 3.3 on the right side) - now it works again, probably was a software problem
    • can this be software issue (after I configured a hotkey that diables/enables power output for OLED), maybe it has saved somewhere (although, I also tried to flash the reset firmware)
    • can try testing OLED separately, with Arduino
    • or just exchange OLEDs with the right side
  • Next one: controller on the left side stopped responding (not workIng via USB, not visible via BT, not reacting to reset button or to GND/RST short)
    • Troubleshooting https://docs.nicekeyboards.com/#/nice!nano/troubleshooting
      • Was going to try ST-Link V2 method (I got it with Mitosis)
      • Desoldered battery first and removed controller from the board - tried to connect via USB and it started working - shorting GND and RST put it into bootloader mode
      • Also the power (orange) led started to flash quickly (usually it does not flash), although everything was working, strange, but it went normal later on its own
    • Just for the case, I reflashed bootloader (simpler method without ST-Link, from the troubleshootIng article)
      • Follow the installation section here. Most likely you’ll just need to run pip3 install –user adafruit-nrfutil.
      • Download the DFU pkg of the nice!nano bootloader.
      • Connect your nice!nano and put it into the bootloader using a double-tap reset.
      • Run the following command in your terminal:
      • /Users/seb/Library/Python/3.9/bin/adafruit-nrfutil –verbose dfu serial –package ../nice_nano_bootloader-_s140_6.1.1.zip -p /dev/tty.usbmodem144201 -b 115200 –singlebank –touch 1200
        • To fInd the serial device name, I compared `ls /dev/tty*` output before and after connecting the nice!nano via USB
  • One or more RGB LEDs do not work properly or at all – [[http://splitkb.com][splitkb.com]]
    • The steps in this guide apply to split keyboards that use WS2812B RGB LEDs or SK6812MINI RGB LEDs.
    • With the default firmware, the default RGB color will be red. All LEDs should light up red when you plug in your keyboard, provided that RGB is enabled in the keyboard and is switched on.
    • Inspect and reflow the joints on the first LED that doesn't work: Check all connections on the first LED that does not behave correctly. Do all solder joints look okay? If not, try reflowing the joint by applying heat to it with your iron.
    • Inspect and reflow the joints on the LED before it: Check all connections on the LED before the LED that does not behave correctly. So if RGB4 does not work, check the connections on RGB3. Check the solder joints, and rework them as needed.
    • Replace the first offending LED: Does it still not work? Try replacing the first offending LED with a new one. Your kit should include several spares.
    • Replace the LED before it: If that doesn't work either, check the first LED before the offending LED, and replace it.
    • If it then still does not work, check the connections on your microcontroller for bridges and proper connections, and rework as needed.
    • If the first LED in the chain doesn't work, marked with RGB1, the issue might be with a
    • microcontroller pin. You can view the schematics for your keyboard in the Technical Information category to see which pin might have a bridge or cold joint. On the Kyria, this is pin D3.
  • Check led configuration - they are too bright
    • RGB Lighting - QMK
      • RGBLIGHT_LIMIT_VAL 255 The maximum brightness level
    • Probably can aslo set the initial "value" (V in HSV) to set the brightness
      • > Changing the Value sets the overall brightness.
  • Also, if i use with nice nano, it would be good to turn them off to save energy

Kyria   folded

Keyboards with keywell: Glove 80, Dactyl etc   folded

Dactyl and family   folded

clipboard-20261107T224411.png

Keyboards (unusual)   folded

Keyboards   folded

Plank and Preonic

clipboard-20261109T000020.png

Corne

clipboard-20261109T000150.png

gBoards - gergo, georgi, ginny

Lily58

ATREUS

Gherkin

Splayed

More keyboards

Various, not only mechanical

Keyboards with trackpad / trackball / touchpad   folded

Keyboard mounting / tilt solutIons, stands, tenting solutions   folded

Trackball, touchpad, mouse   folded

Keyboard Firmware   folded

QMK   folded

ZMK (bluetooth firmware)   folded

KMK (python-based firmware)   folded

Lists of Keyboard Firmware

  • awesome-mechanical-keyboard/firmware.md at master · Keycapsss/awesome-mechanical-keyboard
    • Firmware
    • BlueMicro_BLE - A Bluetooth Firmware for the NRF52832.
    • Bluetosis - Bluetooth firmware for the Mitosis keyboard.
    • EasyAVR - is a keyboard firmware and keymapper GUI for custom keyboards based on USB AVRs.
    • Kaleidoscope - Flexible firmware for Arduino-powered keyboards.
    • Keyplus - An easy to use keyboard firmware with support for wireless and wired split keyboards.
    • KMK - is a feature-rich and beginner-friendly firmware for computer keyboards written and configured in CircuitPython.
    • Mechy - Arduino compatible, plugin based.
    • MK32 - Simple BLE keyboard for ESP32
    • nrf52-keyboard - A ble keyboard firmware using nrf52810/52832
    • Python-Keyboard - A highly extensible firmware written in Python, based on CircuitPython, with RGB, USB and Bluetooth.
    • QMK - A keyboard firmware based on the tmk_keyboard firmware for Atmel AVR and ARM controllers.
    • TMK - Keyboard firmwares for Atmel AVR and Cortex-M.
    • ZMK - MIT-licensed firmware built on top of the Zephyr RTOS that is "wireless first".
    • kbd-prettier - Automatically format your keyboard layout
    • Keyboard Firmware Builder - Online QMK Firmware Builder (2+ years behind QMK firmware master)
    • Q2K - A python based utility for parsing QMK Firmware keymaps to various outputs
    • QMK Configurator - An open source configurator for QMK Firmware
    • qmk_emote_macro_generator - Easily generate QMK macro/leader sequences for arbitrary unicode sequences.
    • TMK Firmware Builder - Online TMK Firmware Builder
  • help-14/mechanical-keyboard: DIY mechanical keyboard and where to find them
    • EasyAVR - EasyAVR is a keyboard firmware and keymapper GUI for custom keyboards based on USB AVRs. It is powerful but also really easy to use.
    • The VIA - QMK based firmware for the view app.
    • Anne Key - Firmware for Anne Pro Keyboard written in Rust.
    • Lotlab/nrf52-keyboard - TMK based keyboard firmware for nRF52 series, now support both nRF52810 and nRF52832.
    • Lotlab/nrf51822-keyboard - This is a firmware based on nrf51822 Bluetooth keyboard, which uses nRF SDK 10.0 as the underlying hardware driver, and uses TMK keyboard library as the upper part of the keyboard function.
    • Polymer firmware - Polymer keyboard firmware.
    • Pipit keyboard - Firmware and config tools for chording keyboards.
    • python-keyboard - A highly extensible firmware written in Python, based on CircuitPython, with RGB, USB and Bluetooth. similar to TMK/QMK.
  • Firmware - Keebfol.io (firmware list)
  • firmware - MechanicalKeyboards (firmware list)

Rust Firmware

Other

Keyboard Stores   folded

Tags: kbd

Tags