Elecia on The Builder Circle, impossible bugs, and some links...

Programming note! Elecia was a recent guest on The Builder Circle by Pratik podcast with?Sera Evcimen. The Builder Circle is a?podcast for hardware entrepreneurs and builders to build a successful hardware product/system and company. Elecia talked about the building blocks of firmware, giving an extended intro to embedded systems and all their unique properties.Check it out here, which gives you all the possible ways to find the show as well as an embedded player. Thanks to Sera for having Elecia on the show!

A peek at Making Embedded Systems 2nd Edition

We have a?new section for you from Elecia's upcoming Making Embedded Systems, 2nd Edition, on Impossible Bugs: There should never be an impossible bug. And code should always compile and work the first time. Should is a stupid word. The key to impossible bugs is to make them possible, to stop thinking about how they can’t possibly happen and dig into how they are happening. There are two methods to doing this. The first method is to focus on reproducing the bug. The second method focuses on explaining the bug. You should use both, switching between them as you get stuck on one path.? Reproduce the bug For the first path, it seems obvious that the first step is reproducing the bug but it is the critical step. It doesn’t matter if you have to hop on one foot and cluck like a chicken, you have to make it happen again. And again. Steps that shouldn’t matter need to be recorded if that’s how the bug gets reproduced. Once you have that, go on to the other steps:

1. Reproduce the bug.
2. Reproduce the bug with the minimal amount of code.?
3. Go back to the last working version: does it still work? Can you find when the bug was introduced?
4. Reproduce the bug on command (or on boot) so you don’t have to do ten steps to reproduce it. Reduce the steps to reproduce the bug as much as possible.
5. After making exploratory tweaks, are you sure you are running the code you think you are?
6. Is this really the minimum amount of code needed to reproduce the bug?

When you’ve got a minimal code set, you may be able to post the issue on a vendor website, or use a debugger to find the issue, or get help from another person.? More likely, before you’ve gotten to step 6, you’ve gotten stuck. So you need to switch strategies. Explain the bug When someone asks me for help with a bug, the first thing I do is ask them to explain what they were trying to do. I’m no longer surprised when they wander off half-way through with their monologue. Explaining the bug helps you understand it better and see the disconnect between what you intend to do and what is happening. It is a more thinky type of action than reproducing the bug. Here are the steps:

1. Describe the bug’s symptoms.
2. Explain how the bug could possibly do what it does. List all possible causes (without using ground loops (but cosmic rays are ok)).
3. Explain the bug and what you’ve tried to a duck. If you realize you forgot to try something, note it down.?
4. Take notes on what changes have what effect. (You will not remember after the third tweak or fourth test attempt.)
5. What changed from the last known good code??
6. Get a code review.

Describing the issue seems so easy, but saying “it doesn’t work” isn’t enough. What doesn’t work? How is it different from expected? Is it a single version of code? On a single board? Be detailed.? The second step assumes the bug exists (this is harder than it sounds) then suggests using inductive reasoning to find the cause. It is backwards from most debugging: instead of finding the cause for the issue, you try to find all possible causes. You can even go a step further: if you were trying to make this happen, how would you do it? Explaining the bug only gets you so far. You can develop lots of theories and ideas, but then you need to take some data which means going back to reproduce the bug. You can’t fix what you can’t measure

.You can preview?the entire book in early access at O'Reilly, 10-day free trial or subscription required.?The book will be available in wide release in early 2024.

Links of distinction:

• We're currently enjoying the latest Murderbot Novel, System Collapse, by past guest Martha Wells.?
• A classic 80s synth, the Yamaha DX7, emulated and crammed into a USB dongle. A pretty cool project and seems like you could just attach this to a MIDI controller with USB out and be on your way? Here's a?brief overview of the DX7 if you've never heard of it.
• Understand malloc by implementing your own, by Dan Luu. Be sure to check out the exercises and thought experiments at the end.
• An?update to the very cool flower?badge made for Chaos Communication Camp 23. It's all open source hardware and software, so you can learn more or make your own. via Timon.

Upcoming Show

This week's show is with Yanina Bellini Saibene, all about technology education, and crossing the language barrier. Look for it on Thursday November 30th.?

Patreon To join the Embedded?conversation?on Slack, support us on?Patreon.

Interested in sponsoring the newsletter or the show? Drop us a line at sponsorship at embedded.fm and let's talk! ??

Sign up to our email newsletter here.