Under the hood, cargo-embed, knurling's probe-run, and Humility are all built atop probe-rs (https://probe.rs/) to provide debugging - I think in this case it's actually a great example of cooperation between projects! Probe-rs has received PRs from both Knurling and Oxide devs; it provides the common interface to use various types of debug hardware and talk to various types of microcontroller cores, essentially replacing OpenOCD.
That Raspberry Pi Pico code snippet is slightly unusual in that the `unsafe` there is because the library isn't sure that 1<<25 is a safe value to write to this register - for example, if the register was a DMA memory address pointer, it's not safe to allow directly writing arbitrary pointers to it since it would allow memory access outside of Rust's memory model. It's not to do with the potential atomicity requirement.
The exclusivity/atomicity in that case is ensured because the method is called on "p.SIO", an object that can't be accessed from both ISRs and the main code at the same time in safe Rust (because it doesn't "implement Sync"). If both an interrupt and the main thread need to access that peripheral, you need to provide some way of sharing it - either using `unsafe`, or in safe code by using a synchronisation primitive such as a critical-section based Mutex that provides that guarantee.
The book chapter you've linked to starts out by demonstrating what is essentially how you'd write this in C and thus requires unsafe, but it builds towards a safe solution - when using either the Atomic* variables (in the Atomic Access section) or mutexes (in the Mutex section), `unsafe` isn't required any more; the user's code is only safe Rust which provides synchronised access to the shared state between the main thread and the ISR.
In other words, the benefit over C is that it _is_ now possible to use only safe Rust to access memory and peripherals from both interrupts and the main thread, and that safe Rust is itself ensuring you can't cause race conditions. The unsafe option is there as a building block for those safe abstractions.
> So at the end of the day it's just C with different syntax, and a lot more hoopla. You've made everything mutable and unsafe.
Perhaps that chapter isn't getting the right message across then. The goal is to completely avoid applicaton code having to make things mutable and unsafe by providing the right abstractions that allow safe Rust to get the same work done while ensuring there are no races.
I'm about 20kloc in to a (not public) nMigen project, including a UDP/IP stack, various peripheral drivers, a DSP pipeline, and some custom networking code. So far I think "do the advantages of being able to metaprogram outweigh..."is a resounding "yes", but I came to it with extensive Python experience so it feels like a very natural fit to me, and given how other attempts at embedded metaprogramming go (Tcl...) I'm not sure Python is easily beat. Being able to integrate with numpy for DSP work, pytest for simulation and testing, Python packaging (such as it is) for distributing modules and managing dependencies and versioning, and simulating inside Python too are all additional compelling advantages.
nMigen is a pretty fledgling project so there aren't a ton of big projects in it yet, but for example Luna[0] (from the makers of the HackRF) implements a full USB stack including USB3 support, with enough abstraction that you can create a USB-serial converter inside your FPGA using two I/Os for full-speed USB and wire it into the rest of your project in about ten lines of Python[1].
Migen, the Python-based project nMigen is based off, has been around for longer and has some large projects, such as LiteX[2] which uses Migen to glue together entire SoCs, including peripheral cores such as GigE, DDR3/4, SATA, PCIe, etc, all written in Migen, and is pretty widely used. It also pulls in Verilog/VHDL designs (such as many of its CPU core choices) since it's easy to pull in those from the Python side.
