Go here to sign up for The Embedded Muse.
The Embedded Muse Logo The Embedded Muse
Issue Number 438, January 17, 2022
Copyright 2022 The Ganssle Group

Editor: Jack Ganssle, jack@ganssle.com

   Jack Ganssle, Editor of The Embedded Muse

You may redistribute this newsletter for non-commercial purposes. For commercial use contact info@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email.

Contents
Editor's Notes

SEGGER Embedded Studio cross platform IDE

Tip for sending me email: My email filters are super aggressive and I no longer look at the spam mailbox. If you include the phrase "embedded muse" in the subject line your email will wend its weighty way to me.

Steve Leibson has another great article about the early days of circuits, in this case a history of the 555 timer. Hans Camenzind designed it; I've read two of Camenzind's books, both of which are great: Much ADO about Almost Nothing: Man's Encounter with the Electron, and Designing Analog Chips.

Quotes and Thoughts

It isn't that they can’t see the solution. It is that they can’t see the problem. G. K. Chesterton

Tools and Tips

Percepio ad

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

Dave Armour sent this link to a great presentation about the Apollo Guidance Computer's role in the Apollo 11 landing. One of the most interesting books about the man/machine interface is David Mindell's Digital Apollo, which I reviewed here. In it Mindell explains the tradeoffs engineers made between the automation and the human piloting of the spacecraft.

How fast is your laptop compared to an old mainframe? In this article the author argues it's quadrillions of times faster than an IBM 7090. I'm not sure I agree with all of his logic, but in my first year of college we had a 7094, and it's pretty amazing to see how much has changed in a single lifetime.

Freebies and Discounts

January's giveaway is a copy of Chris Hallinan's book Embedded Linux Primer. It's an excellent volume for folks working with Linux. I reviewed it here.

Enter via this link.

SourceMonitor

Engineering without numbers isn't engineering - it's art. While there is art in engineering, ultimately it's all about the numbers.

When it comes to understanding source code there are tools that will provide useful metrics. PC-Lint is one very popular and effective tool for analyzing code. Alas, it has become rather expensive.

Another is SourceMonitor from Campwood Software. I've been using this for years and highly recommend it. SourceMonitor is a lightweight tool that analyzes a set of source files. It is extremely fast and super easy to configure. Partly this is because it does not attempt to be as comprehensive as a Lint tool.

Aim SourceMonitor at a project and you'll get a report that looks like this:

Most of those metrics are self-explanatory. A couple of comments:

  • Complexity is the cyclomatic complexity. That's merely the number of paths through a function. Numbers under about 10 indicate a well-behaved function. As the metric goes up the risk and bugginess of the code increases. Over 50 is considered "untestable," as complexity is (provably) the minimum number of tests required to insure the function works (it says nothing about the max tests needed).
  • Depth is depth of nesting in a function. Generally a number under 5 is considered acceptable, though I try to keep it under 3.

Click on a source file name in the picture above and you'll get metrics about the file and each function. For instance:

SourceMonitor supports C and C++, as well as a number of other lingos not used in the embedded biz.

I don't like it that it does not seem to remember directories. When starting a new project you have to select several directories starting with the very root of Windows. If you're like me, your files are buried deep in a filesystem, so there's rather a lot of clicking around needed to configure a new project.

Unfortunately the author of the tool is retiring and no longer providing support. He is trying to open source it, so I hope it will have a good future. Download it today and even if it disappears you'll still be able to quickly produce metrics for your projects.

More on Bugs and Bug Tracking

There were numerous responses to last issue's take on bugs.

Eric Nelson wrote:

Haha, bugs. Tom DeMarco was fond of reminding everyone that defects are designed in and that the 80:20 rule applies to defect designers: 80% of the defects are contributed by 20% of the designers. As managers we need to find different jobs for the 20%.

Also, at one time most software defects were “off by one” errors. Was that array zero-based or one-based. Does this loop end with “<“ or “<=“ etc…

I used to joke that the more “dots” in a software version, the more likely it has bugs. This was largely true with a couple graphics card vendors in the early naughties. Vendor A had one dot (e.g. X.Y) and their drivers were rock solid. Vendor B had three dots (x.y.z.w) and their drivers were problematic. For sure the number of dots makes one wonder about their software development discipline.

