Gabe/techWebsite
1
0
Fork 0
Code Issues 8 Pull requests Projects 1 Releases Wiki Activity

updated rmk article wtih prs that have been merged.

Browse source
This commit is contained in:
Gabe Venberg 2025-05-18 08:48:34 +02:00
parent 7af8724cea
commit 005ea95b1a
2 changed files with 6 additions and 7 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -73,7 +73,7 @@ the ATmega32U4, specifically for the Arduino Pro-Micro board.
QMK does some black magic at compile time in order to rewrite these pin mappings to their RP2040 equivalents,
but I was not able to figure out said magic in order to do the same by hand.
In the end, I cloned the [repo](https://github.com/davidphilipbarr/Sweep) for the Ferris Sweep itself and looked at the PCB design in Kicad,
Tracing where each pin went and cross referencing with the elite-pi (my specific RP2040 board) [usage guide](https://docs.keeb.io/elite-pi-guide) to get the pin number.
tracing where each pin went and cross referencing with the elite-pi (my specific RP2040 board) [usage guide](https://docs.keeb.io/elite-pi-guide) to get the pin number.
Another thing I had to do was define how the 2 microcontrollers in each half of the keyboard communicate with each other,
and define the pins that are used in that communication.
@ -83,8 +83,8 @@ This means it has to use whats called 'half-duplex' UART,
where a single wire is used for 2 way communication.
Luckily, RMK supports this mode of communication through the RP2040's [PIO](https://www.raspberrypi.com/news/what-is-pio/) feature.
Unfortunately, this ability to use half-duplex over PIO is only on RMK's master branch,
and has not made it into a stable release as of this writing.
This simply means I had to do some fiddling in the `Cargo.toml` file to instruct cargo to fetch the latest commit from git, rather than getting the latest published version of the package.
and has not made it into a stable release as of this writing (incorporated in 0.6.0).
This simply means I had to do some fiddling in the `Cargo.toml` file to instruct cargo to fetch the latest commit from git, rather than getting the latest published version of the package (this has since been incorporated in the 0.6.0 release).
After the *painful* process of tracing each pin and defining the pin mappings,
we can define the keymap.
@ -115,12 +115,12 @@ A day or 2 of investigation later revealed that the half-duplex serial implement
only used the RP2040's internal pull-up resistors,
which for my keyboard and TRRS cable were insufficient for a baud rate of 115200.
This was (temporarily) fixed by setting a lower baud rate in the RMK source code,
but for the long term, I've made a [PR](https://github.com/HaoboGu/rmk/pull/291) mirroring [QMKs solution](https://github.com/qmk/qmk_firmware/blob/6d0e5728aa61b442885d48caf49d29e5c60e8197/platforms/chibios/drivers/vendor/RP/RP2040/serial_vendor.c#L133) to this problem, which has since been merged.
but for the long term, I've made a [PR](https://github.com/HaoboGu/rmk/pull/291) mirroring [QMKs solution](https://github.com/qmk/qmk_firmware/blob/6d0e5728aa61b442885d48caf49d29e5c60e8197/platforms/chibios/drivers/vendor/RP/RP2040/serial_vendor.c#L133) to this problem (has been merged and released in 0.6.0).
But, after all that, I had a Ferris Sweep running Rust,
just as the silkscreen demands.
Granted, until the PR gets merged and a new release is cut,
its running a modified version of RMK from my own fork, but it's still Rust.
its running a modified version of RMK from my own fork(since the 0.6.0 release, I'm running stock), but it's still Rust.
The final firmware repo is [here](https://github.com/gabevenberg/ferris-sweep-rmk),
if you want to use it for your own RP2040, wired Ferris Sweep,
@ -131,7 +131,7 @@ or just want an example to help you along.
I then proceeded to use RMK for a few tasks, including writing this article.
It did not feel the exact same as QMK,
I think some of the timings on tap-hold and key 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),
but, apart from a few repeated keys (which should be fixed once configurable debouncing [lands](https://github.com/HaoboGu/rmk/issues/289)) (has been merged, but is currently master only.),
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,