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

started the rust on ferris sweep article.

Browse source
This commit is contained in:
Gabe Venberg 2025-03-10 17:42:23 +01:00
parent 7e49e9e89f
commit 9f4c317274
1 changed files with 47 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -0,0 +1,47 @@
+++
title = "Rust on the Ferris Sweep"
date = 2025-03-10T17:28:15+01:00
draft = true
+++
The other day, I stumbled upon [RMK](https://github.com/haobogu/rmk),
a keyboard firmware written in Rust.
Given that my [Ferris Sweep](../ferris-sweep-keyboard/) has a ferris the crab logo on the silkcreen,
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.
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.
I started by installing a few tools via cargo, running
```
cargo install rmkit flip-link elf2uf2-rs
```
Then I ran `rmkit init` and answered a few questions about my keyboard, which generated a template for me to further modify.
I modified `.cargo/config.toml` to use `elf2uf2-rs` as documented in the templates README, as I cant exactly set up a debug link on an already assembled keyboard.
The docs say I need to modify the `memory.x` file for my microcontroller, but I found the `rmkit` tool had already set it with the right contents.
Then came the hard work, configuring `keyboard.toml`.
I followed [the docs](https://haobogu.github.io/rmk/keyboard_configuration.html),
carefully started porting my [Ferris Sweep layout](https://github.com/gabevenberg/qmk_firmware/blob/personal/keyboards/ferris/keymaps/almost_default/keymap.json) to the `keyboard.toml`.
First off, for the keyboard metadata, I simply took from [QMK's Ferris Sweep info.json](https://github.com/gabevenberg/qmk_firmware/blob/personal/keyboards/ferris/sweep/info.json).
Then for the tricky part. We have to define our pin mappings using the peripheral names as [defined by embassy](https://docs.embassy.dev/embassy-rp/git/rp2040/struct.Peripherals.html)
This is hard because the QMK mappings given in the [keyboard.json](https://github.com/qmk/qmk_firmware/blob/master/keyboards/ferris/sweep/keyboard.json)
are for the Aurdino pro-micro pin names,
and I wasn't able to figure out what magic QMK does to convert those into the RP2040 [Elite-pi](https://keeb.io/products/elite-pi-usb-c-pro-micro-replacement-rp2040) equivalents.
In the end, I just cloned the Ferris sweep [repo](https://github.com/davidphilipbarr/Sweep) and opened the files in kicad,
cross referencing the schematic with the elite-pis [usage guide](https://docs.keeb.io/elite-pi-guide)
One stumbling block is that the Ferris sweep ran out of pins to use full-duplex UART, and therefore only uses half-duplex.
To solve this, RMK supports (only on the RP2040) a PIO driver for half duplex, gated behind a crate feature in `cargo.toml`.
With it, we can set our Tx and Rx pins to the same pin.
After the painstaking process of tracing all the pins and putting them in the matrix, we can define the keymap.
My [keymap](https://github.com/gabevenberg/qmk_firmware/blob/personal/keyboards/ferris/keymaps/almost_default/keymap.json)
is a bit complex, so it took some time to port.
The final file looked like [this](https://github.com/gabevenberg/ferris-sweep-rmk/blob/main/keyboard.toml)