Link to Macropad firmware containing KDL: https://github.com/2004Island/macropad-circuitpython
Three or four months ago, my friend (Varun Sreedharan) approached me about writing firmware for a macropad he had created. It uses a custom PCB, a Raspberry Pi PICO, low profile switches, an oled I2C display, and a few 3D printed parts to create a surprisingly satisfying to use piece of hardware.
I started by writing a parser for a language I named Keyboard Description Language, or KDL. Other macro pads and keyboards I’ve seen use clunky and repetitive methods like JSON or XML files for defining the purpose of all the keys, and require them to be included in the firmware at compile time. By virtue of using CircuitPython, KDL is able to load configuration files dynamically, and reloads as soon as the new file is finished copying to the PICO’s flash.
KDL uses a layer system (called states) to handle multiple definitions for each key. States can be switched between by keys, and dictate which definitions each key should use. Keys are defined as key row,col: [actions/attributes] which allows for quick definition of each key using minimal repetition. This is then followed by comma separated actions and/or attributes, which there can be as many of as you want. Attributes define the color of the built-in LED for each key, and when/if the state of that LED should be toggled. Actions allow the key to set the state of the macropad, send keypresses to the connected computer, or send output to the display. All in all this creates a very concise and forgiving language to easily define how you want your macropad to work.
In my code I have been calling KDL an interpreter, but I don’t know what to classify it as really. It’s a description language, but it has an entire event handler that maps key presses to their associated actions so the firmware using it doesn’t need to be concerned with states. This makes it much more than a dumb parser, but I am hesitant to call it a full interpreter. I feel like this is a slightly more accurate term for it, so I will be calling it an interpreter until I can think of something more fitting.
I got all of this code working with a basic driver program to test it on the numpad of my laptop’s keyboard last December. Shortly after I got the first revision of the hardware (Thanks Varun!) and started working on integrating it into the firmware.
>> Home