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

finalizing rmk article.

Browse source
This commit is contained in:
Gabe Venberg 2025-03-29 13:06:51 +01:00
parent 292f9635db
commit bc2eac981c
1 changed files with 7 additions and 7 deletions

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

@ -1,7 +1,7 @@
+++
title = "Rust on the Ferris Sweep"
date = 2025-03-25T17:28:15+01:00
draft = true
date = 2025-03-29T13:06:15+01:00
draft = false
[cover]
image = "keyboard-with-rust"
+++
@ -14,7 +14,7 @@ it felt only fitting that I flash it with RMK.
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,
However if you are designing your own keyboard, or want to use certain 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.
@ -61,7 +61,7 @@ but I wasn't doing anything fancy enough to justify that.
The first part of the `keyboard.toml` contains some basic metadata about your keyboard,
like its name, USB ID, and what microcontroller it uses.
I lifted all this info from [QMK's Ferris Sweep info.json](https://github.com/gabevenberg/qmk_firmware/blob/personal/keyboards/ferris/sweep/info.json) for consistencies sake.
I lifted all this info from [QMK's Ferris Sweep info.json](https://github.com/gabevenberg/qmk_firmware/blob/personal/keyboards/ferris/sweep/info.json) for the sake of consistency.
Then I had to configure the pin mappings, defining which pin correspond to each key (in the Ferris Sweeps case, as it is a direct wire, where each pin corresponds to exactly 1 key),
or defining which pins correspond to rows and columns of the keyboard matrix (in the case of most larger keyboards.)
@ -92,7 +92,7 @@ My [keymap](https://github.com/gabevenberg/qmk_firmware/blob/personal/keyboards/
other than its extensive use of layers and tap-hold Keybinds.
(keybinds that do a different thing on being held down than they do on tapping them)
All the features I use are [well documented](https://haobogu.github.io/rmk/keyboard_configuration.html#layout) by RMK,
so while porting the keymap was tedious, it was not especially difficult or noteworthly.
so while porting the keymap was tedious, it was not especially difficult or noteworthy.
### `vial.json`
@ -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.
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, 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 its still Rust.
its running a modified version of RMK from my own fork, 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,