In one organization I know of, the product build was always broken except at release time. It took an all-hands month to get it cleaned up, so they couldn't do releases very often and still do development. In another organization, the discipline was that the build was never broken, and if it ever did break nobody went home until it was fixed. No surprise that the latter group could deliver a complete, fully-tested product release every two weeks.

John Grant, replying to my advice to track buggy functions:

My rule of thumb (possibly channeling Lady Bracknell) is if there's more than one bug in a piece of code I can't have been awake when I wrote it so throw it away and write it again.

Dave Zar also had comments about bug tracking:

Anyway, I saw your comment about "Keep a tally of bugs in each function. It can be pretty informal. But that data will quickly and quantitatively show which are in the small batch of what is bad code" and it's spot on. I've been writing bugs for over 40 years, now. I can confirm that even if this informal way is to remember "hey, I was here last month for something similar" then you are on to something. Likely bad code (not just an obvious '<' that should have been '>').

I think one reason folks don't just dive in and fix "bad code" is that someone else might have written it. One of the hardest things to do is to rewrite someone else's code. We tend to think they were more clever and/or better than us and if we could just spend a little more time figuring this out, all will be obvious and the universe will be aligned. I can absolutely state that this is true less than 10% of the time. Heck, haven't we all experienced the feeling of "what idiot wrote this" only to later recall it was ourselves?

I know I write much better code than I did 40 years ago. Heck, I write better code than I did even one year ago. We all learn (or should) and improve in any number of ways. So a bug in a module/function/method is an opportunity to clean it up, not patch it when it's obviously "bad." Even in mission critical code the time spent rewriting is always less than debugging/patching/debugging/hacking/debugging/rewriting. The rewrite should be on the smallest failing unit possible (unless there is a larger project to rewrite large sections) but I've found that it's often the most time-efficient way to get past the problem.

Design for Debugging

Daniel McBrearty sent an email about things that should be obvious, but are too-often neglected:

The last weeks I've been involved in a project which has had me thinking a LOT about designing in a way that makes debug and verification easier, and certain things keep coming back which I wanted to share. To be honest a lot of this is stuff which I thought was a bit basic, but as I find myself discussing this with other (not inexperienced) engineers, maybe it's not as self-evident as I thought. Anyway.

1. Modularity and encapsulation. I came across a piece of system design where (essentially) the inner workings of devices (like memory maps and file system info for FLASH storage) are exposed across APIs and comms channels. My gut tells me that this isn't great, but I have difficulty in explaining why. My design approach for this would be to design the API by *function* and hide low level stuff behind the interface. I think it is much easier to test, and also to do logging at system interfaces, so when things go wrong, far easier to diagnose. (There are no other reasons like speed or whatever that go against this.)

2. Debug output. I don't mind loggers that use the USB channel which is also used for programming (and these days, often for power too) as a first up solution. But when I am going to be spending a lot of time designing and debugging and there is a spare UART and associated pin available - give me that every day. Especially when you have several boards that are supposed to be working together and don't, and every time you run a new test you have to reconnect every damn terminal. A dedicated UART out with your favourite terminal on the end just stays up as long as the host is up, even when you power cycle the target. Saves a lot of time in the end.

3. LEDs. Please please HW guys - give me at least one LED. You can find the space. When other stuff doesn't work or you are in the bootloader with no debug - a simple LED can make such a difference ... oh and by the way, bring a bunch of those "spare" GPIOs out to something I can solder a wire to as well.

Thanks for reading. To be honest this stuff seems so old-fashioned and trivial I wonder a bit why I am bothering you with it - but, it keeps coming up so it cannot be as universal as I think it should be, I guess. Either that or I am hopelessly stuck in the past ...

Failure of the Week

From Tony Whitley:

Dominic Valentino wrote "While riding my bike the other day, my GPS enabled bike computer had a little math issue. Although I've sailed to the Dry Tortugas a couple times, I've never ridden my bicycle there at 4500 mph!"

Have you submitted a Failure of the Week? I'm getting a ton of these and yours was added to the queue.

Jobs!

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.

Joke For The Week

These jokes are archived here.

Martin Buchanan sent this:

Asimov's Laws of Robotics running on Linux:

Kill him!

"I'm sorry Dave. I can't do that."

sudo Kill him!

"Sure thing, no problem."

About The Embedded Muse

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. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at info@ganssle.com for more information.