Mike Rosing (@drmike)

I love math and physics, learned DSP and embedded systems to do math and physics, and found FPGA's a hell of a lot of fun. I graduated in 1982 with a PhD in nuclear engineering and have been programming in assembler and C ever since.

Ancient History

Mike Rosing ● January 18, 2016●8 comments

Technology moves fast, and the tools, platforms, and assumptions you rely on can become outdated almost overnight. In this reflective post, the author contrasts the rapid evolution of embedded development with the much slower pace of social change, from programming turnaround times to the underrepresentation of women in engineering. It is a reminder to keep learning, but also to think about how we work and who gets included.

What IS an electron?

Mike Rosing ● December 21, 2015●5 comments

The post surveys historical and theoretical perspectives to ask what an electron actually is, treating the electron as a working scientific model rather than an absolute object. It traces the concept from early electrical technology and J.J. Thomson’s discovery through Maxwell’s relativistic field laws and Dirac’s relativistic quantum equation, noting spin, positrons, and radiation puzzles that led to quantum mechanics. The article discusses collective behaviors — Langmuir’s paradox, exchange-correlation in plasmas, density functional theory in solids, and superconducting pairing — and emphasizes that an electron can appear pointlike at high energies, wave-like in atoms, and collective in materials, so the practical answer depends on experimental context and timescale.

The Art of Debugging

Mike Rosing ● December 11, 2015

The post presents debugging as the essential, iterative craft of electronics engineering, emphasizing that practical troubleshooting is learned through experience. It advises starting with the basics—verify power rails and ground connections—before isolating faults using a binary-search approach on hardware. For firmware issues, the author recommends hardware-assisted tracing (toggling spare pins or sacrificing simple hardware) to observe routine entry/exit and interrupt activity, and using in-circuit debugging when available. The narrative also covers human factors: when stuck, step away to let unconscious problem solving work, and recognize that many failures stem from intended behavior or edge conditions. The conclusion stresses designing systems for debuggability to reduce bugs and treat debugging as an engineering art that improves with practice.

No Threads Found