Why Writing Firmware Is Kinda Like Software Exploitation

LEDs are incredibly common and incredibly useful debug tools. I've had to work with boards that don't have them and without physical access to the traces for a scope, you're out of luck.

While some of it is fascinating, I've also had to spend entire days figuring out why a single pin won't toggle on a microcontroller. It sometimes takes herculean effort for the simplest debugging tasks.

Perhaps these things (firmware, exploits) are more about scientific observation of experiments and less about reading documentation or literature to understand how to develop something. Commercial software development can be like that too. You may need to understand assembly code to figure out how library routines work (without access to the source). The documentation is usually incomplete or incorrect (as in "security by obscurity"). And people whose minds work in a particular way, who can back out what is going on from a set of empirical results, can get things done that others cannot.

Do not let the title fool you. This is not about security; it's about all the stuff Steve Ridley learned working on bringing an RF hardware product to market.

Edit: Shame on me, should have read the article more carefully, he actually explains why he was not able to use JTAG. Sorry for my hubris.

-------

I like the approach, but while this post rants about the unprofessional Arduino crowd, his attempt to solve his init problem via a blinking LED to Morse debug data strikes me as similarly inefficient.

To solve these kinds of problems, one normally attaches a JTAG interface (or the equivalent device on the particular platform) and single steps through the code, observing registers and memory... if you don't have this tool (for ARM the most primitive will cost you maybe 30$ or €, the fastest and most feature rich will be s few 1000) you'll waste a LOT of time in low level debugging.

If you really have to Morse on a GPIO, you want something that a logic analyzer can decode.

This article makes me sad. Here's a guy who has only relatively recently acquired skills in hardware and firmware development, but he already thinks he's in a position to arrogantly shit all over what he calls '“Maker” folks who are usually web programmers that want to declare to their coworkers and friends with self-righteous indignation that they are “going lower level” or “getting into robotics”'.

> Working on solved problems sucks

I don't think there is such a thing as a solved problem. The more I get into web dev, the more fascinated I become by it. There's just so much to learn, if it were such a "solved problem" then 99% of the code I have to maintain, including my own, wouldn't utterly suck.