One of my (@wez) hobbies is making custom mechanical keyboards. This repository is where I'm collecting my tools. It includes:

• A FreeRTOS-based firmware for keyboards
• A keyboard-layout-editor.com (KLE) parser and code generator that can take layout information and generate the keymap data for use with the firmware.
• Can target boards supported by Arduino (via the FQBN), and directly target the AVR toolchain. Adding support for other targets is pretty straight forward

Things planned for the future:

• Generate SKIDL schematics and a PCB design from KLE data
• Generate plate/case design files from KLE data

Everything is driven via the clacker.py script in the root of the repo. Running it for the first time will pull in some python dependencies needed to run some of the subcommands.

Running clacker.py build will build all of the possible targets. You can specify a target from a subdirectory using a command like clacker.py build src/firmware/flutterby:flutterby. Targets are defined by the info.py files that are found throughout the repo. In the example given already, the portion of the name to the left of the colon corresponds to the subdirectory containing the info.py file and the portion to the right of the colon corresponds to the name property of one of the targets defined in that info.py file.

You can find a list of possible targets by running:

clacker.py list-firmware

Running clacker.py test will run all the unit tests. The unit tests are built with the host system compiler and are intended to verify architecture neutral components.

You can find a list of possible tests by running:

clacker.py list-tests

This subcommand will build and upload a firmware to the device. For example:

./clacker.py upload src/firmware/flutterby:flutterby --port /dev/cu.usbmodem14?1

will build and upload the flutterby firmware to the device on the specified port.

Why another keyboard firmware? There are a couple of properties that I strongly desire and that are not easy to add to existing firmware projects, but the main thing for me is Low power utilization. Other projects are optimized for USB bus powered devices and use very busy loops. I'm aiming for low power bluetooth devices and desire the ability to put the device to sleep when possible.

In addition, I'd like to take advantage of more modern C++ features to help make the firmware a bit more composable.