Felipe Balbi

What did the boot ROM just do to my RAM?

2026-06-11T09:00:00+00:00

A while back I was trying to get teleprobe</a> to run a test suite on an RT685-EVK. Teleprobe’s trick is that it takes your test, compiled as a standalone firmware binary linked to execute directly from SRAM, loads it into the target’s RAM over the probe, and runs it from there — flash never gets touched. On every board I’d used it with before, it just worked. On the RT685, every run ended in a HardFault before the first test got a chance to do anything.

The diagnosis took longer than the bug deserved. The RT685’s boot ROM was power-cycling almost every SRAM partition on the way to user code — including the one the test binary was linked into. The instructions were being scribbled over between the load and the first fetch, so the core would dutifully jump to what had been code, hit garbage, and fault. Nothing in the reference manual said which partitions the ROM touches at startup, and the HardFault itself only told me where execution died, not why the instructions there were no longer the ones I’d loaded. I worked it out by reading whatever I could find, writing a few throwaway scripts, and squinting at probe dumps.

That experience is why I wrote rambo</code></a>. It’s a small CLI whose only job is to answer the question I should have been able to look up: which parts of this chip’s RAM does the boot ROM clobber before my first instruction runs?

What rambo actually does</h2> The core loop is short enough to describe in a paragraph. For every RAM region probe-rs knows about for a given chip, rambo writes a deterministic pattern across the whole region — each 32-bit word stores its own address. Then it issues a reset and halts the core on the vector catch, before any user firmware runs. It reads the region back and classifies every block as one of four things: SAFE (the pattern survived), ZERO (filled with 0x00000000</code>), ONES (filled with 0xFFFFFFFF</code>), or CHANGED (rewritten with something else — ROM scratch, stack, or working data, and sometimes just garbage from a partition the ROM power-cycled). Output is a colored heatmap, a run-length-encoded summary of contiguous regions sharing a class, and per-region totals. It is deliberately a plain stdout program with ANSI colors. Not a TUI. Not a simulator. Not a fancy GUI. It’s something you can read in your terminal, pipe to a file, or paste into a bug report when you ask a vendor why their ROM is doing what it’s doing. The only thing it depends on at runtime is a debug probe and a chip that probe-rs supports — which, in practice, is most of the Cortex-M world. It does not flash anything. It does not modify your firmware. It writes a pattern, resets, reads back. That’s it.
Why writing the address as data matters</h2> The “each word stores its own address” pattern is the kind of thing that looks arbitrary until you’ve tried the alternatives. A solid bit pattern like 0xDEADBEEF</code> repeated everywhere will tell you whether RAM was clobbered, but it won’t tell you whether the readback came from the address you think it did — if the chip aliases memory or has unmapped windows in a reserved range, you can read the same 0xDEADBEEF</code> back from two different addresses and not notice. With addr-as-data</code>, every location is uniquely identifiable. A SAFE word is unambiguous. A ZERO or ONES word is unambiguous. A CHANGED word that also happens to equal some other valid address is a strong hint that something is aliased. The pattern is essentially free to generate, and it carries its own coordinate system.
A small tour of the optional modes</h2> The default survey answers the headline question. The optional modes are there for when the answer to “what is the ROM doing here?” is more interesting than “nothing” or “everything.” --fingerprint</code> classifies the kind of clobber inside CHANGED blocks. Is the block mostly zeros with a few non-zero words at the top? That looks like a stack frame. Is every word the same non-zero value? That’s a constant fill. Is it an ascending counter, a repeating motif, or an address-plus-offset pattern? Each of those points at a different ROM behavior — a memset, a struct initialization, a copy with a fixed offset, an uninitialized scratch buffer the ROM forgot to clear. None of these tell you exactly what the ROM is doing, but they let you skip straight past “is this even structured data” and into “this looks like a 16-byte header followed by a counter.” --dual-pattern</code> writes addr</code> in one reset cycle and ~addr</code> in a second. Both passes get classified independently and compared. If a block came back SAFE in both passes — pattern survived both times — then the ROM genuinely didn’t touch it. If a block came back CHANGED in both passes but with the same value, the ROM is actively writing there regardless of what was already in memory. This disambiguates two flavors of “the ROM didn’t touch this” that single-pass surveys can’t tell apart: undriven (the ROM left it alone) versus coincidentally the same as my pattern (extraordinarily unlikely with addr-as-data, but possible in pathological cases). --write-readback</code> is the opposite trick: skip the reset entirely. Write the pattern, immediately read it back, classify what comes out. On normal RAM, this is boring — everything classifies as SAFE. On reserved address ranges, on code-bus aliases of system RAM, on peripheral windows that look like memory in the chip description but aren’t, this is where you find out. Aliasing shows up as the same content at two addresses. Unmapped windows show up as bus faults or all-ones reads. It’s worth running once on any new chip just to see what its memory map actually does, as opposed to what the documentation claims. --reset-cycles N</code> re-runs the read after each of N resets without re-writing the pattern in between. If the ROM is deterministic — same chip, same reset, same post-ROM RAM contents every time — the classification is identical across cycles. If anything drifts, you’ve got nondeterminism worth investigating: timing-sensitive scratch, uninitialized stack frames bleeding in from whatever was happening microseconds before the reset, or RAM that hasn’t fully settled. This one is mostly useful when something should be the same every boot but isn’t, and you need evidence before you can start arguing about it.
The CI bit</h2> The mode I’m most happy with isn’t in the survey — it’s in the two flags that turn rambo into a regression gate. --json <path></code> writes a stable, schema-versioned JSON report of the entire run. Use it as a CI artifact, archive it across firmware versions, diff it when something changes. --expectations <path></code> takes a small declarative file — a “RAM contract” — and evaluates each clause against the survey. Each entry names a range and one of three claims:{ "name": "main_sram_crash_dump_area", "range": { "start": "0x20030000", "end": "0x20031000" }, "expect": "safe", "rationale": "Reserved for crash-dump recovery after watchdog reset." }</code></pre> The clauses are expect: <class></code> (every block must be that class), expect_any_of: [<class>, ...]</code> (every block must be one of these), and expect_not: <class></code> (no block may be that class). Exit code is 0 if every expectation holds, 1 if any fails. Ranges are checked for alignment and bounds before any probe I/O happens, so a typo can’t brick a run. What this gets you is a small, version-controlled answer to “the bootloader assumes these regions survive the ROM” that runs on every PR and on every new silicon rev. The next time a chip vendor patches their ROM and quietly starts touching memory they didn’t touch before, your CI tells you. It’s a tiny, boring thing. It’s also the kind of thing that would have saved me a few days on the RT685.
What rambo isn’t</h2> A few honest limits before you reach for it. It’s only as accurate as probe-rs’s chip database. If a chip’s memory_map</code> omits a region, rambo can’t survey it. Most of the time this is fine; occasionally a vendor leaves a peripheral-attached SRAM out of the description and you’ll need to add it yourself (or --chip-description-path</code> your own). Some CMSIS-Pack descriptions list code-bus aliases of system-bus RAM as separate regions. Rambo treats every region in the map as independent, so you’ll see the same physical RAM surveyed twice under different addresses. That’s almost always what you want — the aliases sometimes behave differently — but it can look surprising the first time. And “SAFE” only means “the ROM didn’t write here on this chip rev, with this fuse configuration, on this boot mode.” It does not mean the ROM will never write there. That gap is exactly why the contract file and CI gate exist.
Try it</h2>cargo install rambo</code>, or grab a pre-built binary from thereleases page</a> for Linux, macOS (Intel + Apple Silicon), or Windows. Source is on GitHub</a>.
If you run it on a chip I haven’t tested with — so far that’s RT685, RT633, MCXA266, MCXA276, and MCXA577 — I’d genuinely like to hear what came back. Especially if it surprises you.

Writing embedded drivers without an MCU 2026-06-10T16:00:00+00:00 Let me clarify the title up front: there is an MCU. There’s a Raspberry Pi Pico 2 sitting on my desk. What I mean is that the MCU isn’t in my dev loop. I don’t flash it. I don’t reset it. I don’t attach a probe to it. I treat it like a USB peripheral that happens to speak the buses I need — I²C, SPI, UART, GPIOs, ADC, and 1-Wire — and I write all of my driver code as a normal cargo run</code> binary that runs on my laptop, against the real sensor, over a real bus. This post is about how that works, why it’s nice, and what you can do once your “embedded” driver is just a Rust program with std</code>. The loop I’m trying to escape</h2> The traditional embedded dev loop looks something like this: Edit a line of code.</li> Wait for cargo build --target=thumbv8m.main-none-eabihf</code> to finish.</li> Reflash the chip (a few seconds with a probe, longer over the bootloader).</li> Either power-cycle the board or punch the reset button.</li> Squint at defmt</code> output through a probe.</li> If you need to reproduce a bug, also: physically interact with the board (push a button, breathe on the sensor, jiggle a wire).</li> Goto 1.</li> </ol> On a good day with a fast build and a good probe, that’s two minutes per iteration. On a bad day — a stale build cache, a probe that disconnects, a chip in some weird stuck state — it’s five or ten. The frustrating part isn’t the time. The frustrating part is that none of it is about the driver I’m writing. The driver is just some byte-level logic that talks to a chip over I²C. The chip doesn’t care which CPU is initiating the transactions. The chip certainly doesn’t care that I had to write a linker script and a clock-tree configuration to get there. So: why not skip all of that, and write the protocol logic somewhere where iteration is free? Enter Pico de Gallo</h2> Pico de Gallo</a> is a project I’ve been building for exactly this. It’s a small landing board that turns a Pi Pico 2 into a USB-attached protocol bridge. Plug it into your laptop, and your laptop now has an I²C bus, a SPI bus, a UART, a handful of GPIOs, two PWM channels, an ADC, and a 1-Wire master — addressable from any host-side program. A few things it isn’t, because it gets confused with each of these: It’s not a logic analyzer. It drives the bus; it doesn’t sniff somebody else’s.</li> It’s not a USB-to-I²C dongle in the FTDI sense. The chip underneath is a Pi Pico 2, the firmware speaks postcard-rpc</code></a>, and the host side is a real Rust crate with proper types and async support.</li> It’s not a debug probe. There’s no SWD on the other end of the cable. There’s only the device you wired up.</li> </ul> What it actually does is let you write this: use pico_de_gallo_hal::Hal; use embedded_hal::i2c::I2c; let hal = Hal::new(); let mut i2c = hal.i2c(); let mut buf = [0u8; 2]; i2c.write_read(0x48, &[0x00], &mut buf).unwrap();</code></pre> …on your laptop, and have the bytes appear on a real I²C wire, addressed to a real chip, with the reply coming back into buf</code>. The Pico de Gallo book has the full setup</a> — what to assemble, how to flash the firmware, the pinout, and a tour of each interface. I won’t repeat any of that here. From this point I assume you have a Pico de Gallo plugged in, a TMP108 wired to the I²C connector, and the gallo</code> CLI installed. Feeling the bus before writing a line of code</h2> The first thing I do with any new chip is poke at it through the CLI. This is the equivalent of the “wiggle a probe at it” step from the hardware world, except it’s three commands. Did the chip enumerate at the address I think it did? $ gallo i2c scan ╭────┬────┬────┬────┬────┬────┬────┬────┬────┬────┬────┬────┬────┬────┬────┬────┬────╮ │ │ 0 │ 1 │ 2 │ 3 │ 4 │ 5 │ 6 │ 7 │ 8 │ 9 │ a │ b │ c │ d │ e │ f │ ├────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┤ │ 0 │ RR │ RR │ RR │ RR │ RR │ RR │ RR │ RR │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ │ 1 │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ │ 2 │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ │ 3 │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ │ 4 │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ 48 │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ │ 5 │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ │ 6 │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ │ 7 │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ -- │ RR │ RR │ RR │ RR │ RR │ RR │ RR │ RR │ ╰────┴────┴────┴────┴────┴────┴────┴────┴────┴────┴────┴────┴────┴────┴────┴────┴────╯</code></pre> Yes. The TMP108 with its A0 pin to ground sits at 0x48, and there it is. If this had come back empty, I’d know it was wiring, not software, and I’d know it before I’d touched a Rust file. Can I read its temperature register? $ gallo i2c write-read --address 0x48 --bytes 0x00 --count 2 0x18 0x40</code></pre> Two bytes, just as the datasheet promised. Register 0x00 is the temperature register; the top 12 bits of the returned 16 are the signed reading in 0.0625 °C/LSB. So 0x1840 → 0x184 → 388 → 388 × 0.0625 → 24.25 °C. The room I’m in is about 24 °C. Three commands, no Rust, and I know: My wiring works.</li> The address I expected is the address the chip enumerated at.</li> The data format matches the datasheet.</li> </ol> Those three facts cost me about a minute of reading effort each on a real MCU, every time something goes wrong, because they’re all entangled with everything else. Here they’re isolated and free. Reading it from Rust</h2> Now for the actual program. The tmp108</code> crate</a> on crates.io already exists — it’s a regular embedded-hal</code> driver, #[no_std]</code>, written for anything that implements embedded_hal::i2c::I2c</code>. Normally you’d pull it into a firmware project, build for a Cortex-M target, and flash. We’re going to pull it into a std</code> binary instead. [dependencies] pico-de-gallo-hal = "0.5" tmp108 = "0.5"</code></pre>use pico_de_gallo_hal::Hal; use tmp108::Tmp108; fn main() -> anyhow::Result<()> { let hal = Hal::new(); let i2c = hal.i2c(); let mut tmp = Tmp108::new_with_a0_gnd(i2c); let temperature = tmp.temperature()?; println!("Temperature: {temperature:.2} °C"); Ok(()) }</code></pre> That’s the whole program. cargo run</code>, and the bytes go out, the reply comes back, and a number prints. The interesting thing to notice is what isn’t there. The tmp108</code> crate doesn’t know that pico-de-gallo</code> exists. It has no conditional compilation for “host” or “USB.” Its only requirement is “give me something that implements embedded_hal::i2c::I2c</code>,” and pico-de-gallo-hal</code> does. The exact same Tmp108::new_with_a0_gnd</code> call, with the exact same crate, the exact same version, will run unmodified on an RP2350, an STM32, an nRF52, or any other chip that has an embedded-hal</code> I²C implementation. This is not emulation. It’s not mocking. It’s not simulation. The bus is real. The chip is real. The driver is real. The only thing that’s different is what’s underneath the I2c</code> trait — and that’s the whole point of the trait existing in the first place. One honest caveat on that portability claim: of the interfaces Pico de Gallo exposes, only I²C, SPI, GPIO, and Delay</code> have stable, widely-adopted embedded-hal</code> traits today. The TMP108 example above sails through because it’s I²C, and the alert examples in tmp108’s examples/</code> folder</a> sail through because they only also need GPIO. A driver for, say, a 1-Wire temperature sensor or a UART-attached GPS module won’t be quite as plug-and-play — embedded-hal</code> doesn’t have stable abstractions for those yet, so each crate tends to invent its own. The “unmodified upstream driver” story is strongest for parts whose driver only needs I²C, SPI, GPIO, and timing. For everything else, the host-side loop still works; you just may have to do a bit of shimming. The dev loop, side by side</h2> Here’s the same edit-and-test cycle from above, redrawn against this program: Edit a line of code.</li> cargo run</code>.</li> </ol> That’s it. A debug build of this program takes under a second to recompile and start. There’s no flash step, no reset, no probe to attach. If the program panics, the stack trace points at the line that panicked, in source, with debug symbols, in the same terminal I just ran it from. Other things that just work, because it’s std</code>: cargo test</code> runs against the real chip.</li> cargo bench</code> measures real round-trip latency over USB.</li> cargo flamegraph</code> and perf</code> and dtrace</code> and Instruments all work, because it’s a normal native process.</li> println!</code>, dbg!</code>, eprintln!</code>, tracing</code>, env_logger</code> — any of them. Whatever you’d use in a normal Rust program.</li> The debugger you actually like — rust-lldb</code>, rust-gdb</code>, the one built into your editor — attaches the way it always does.</li> </ul> The obvious question at this point is what the catch is. We’ll get there. What having std</code> actually unlocks</h2> The temperature-printing program is the warm-up. The thing that makes this approach worth talking about is what becomes easy next. Here is a small ratatui</code> dashboard that reads the TMP108 four times a second and plots a live sparkline of the last 60 samples alongside running min / avg / max: The whole program is about 150 lines and uses three dependencies: pico-de-gallo-hal</code>, tmp108</code>, and ratatui</code>. The interesting bits look like this: const HISTORY: usize = 60; const SAMPLE_INTERVAL: Duration = Duration::from_millis(250); let hal = Hal::new(); let i2c = hal.i2c(); let mut tmp = Tmp108::new_with_a0_gnd(i2c); let mut samples: VecDeque<f32> = VecDeque::with_capacity(HISTORY); let mut next_sample = Instant::now(); loop { if Instant::now() >= next_sample { let t = tmp.temperature()?; if samples.len() == HISTORY { samples.pop_front(); } samples.push_back(t); next_sample += SAMPLE_INTERVAL; } terminal.draw(|frame| draw(frame, &samples))?; // ...event handling: quit on 'q' or Esc }</code></pre> The draw</code> function splits the screen vertically into a stats row and a sparkline: fn draw(frame: &mut Frame<'_>, samples: &VecDeque<f32>) { let chunks = Layout::default() .direction(Direction::Vertical) .constraints([Constraint::Length(3), Constraint::Min(0)]) .split(frame.area()); frame.render_widget(stats(samples), chunks[0]); frame.render_widget(sparkline(samples), chunks[1]); }</code></pre> …and sparkline</code> rescales the float window into the integer bars that ratatui::Sparkline</code> wants, so even tiny drifts are visible: fn sparkline(samples: &VecDeque<f32>) -> Sparkline<'_> { let bars: Vec<u64> = if samples.is_empty() { Vec::new() } else { let min = samples.iter().copied().fold(f32::INFINITY, f32::min); let max = samples.iter().copied().fold(f32::NEG_INFINITY, f32::max); let span = (max - min).max(0.1); samples .iter() .map(|t| (((t - min) / span) * 1000.0).round() as u64) .collect() }; Sparkline::default() .data(bars) .max(1000) .style(Style::default().fg(Color::Yellow)) .block(Block::bordered().title(" last 60 samples (q to quit) ")) }</code></pre> That’s it. Read in a loop, push into a ring buffer, redraw. The total code is shorter than the LCD-init sequence I’d have written the first time I tried to do this on an MCU. And because it’s a normal terminal program, Ctrl-C</code> cleans up and exits. Once you’re in this world, a lot of other things become “just write the program”: Data logging. A few lines of serde</code> + csv</code> and every sample gets a wall-clock timestamp on disk. Post-process with whatever you like — polars</code>, pandas</code>, jq</code>, a quick shell pipeline: let mut wtr = csv::Writer::from_path("temps.csv")?; wtr.write_record(["timestamp_ms", "temperature_c"])?; // inside the loop: wtr.write_record(&[ chrono::Utc::now().timestamp_millis().to_string(), format!("{t:.4}"), ])?;</code></pre> Bus tracing. Wrap the driver in a tracing</code> span and you get structured records of every transaction, every reading, every error, with timestamps and process metadata. Pipe it into tracing-subscriber</code>, tokio-console</code>, OpenTelemetry — pick your poison. Stress testing. Spin up a tokio</code> runtime, share the bus through a Mutex<Bus></code>, and have a dozen tasks all reading and configuring the chip concurrently. See what falls over. This is something you could do on the MCU, but it’s the kind of thing you’d never set up just to find out. A/B testing. Run two versions of the driver against the same chip back-to-back, diff their outputs sample-for-sample. Catch a regression in the new version before it makes it anywhere near a production board. Real CI. This is the one I’m most excited about. cargo test</code> runs on a CI runner that has a Pico de Gallo plugged into it, with real chips wired up. Every PR exercises the driver against real silicon. No simulation. No “we’ll catch it in hardware testing later.” (More on CI in the testing chapter</a> of the book.) Runnable examples in your crate. This one flips the framing. So far we’ve talked about Pico de Gallo as something consumers of a driver crate use. But it works just as well for the author of the crate. Cargo lets you put a examples/</code> folder in your library and have each file be a binary; if those binaries can target a real, running version of your chip without anyone reaching for a soldering iron, they stop being “snippets you’d have to port to your board” and start being “things a reader can cargo run</code> after plugging in two cables.” The tmp108</code> crate’s examples</a> are exactly this. There are five of them — one-shot read, continuous read, comparator-mode ALERT, interrupt-mode ALERT, and a embedded-sensors-hal</code> trait demo — and every single one starts with let hal = Hal::new(); let i2c = hal.i2c();</code> (the ALERT ones also grab a GPIO for the interrupt line). A reader who wants to understand any of the modes runs cargo run --example oneshot</code> and gets a real temperature back from a real chip. No board-bringup chapter. No “you’ll need to adapt this for your target.” The documentation is the running program. Each of these was technically possible before. Each one required setting up its own bespoke pipeline, often with a custom MCU build, a custom log format, and a custom analysis layer on top. With a real bus available to a real std</code> program, they all collapse into “use the crate that already exists.” The catch</h2> One might ask, what’s the catch? Here is the honest list. USB latency. Every transaction is a USB round-trip. In practice that’s about a millisecond. For polling a temperature sensor every 250 ms, that’s invisible. For a tight register-poll loop at 100 kHz trying to catch a hardware event in software — no, that does not work, and pretending it does would be a lie. Use the chip’s ALERT</code> pin and an interrupt-driven path for that, which Pico de Gallo also supports via the GPIO Wait</code> impl. Timing is host-mediated. You cannot reproduce sub-millisecond interrupt-to-handler timing on a host. You can validate the protocol your interrupt handler implements, but not the latency of getting to the handler. For that you eventually need the real MCU. Single master, single bus. The Pico de Gallo is the only master on the bus. You can’t reproduce a scenario where two different MCUs are arbitrating for the same wires. The driver still has to be no_std</code>. Pico de Gallo lets you exercise the logic of the driver in a comfortable environment. It does not validate that the driver compiles for your real target. You still need a one-line “build for thumbv8m.main-none-eabihf</code>” step in CI to catch accidentally pulling in std</code>. The tmp108</code> crate has exactly that job</a> running on every push for this reason. None of these are surprises. They’re the natural consequence of moving the dev environment off the target. The point is that for the work that is portable — and a sensor driver is essentially all portable work — you don’t have to pay the cost of the target during development. Wrapping up</h2> A device driver is protocol logic. Protocol logic doesn’t care what CPU is initiating the transactions. So write it where iteration is cheap, where you have a debugger and a test runner and a profiler, where you can wrap it in any visualization or analysis tool you want, and where adding “log every sample to a CSV” is two lines of code instead of two weeks of integration work. Pico de Gallo is one way to do that. It happens to be the one I built, because nothing else existed that gave me exactly this. If you want to read more, the book</a> covers the hardware, the firmware, the wire protocol, and a full chapter on writing a driver from scratch against a different temperature chip (TMP102). The tmp108</code> crate</a> used in this post is on crates.io, and its examples/</code></a> directory is full of cargo run --example</code>-able programs that all target a real chip through Pico de Gallo. The full ratatui dashboard code lives in a tiny standalone project that you can copy and adapt. If you build something with it — a driver, a logger, a CI rig, a dashboard for a chip you’ve been wanting to characterize — I’d love to hear about it. Hello, world 2026-06-10T08:00:00+00:00 This is the first post on the new version of balbi.sh</a>. The previous incarnation was a single HTML file with one link; this one is built with Zola</a> and styled after ef-melissa-light</a> — a warm, legible Emacs theme by Protesilaos Stavrou. Body text is set in Aporetic Serif, headings and UI in Aporetic Sans, and code in Aporetic Sans Mono — all from the same author as the colour palette. Why now</h2> I want a place to keep working notes — short writeups about the things I run into while building firmware. The bar for publishing here is low on purpose. If a problem took me more than an hour to figure out, it probably deserves a post so I (or you) don’t have to figure it out again next time. What to expect</h2> Mostly: Embedded Rust — Embassy, embedded-hal</code>, async on tiny chips.</li> Bare-metal C — when Rust isn’t an option, which is more often than I’d like.</li> Tooling — probe-rs, defmt, the linker, the assembler, the things that quietly hold everything together.</li> Occasional rants about debugging hardware at 2am.</li> </ul> If you want to follow along, there’s an Atom feed</a>. Code, by the way</h2> It looks like this: #[embassy_executor::task] async fn blinky(mut led: Output<'static>) { loop { led.toggle(); Timer::after_millis(500).await; } }</code></pre> That’s all for now. More soon.

Felipe Balbi

What did the boot ROM just do to my RAM?

Writing embedded drivers without an MCU

The dev loop, side by side</h2> Here’s the same edit-and-test cycle from above, redrawn against this program:</p> Edit a line of code.</li>

Hello, world