Nice article, but I wanted to point out that you seem to imply that Rust "mitigate(s) or completely eliminate(s)" deadlocks and race conditions. Neither of these is true:
Perhaps you were thinking about data races, which are unsafe and therefore not allowed by Safe Rust? The Rustonomicon (https://doc.rust-lang.org/nomicon/races.html) defines data races as:
- two or more threads concurrently accessing a location of memory
- one or more of them is a write
- one or more of them is unsynchronized
Possibly you knew all of this and just got carried away in your enthusiasm for Rust (very much shared!), but lest your readers think Rust is actual magic instead of merely amazing, it might be nice to clarify the article.
Can you recommend any resources on using the self test HW (assuming JTAG/SWD/GDB are all setup, although I'd love to see any recommendations on those as well)? I currently don't know anything about the trace macrocell.
Check the documentation for GDB and OpenOCD and the overviews from STMicro. You can poke things into memory, like peripheral configurations into peripheral registers. You can have the trace cell generate events on the debug port based on memory access or other events, analogous to Intel/AMD performance counters and iperf/xperf. It also implements breakpoints and code stepping in hardware.
To do full mockups you usually need an IO board that can drive pins, but you can also have the trace macrocell jump to code that sets an IO pin's internal driver high and triggers the input side of the IO port.
