PRK is a PicoRuby-based keyboard firmware running on RP2040 chips.
Published April 17, 2022
Hitoshi Hasumi's PRK is an alternative keyboard firmware for RP2040-based boards, utilizing the PicoRuby language.
To clarify things up: PicoRuby is the Ruby interpreter for one-chip microcontrollers, and PRK firmware is a keyboard firmware framework written in PicoRuby.
As noted by Hitoshi, PicoRuby is the preceding project:
Firstly, I've just wanted to make Ruby eligible for one-chip microcontrollers because my job relates to some IoT systems. But at the same time, I remember Matz, the founder of Ruby language, said that it'd be great if Ruby could be used in a DIY-keyboard. (Actually, Matz himself is also a DIY-keyboard lover.) This is the reason that I started the PRK project just after PicoRuby became capable enough – Hitoshi.
I've planned to feature PRK for a long time since it was used on several keyboards introduced on this blog already: e.g. the C-13X by flurples, m.ki's Cool836pico or policium's Grin Type-R, just to name a few.
It's hard not to notice, at least as of writing this, that all the contributors and users are based in Japan so this firmware can be considered to be a project of the Japanese DIY keyboard community.
I mainly tweet in Japanese and actively support those who are having a problem with PRK on Twitter. However, I'd be really glad if people all over the world would use the PRK Firmware. I will support you in English! – Hitoshi.
But that's enough talk about the background, let's see the nitty-gritty details. Here is a video presentation by Hitoshi himself introducing PicoRuby and the PRK firmware with some examples at Rubyconf 2021, Denver:
TMK, QMK, KMK, ZMK, PRK, etc. Why would you need one more keyboard firmware and where can PRK be plotted on the map of all the firmwares with regards to mission, usage and features?
PRK vs QMK vs KMK
Up until last year, the most famous firmware (de facto standard) was QMK (which started out as a fork of TMK). QMK is written in C, and – many user may not be aware of this but – you write your keymap in C accordingly. Despite all the tools available, the QMK workflow remained a real PITA, especially for real custom keyboards with unique matrices.
No wonder the appearance of Raspberry's RP2040 microcontroller and development boards like the Pi Pico, Adafruit KB2040, Tiny2040, RP2040-Zero, RP2040 Stamp, etc., combined with CircuitPython and KMK was received with acclamation.
PRK is positioned along those lines and, with its target chip being the RP2040, it may be the closest relative and an alternative to KMK. With the main difference being that while KMK/CircuitPython uses Python, PRK/PicoRuby uses Ruby as its programming language to achieve pretty much the same thing.
Other than that, both firmwares execute your program directly on the keyboard without compilation. Changes made to the program are immediately reflected in the keyboard's behavior.
When to choose PRK?
So, at least if you want to delve deeper into custom functions, choosing one firmware over the other comes down to your choice of programming language.
Being familiar with the language is not so important when your keymap consists of only predefined keycodes but it gets more critical if you're up to write some unique functions. After all, with all the power and resources of the RP2040, a single keypress can launch a whole array of programs – as opposed to merely generating a humble alphanumeric character. In this sense, QMK is for masters of C, KMK for Python-heads and PRK for Ruby-wizards.
Some friends of mine said that PRK is better than KMK in terms of response to inputs and they feel comfortable using PRK. Also, I think PRK's just improved farther in that point because it introduced debounce algorithm today. :D If you are annoyed by bouncing switches, please try PRK Firmware – Hitoshi.
The installation process is the same as with CircuitPython and KMK, which means you're likely done in 2 minutes. All the development boards sporting the RP2040 chip appear like flash drives so flashing the firmware and updating the keymap means simply copying files.
No compilation needed, there's no cumbersome or confusing toolchain involved like with QMK's local building environment.
Btw, here is the Github repo in case you can't wait to try PRK: https://github.com/picoruby/prk_firmware
Let me include another video of Hitoshi. Although this one is in Japanese, the slides are in English and this one contains more tips:
Features of the PRK firmware
From the feature list, PRK is capable of driving non-splits and symmetrical splits via UART.
It handles macros, RGB LEDs, rotary encoders, etc. And as already mentioned, it introduced debounce algorithms today. Yeah, a new version was released just during writing this piece. See the latest changes here.
Media keys, OLED displays, mouse/trackball and I2C are not yet implemented but some of these are in the main focus of further development.
PRK will introduce VIA feature in the next version. It means you will be able to configure a keymap trough Remap. Then Mediakeys, Mouse/Trackball, and Gamepad are upcoming features – Hatoshi.
PRK is developed by crazy people, so they implement maniacal features before they implement normal features – @policium.
@policium refers here e.g. to duplex matrix support – and no, this is not the duplex matrix we westerners talk about. (More on this in a later post.)
As a summary: PRK is another alternative firmware for keyboards sporting the RP2040 microcontroller. Its interchangeability with KMK makes it easy to test so feel free to give it a try!
Published on Sun 17th Apr 2022. Featured in KBD #74.