Rust on the Ferris Sweep

Summary

The other day, I stumbled upon RMK, a keyboard firmware written in Rust. Given that my Ferris Sweep has a Ferris the crab logo on the silkscreen, it felt only fitting that I flash it with RMK.Since I first built it, my Ferris Sweep has been running QMK, 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 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.RMK is a much newer project than QMK. QMK provides premade configurations for over 1,000 keyboards, allowing you to build someone else’s design and get straight to designing a keymap, without having to fuss about with matrices or pin mappings. RMK has no such definitions, just documentation of how to write them and a few example projects, which made the journey to put it on my Ferris Sweep interesting enough to write about.Configuring the firmware#Now, the setup between RMK and QMK is a bit different. In QMK, you clone the entire QMK repo, make any keymap modifications you want, and compile. RMK, being written in a language with a decent package manager, just has you make a repo from a small template that depends on the RMK crate. RMK provides a tool, rmkit, to help you setup this repo.I started by installing rmkit and a few embedded tools via cargo, running:cargo install rmkit flip-link elf2uf2-rs probe-rs-tools cargo-make cargo-binutils llvm-tools Then I ran rmkit init and answered a few questions about my keyboard, which generated my initial template. From there, I modified .cargo/config.toml to use elf2uf2-rs, as my keyboard does not have an exposed debug header, which would be needed for probe-rs. The docs mentioned I may have to modify a file called memory.x...