For novel ideas about building embedded systems (both hardware and firmware), join the 40,000+ engineers who subscribe to The Embedded Muse, a free biweekly newsletter. The Muse has no hype and no vendor PR. Click here to subscribe.


Special Reports About Building Embedded Systems

Here's a variety of special reports about a range of embedded subjects, from hardware to firmware:

  • Hardware and Firmware Issues in Using Ultra-Low Power MCUs - Building a battery-powered device with an ultra-low power MCU? Most of what passes for common knowledge about these sorts of systems is wrong. Here's the real scoop, backed up by experimental evidence.

  • Probing Pointers - Scope (and logic analyzer) probes have a variety of surprising issues. This report gives some insight with real-world examples.

  • eXtreme Instrumenting - Want cool but cheap ways to monitor the real-time peformance of your embedded systems? This details are all in this report.

  • How to Automatically Find Bugs in Your Code - There is a simple way to create self-debugging code. Alas, in the firmware world it's rarely used.

  • Salary Survey - Here's a 2018 salary survey of embedded developers. How does your pay match these numbers?

  • Write-Only Memory - Not really a Special Report, but here's Signetic's 1972 Write Only Memory datasheet. "The 25120 is easily cooled by employment of a six-foot fan, 1/2" from the package. If the device fails, you have exceeded the ratings. In such cases, more air is recommended.". The datasheet is a hoot!

  • A Boss's Guide to Process Improvement - Does your boss understand what's needed to produce great code? Many have no formal software engineering background and just need some hard data. This Boss's Guide to Software Process Improvement is a short paper that will give your boss the facts.

  • Debouncing - There's a lot of smoke and mirrors in typical debounce code. Magic numbers, tuned software that breaks whenever anything changes. This is the definitive guide to debouncing switches and contacts. It includes plenty of empirical data taken from a wide variety of switches.

  • Firmware Standards Manual - By it's very nature computer code is cryptic. Wise developers employ standards to enhance readability. Note that all safety critical code must conform to a standard... so why don't all of us who wish to create great software do the same?

  • Watchdog Timers - I've examined hundreds of watchdog timers over the years. Few - very few - are completely robust. A watchdog is the last line of defense before the systems dies. It has to be awesomely designed. Check out Great Watchdogs for some ideas.

  • Commenting - Ah, comments. We all write them (usually). We all read them (and never believe a word we read). Comments are as important as the code itself, yet usually they're a poorly-written afterthought. In my opinion they should be a fore-thought, written before we start typing in curly braces.

  • Testing RAM - Did you know that a RAM test on DRAM whose refresh circuitry has fried will pass? Or that impedance issues mean good RAM tests cleverly drive the address & data busses in a way to create the worst-case electromagnetic effects? Nearly all the RAM tests I run into are lousy. Here's what you need to know about Testing RAM in Embedded Systems.

  • Becoming an Embedded Developer - I get a lot of email asking how one can become a firmware fiend. I learned the same way I learned about the birds and the bees - talked with my friends, ran a few experiments, and iterated. But that's not efficient.

  • Code Inspections - There is a silver bullet that greatly reduces defects while saving development time. Though we've known about it since 1976 few developers routinely employ it. A Guide to Code Inspections gives the facts and the techniques.

  • Floating Point Approximations - Need to do a trig function but don't have a trig library? Is the trig library too big? See how simple polynomials produce all of the trig functions in Floating Point Approximations (for trig), or Other Floating Point Approximations (roots, logs and exponentiation).

  • Better Resumes - Most technical resumes are awful. They're peppered with acronyms the reader probably doesn't know, sentence structure is non-existent, and the document doesn't fulfill its primary mission: sell the candidate.

  • Microprocessor History - The first commercial microprocessor appeared over 40 years ago. The history of this invention is really interesting.