You may redistribute this newsletter for non-commercial purposes. For commercial use contact jack@ganssle.com.

• Editor's Notes
• Quotes and Thoughts
• Tools and Tips
• Freebies and Discounts
• On Stack Overflows
• Optimizing Optimism
• This Week's Cool Product
• Jobs!
• Joke for the Week
• Advertise with us
• About The Embedded Muse

Did you know it IS possible to create accurate schedules? Or that most projects consume 50% of the development time in debug and test, and that it's not hard to slash that number drastically? Or that we know how to manage the quantitative relationship between complexity and bugs? Learn this and far more at my Better Firmware Faster class, presented at your facility. More info here.

"Forget your perfect offering/There is a crack in everything/That's how the light gets in." Leonard Cohen

Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past.

Clever algorithms to speed up common calculations are always interesting. Kjeld Mathias Petersen sent in a link for a very fast way to compute an inverse square root: https://en.wikipedia.org/wiki/Fast_inverse_square_root

The Barr Group recently held a webinar about preventing and detecting stack overflows. A transcript is here. It has some useful tips.

The webinar has a link to a paper by Micrium on the subject. However, the full set of links to Micrium's papers about stacks is https://www.micrium.com/detecting-stack-overflows-part-1-of-2/ and https://www.micrium.com/detecting-stack-overflows-part-2-of-2/. These are must-reads regardless of which RTOS you're using.

The second paper is particularly important. Some RTOSes, given a CPU with a stack limit register or the increasingly-popular MPUs (memory protection unit) found on some ARM Cortex parts, will use those hardware resources to enforce stack limits. Wait, you say - how can a single stack limit register or the relatively-simple MPU monitor the perhaps dozens of stacks in a multi-tasking environment?

The answer is that the RTOS reloads these hardware monitors as it switches from task to task. Sine only a single task executes at a time, a single monitor is all that is needed. Yes, there's some overhead involved in the reload, but that's typically just a handful of instructions.

Chasing stack overflows will age one quickly as the bug is usually impossible to replicate. When I got into this business the only 8 bitter around was Intel's 8008 which had a hardware stack on-chip. It was a mere seven levels deep, which meant we routinely overflowed it. Today stacks are much bigger, but an overflow is just as hard to find as it was 40+ years ago.

The 80386 came out in 1985 and was perhaps the first microprocessor with a really-decent MMU. Most people programmed it to give a nice flat 4GB address space. In my opinion this was a really poor idea for any moderately-complex system. The MMU is a fantastic tool to ensure tasks don't wander off, stacks don't overflow, heaps behave, and more.

The 386's total transistor budget was 275,000. It was built initially in 1500 nm geometry. I don't know how much of that budget went to the MMU but suspect it was a smallish subset, and can't help but wonder if today's 45 nm MCUs could incorporate the technology for a low cost. An MPU is a great first approximation, but given how many problems stem from memory integrity, I sure would like the better support of a decent MMU.

Regardless, if your processor has a stack limit register or MPU, use it. A blown stack could take weeks to find; a hardware monitor will capture the problem in under a microsecond. And do check out those links.

200 million degrees in Kansas City? Doesn't sound right to me.

We're all too optimistic. We assume things will go well when bitter experience shows otherwise. This temperature map is an example of optimistic programming; the developers obviously never applied a sanity check to their results. One of the oldest rules in software is to check your goesintas and goesoutas. But few of us do.

Some languages enforce the notion of Design by Contract (DbC). The idea is that no function stands in isolation. There's some relationship between it and the rest of the project. In business these sorts of relationships are enforced by contracts; DbC is a way of enforcing them at runtime in software. The latest version of Ada and Eiffel both support DbC, and a great paper about the idea is here.

C doesn't have DbC, but we do have the horribly-underutilized assert macro. Assert throws an error if its argument isn't true. Yes, assert does a printf which is not available or too costly in many embedded systems, but it's a short macro that can be trivially rewritten to do something more logical.

Miro Samek has an excellent article about this here, which includes code for an embedded-friendly assert macro. However, I'd recommend modifying it a bit. The assert macro disappears when the debug switch (or, in Miro's code, NASSERT) isn't defined. But assert can take any argument, including assignment statements and function calls. It's possible that the code will run differently depending on whether the debug switch is defined or not.

Instead, define and use a slightly different version of assert:

#define assert_e(a) ((void)(a), assert(a))

//lint -emacro(730,assert_e)

Now PC-Lint (you are using lint, aren't you?) will complain if the argument is such that the code's behavior will change depending on whether the debug switch is defined or not.

Electronic Design magazine has an interesting article about using a TI TPL5110 "nano-timer" to create ultra-low power products that can run for years from a battery, or more or less forever using energy harvesting. Instead of placing the MCU in a sleep mode, the timer removes power completely from the controller. For an application where the system is not running most of the time this means one could use an MCU that is not optimized for extremely-low sleep currents. Or there could be a lot of power-hungry electronics hanging on the far side of the FET.

Often the weak part of a circuit like this is the FET that gates power to the MCU. Many leak a fair amount, but the TS5A3160 cited has pretty decent specs.

The TPL5110 only consumes 50 nA (worst case), which is pretty remarkable.

The nano-timer approach makes sense for applications where the system must come to life at regular, timed, intervals. If the MCU needs to power up in response to an event, other approaches should be used.

Note: This section is about something I personally find cool, interesting or important and want to pass along to readers. It is not influenced by vendors.

Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad.

Note: These jokes are archived at www.ganssle.com/jokes.htm.

To understand what recursion is, first you have to understand recursion.

Advertise in The Embedded Muse! Over 27,000 embedded developers get this twice-monthly publication. .

The Embedded Muse is Jack Ganssle's newsletter. Send complaints, comments, and contributions to me at jack@ganssle.com.

The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster.