Embedded & FPGA engineer — precision RF, high-speed data paths, and the firmware underneath.

📍 Fremont, CA · 🌐 zephyr.atomi.ai

I have a hard time letting go of the question "so what's actually going on one layer below that?" That restlessness probably explains everything else on this page.

I came up through computer science, and for a long stretch the software I wrote never touched a wire. A C compiler for a sixteen-core network processor. Nine years on a large ad platform. Then chief architect at a data infrastructure company, building real-time analytics and GPU-backed Kubernetes — Kafka, Spark, HBase, Druid, data all the way down. I was good at it. Somewhere in there I turned into a manager. But the thing I actually enjoy is being at the bench, debugging the product I want to exist.

Hardware first showed up in my life because I got cornered. I owned data ingestion and presentation for a smart bathroom scale — cloud-side work. The ingestion kept breaking, and after chasing it around my own layer without finding anything, the only direction left was down: understand how the scale itself was built. One MCU, a few sensors, a Bluetooth module, and the path a reading takes from a strain gauge all the way to a row in my database. That's when I started to have any real picture of hardware. What became obvious afterwards is that you can't build an IoT data platform while pretending the hardware isn't there. Cost, performance, latency, uplink and downlink bandwidth — all of it decides what the platform can honestly deliver to a user.

So after leading engineering at two companies, one in China and one in the US, I started from zero on a machine that makes a pizza end to end. I drew every board myself in KiCad. The firmware is Rust — for the efficiency, and above all for the debugging efficiency. Four kinds of RP2040 node on a single CAN bus, stepper motors, oven temperature control, all of it. The Rust CAN library I needed didn't exist, so I wrote one. That machine settled the question for me. Almost nothing I ran into was a distributed systems problem; it was all how do I get this MCU to do this correctly — timing, interrupts, bus arbitration, a motor that flatly refuses to behave the way the datasheet says. The work is wherever the problems are. Plenty of friends went off to do AI, which is where all the heat is. I asked myself what I actually wanted to spend my time on, and the answer was: further down.

FPGA is the thing I've found most interesting these past few years. It started on the pizza machine, when we needed CAN. We had already settled on the RP2040 as our MCU and there was no comfortable option for it, so I went looking, and found that an FPGA can serve as a fairly generic communications solution — whatever protocol you want, you describe it. So I got started, and got both UART and CAN running. That route never actually got used: I got the RP2040's PIO working too, and that solved the problem. But the door was open. At my current company the work itself is FPGA-based RF, plus interfaces like OctoSPI, so I've put a great deal of time into it. One thing has grown steadily clearer: in high-frequency, high-speed work, when there's no ASIC or DSP that happens to fit, an FPGA is basically the only way to get close.

The field I'm in now leans toward optics and RF, and there is a lot in it I don't understand. The analog circuitry you run into in RF, for one, is well past the point where you can solve your problem by copying someone else's design — interference, grounding, low-pass versus high-pass, all of it has to be worked out for the actual situation in front of you. I'm an outsider to that today, and it has set my curiosity going all over again. Finding an unfamiliar field, working at it until I can learn it, and eventually getting on top of it — that has been my approach to problems for as long as I can remember. I'm glad the world keeps producing things I don't know yet.

On to the next unknown.

• octospi — OctoSPI slave IP core for Xilinx FPGAs with an AXI4-Lite bridge; Embassy/Rust async driver on STM32U595; cocotb + Verilator regression suite
• can2040-rust — CAN 2.0 for the RP2040, written from scratch in Rust: no_std, zero C dependencies (8K+ downloads on crates.io)
• canopen-rust — Pure-Rust CANopen stack on top of can2040-rust, full CiA 301 application layer (5K+ downloads on crates.io)
• stm32-dual-boot — Minimal dual-slot bootloader for the STM32U575ZI: two firmware slots, one word of SRAM
• pizzaro-firmware — Complete multi-MCU firmware for the pizza robot: RP2040, Rust, CAN

Write-ups for each — including what went wrong — are at zephyr.atomi.ai.

Verilog · SystemVerilog · Vivado · Artix-7 · Zynq UltraScale+ RFSoC · AXI4-Lite · cocotb · Verilator Rust (no_std, Embassy) · C · STM32 · RP2040 · ESP32 · KiCad

AXI-DMA and PCIe — the boards are already on my desk. And the analog side: getting to where I can reason about an RF front end myself, instead of asking someone who knows more than I do.