Gabe/techWebsite
1
0
Fork 0
Code Issues8 Pull requests Projects1 Releases Wiki Activity

added a paragraph with background info on qmk.

Browse source
This commit is contained in:
Gabe Venberg 2025-03-23 23:43:02 +01:00
parent a194ef70a9
commit 487b164e43
1 changed files with 16 additions and 4 deletions

20
content/posts/rmk-ferris-sweep/index.md
View file

@ -11,11 +11,20 @@ a keyboard firmware written in Rust.
Given that my [Ferris Sweep](../ferris-sweep-keyboard/) has a Ferris the crab logo on the silkscreen,
it felt only fitting that I flash it with RMK.
However, RMK is a much newer project than [QMK](https://qmk.fm/).
QMK provides premade configurations for almost keyboard out there (or at least, every keyboard that allows flashing your own firmware),
allowing you to build someone else's design and get straight to designing a keymap, without having to fuss about matrices or pin mappings.
Since I first built it, my Ferris Sweep has been running [QMK](https://qmk.fm/),
a very mature C-based keyboard firmware.
QMK is a great project, and doing basic keymaps for an already-supported keyboard is straightforward and well-documented.
However if you are designing your own keyboard, or want to use certan advanced QMK features,
you wont be able to use QMKs JSON-based 'data driven' features.
Instead, you will have to use its C macro based configuration,
which can be daunting and may require understanding QMKs complex build system.
RMK is a much newer project than QMK.
QMK provides premade configurations for over 1,000 keyboards,
allowing you to build someone else's design and get straight to designing a keymap,
without having to fuss about with matrices or pin mappings.
RMK has no such definitions, just documentation of how to write them and a few example projects,
making this journey to put it on my Ferris Sweep interesting enough to write about.
which made the journey to put it on my Ferris Sweep interesting enough to write about.
## Configuring the firmware
@ -92,6 +101,9 @@ It did not feel the exact same as QMK,
I think some of the timings on tap-hold and debouncing might be different,
but, apart from a few repeated keys (which should be fixed once configurable debouncing [lands](https://github.com/HaoboGu/rmk/issues/289),
it was a very serviceable keyboard firmware.
Obviously, being a much newer project than QMK,
it has not yet implemented some of the more advanced features QMK has,
such as support for displays, per-key RGB, or pointing devices.
The next release is focusing on input devices,
so in the future RMK will also support keyboards with encoders and pointing devices like trackballs and touchpads.