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)