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.

The maxim in firmware is "this demonstrates the importance of not being seen".

The comparison to exploitae is .. modestly nauseating ( but perfectly understandable ) ; I never ran into a story about exploits where the perpetrator really wanted to be invisible.

There is no narcissism in firmware. It is the perfect satisfaction of leaving no ripple in the pond.

well said. I would agree. I am new to hardware...I just found myself getting the same tinglies I did with software exploitation as those I got writing firmware. Hence the correlation.

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.

No problemo, thanks for editing. I am equally as cynical. I would've called me an idiot for not using the debugger also...but alas it was busticated.

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”'.

I don't mean to shit on "Makers". In fact the growing popularity of "Makers" is what makes companies like TI and others see market viability for the low-cost development kits that I take advantage of quite a bit.... I just find that if you visit your average hackerspace or Maker faire, you spend most of your time weeding through the noise to try to get actionable and useful information. I was merely pointing out that if you abhor the sciolist hipster smug, be wary of the "Makers" because there is a abnormally high concentration of that there than in most technology communities.

> 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.