From 9f4c317274200bb0c08f43fe2d08640cb91c07ac Mon Sep 17 00:00:00 2001 From: Gabe Venberg <gabevenberg@gmail.com> Date: Mon, 10 Mar 2025 17:42:23 +0100 Subject: [PATCH] started the rust on ferris sweep article. --- content/posts/rmk-ferris-sweep/index.md | 47 +++++++++++++++++++++++++ 1 file changed, 47 insertions(+) create mode 100644 content/posts/rmk-ferris-sweep/index.md diff --git a/content/posts/rmk-ferris-sweep/index.md b/content/posts/rmk-ferris-sweep/index.md new file mode 100644 index 0000000..74f0ed7 --- /dev/null +++ b/content/posts/rmk-ferris-sweep/index.md @@ -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)