Tweet Follow @jack_ganssle
Go here to sign up for The Embedded Muse.
TEM Logo The Embedded Muse
Issue Number 329, May 15, 2017
Copyright 2017 The Ganssle Group

Editor: Jack Ganssle,

   Jack Ganssle, Editor of The Embedded Muse

You may redistribute this newsletter for non-commercial purposes. For commercial use contact

Editor's Notes

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. See for more details.

I'm now on Twitter.

Quotes and Thoughts

"Without requirements and design, programming is the art of adding bugs to an empty text file." - Louis Srygley

Tools and Tips

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

Rick Altherr had some links regarding capacitors, which I wrote about in the last issue:

Regarding capacitors, James Lewis ( gave a presentation at Hardware Developers Didactic Galactic (HDDG) back in February 2016 on the various capacitor technologies (aluminum, ceramic, tantalum).  He brings his experiences from working at Kemet to explain each technology, their unique properties, and evidence against some of the myths around capacitor selection.  His slides are available at and a full video of the presentation is at

Chris Hills wrote:

We (MISRA) now have a MISRA Video channel on you tube ( and the latest video of our extensive collection of three videos  is the History of MISRA-C from the beginning.    ( An interview with Les Hatton (author of Safer C) Olwen Morgan and Gavin McCall (Visteon  and MISRA C Chairman 2000-2008 )   On the developments  from 1994 that lead to the first MISRA-C

It highlights that the first MISRA-C was actually developed from a coding standard developed for a medical application and that  it was never specifically an automotive coding standard.

Greg Nelson had a good experience with a tool vendor:

I wanted to publicly express my gratitude (and total exhilaration) over the tech support I recently received from Saleae, the maker of low-cost but high-performance logic analyzers that I first read about here in the Embedded Muse.

I received a hand-me-down Logic16 from a colleague, and when I went to use it, I found that one of the input channels was malfunctioning in a strange way.  After muddling along with a "Logic15" for a few days, I thought I'd just write to Saleae to see if they had any suggestions for recalibration or other steps that might make it work for me.

They did far better: they offered (within 12 hours) to send a replacement device!  Their only request was that I run through a couple of simple steps to confirm that the problem was with the device and not e.g. my circuit.  After that confirmation, they shipped out a replacement device and even a prepaid shipping envelope to return the defective unit.

I want them to receive the credit they deserve for this.  If all of our tool and component vendors had tech support that was even close to this, our lives as engineers would be so much simpler - we could focus on solving the design challenges that we love instead of the support nightmares we hate.  Right now, for example, I'm on day 3 of waiting for an (unnamed) FPGA vendor to get back to me and explain why their synthesis tool runs in batch mode inside their IDE, but rejects it as a license violation when I try to run it from the command line, as our department's configuration manager would like to have an automated build process for the production release.

Thanks once again to Saleae for upping the ante in the quality of support we should expect from our tool vendors!

Freebies and Discounts

Debugging an RTOS based system is hard. Even if your code is logically "correct", when you have multitasking and asynchronous events occurring you may get strange behavior and transient faults which are difficult to capture, never mind recreate. Percepio's Tracealyzer is like a logic analyzer for your RTOS-based software. It records and visualizes your software at RTOS level, to help you understand what's going on.

This month's contest giveaway is a full Professional Edition of Percepio Tracealyzer for the RTOS of your choice. One lucky Muse reader will win this at the end of May when the contest closes. Thanks to Percepio for donating the Tracealyzer for the contest.

Enter via this link.

Engineering Isn't Supposed to Be This Way

In my naive youth I once commented to my dad (a mechanical engineer) that "engineering is so pristine and above the fray of marketing, sales and the chaos of business." He laughed. Forty years later I, too, am somewhat jaded, though do feel that engineering is a noble profession. Unfortunately, outside influences can corrupt the process, and many engineers themselves are resistant to the important realities of business. Seeing yet another disaster recently, I was reminded of this column I wrote for EDN in 1997:

Day 1. My boss, an engineer from the old pre-CAD days, has successfully brought a generation of products from Acme Toaster Corporation's engineering labs to market. Bob is a wonder of mechanical ingenuity. All of us in the design department have the utmost respect for him, so I was honored today when he appointed me the lead designer on the new Acme 2000 Toaster.

Finally, after 4 years of undergrad work in mechanical engineering at MIT, and almost a decade working in the appliance group here at Acme, they've recognized my talents and have given me the responsibility I've yearned for. I'm excited about this challenge.

Day 6. We met with the president, head of sales, and the marketing VP today to hammer out the project's requirements and specifications. We agreed to meet a cost of goods of $9.50 in quantities of 100,000. I've identified the critical issue in the new design: a replacement for the timing spring we've used since the original 1922 model. Research with focus groups shows that consumers set high expectations for their breakfast foods. Cafe latte from Starbucks goes best with a precise level of toastal browning. The Acme 2000 will give our customers the breakfast experience they desire.

I estimated a design budget of $21,590 for this project, and final delivery in 7 weeks. I'll need one assistant designer to help with the drawing packages. This is my first chance to supervise! I'm looking forward to making the hire and mentoring this person.

Like all Acme meetings we reached these decisions by consensus. The company is family owned and is operated, well, I guess the best word is "gently". The little friction that occurs is always resolved fairly. We work hard but in harmony. It's a place I hope to retire from in 30 years, as my father did.

Day 23. We've found the ideal spring material. Best of all, it's a well-proven technology. Our projected cost of goods is almost a buck-fifty under goal.

The rough prototype (completed in just 12 days from the go-ahead!) has been servicing the employee cafeteria for the last week without a single hiccup. Toastal quality exceeds projections. There's still a lot of work ahead, as we do the production engineering that is so important to producing a reliable product.

Day 24. That block of Acme stock sold to the Mackenzie family in the 50s was just snapped up by a major aerospace company which had run out of defense contractors to acquire. At a company-wide meeting we were assured that this was an investment only, and that nothing will change. They will send in a couple of auditors, but this is just to help us find ways to do things more efficiently.

Day 30. I showed the Acme 2000's exquisitely crafted toastal timing mechanism to Ms. Primrose, the new engineering auditor today. The single spring and four interlocking lever arms are a thing of beauty.

I wonder if her constant sniffing annoys the others as much as it does me?

Day 36. The design is complete. We're starting a prototype run of 500 toasters tomorrow. I'm starting to wrap up the engineering effort. My new assistant did a wonderful job. We're cleaning up the drawings and getting ready for our next project.

Day 38. Suddenly a major snag. Bob called me into his office. He seemed very uneasy as he informed me that those "on-high" feel the Acme 2000 is obsolete. Something about using springs in the silicon age.

I reminded Bob that the consultants had looked at using a microprocessor, but figured an electronic design would exceed our cost target by almost 50% with no real benefit in terms of toastal quality. "With a computer our customer can load the bread the night before, program a finish time, and be presented with the perfect slice of toast when he awakens," Bob intoned as if reading from a script.

Day 48. Chuck Compguy, the new microprocessor whiz, scrapped my idea of using a 4 bit dedicated CPU. "We need some horsepower if we're gonna program this puppy in C," he extolled, while I stared fascinated at the old crumbs stuck in his wild beard. "Time-to-market, you know. Delivery is due in 3 months. We'll just pop this cool new 8 bitter into it, whip up some code, and ship to the end-user."

"What's an end-user'?" I muttered as I headed back to the office, wondering what had happened to our original schedule.

Day 120. The good news is that I'm getting to stretch my mechanical design abilities. Chuck convinced management that the old spring-loaded press-down lever control is obsolete. I've designed a "motorized insertion port", stealing ideas from a CD-ROM drive. Three cross-coupled safety interlock microswitches insure the heaters won't come on unless toast is properly inserted. We're seeing some reliability problems due to the temperature extremes, but I'm sure we can work those out.

Day 132. New schedule; delivery now expected in three months. We've replaced the 8 bitter with a Harvard Architecture 16 bit 3 MIPs CPU.

Yesterday Bob spent over an hour yelling at the engineering team. Chuck just shrugged his shoulders and whispered "This always happens." I hope Bob is OK; maybe he's just short on sleep.

Day 172. New schedule; delivery now expected in three months. Bob spends a lot of time throwing stuff in the lab. For the first time I've actually been working weekends. I mentioned it to Chuck and he mumbled "Saturday? Saturday? It's Saturday? So what, we always work weekends."

Day 194. The auditors convinced management we really need a GUI with a full-screen LCD. "You're gonna need some horsepower to drive that," Chuck warned us. "I recommend a 386 with a half-meg of RAM." He went back to design Rev J of the PCB.

Bob is starting to look a lot like Dilbert's boss, even to the hair sticking up vertically.

Day 268. We've cured most of the electronics' temperature problems with a pair of fans, though management is complaining about the noise.

Bob sits in his office all day, door locked, drinking Jack Daniels. Like clockwork his wife calls every night around midnight, sobbing. I'm worried about him, and mentioned this to Chuck. "Wife? Wife? Yeah, I think I've got one of those, and 2 or 3 kids too. Now let's just stick another meg of RAM in here, OK?"

Day 290. New schedule; delivery now expected in three months. Chuck has gained even more weight; his teeshirts are ripped, though I'm not sure if that's from the extra flab or from stiffening caused by congealing food.

We gave up on the custom GUI and are now installing Windows CE. The auditors applauded Chuck's plan to upgrade to a Pentium with 32 Mb of RAM. There's still no functioning code, but the toaster is genuinely impressive. Four circuit boards, bundles of cables, and a Gb of hard disk. "This sucker has more computer power than the entire world did 20 years ago," Chuck boasts proudly.

Day 340. The toast application sometimes starts but often gives General Protection Faults. The auditors are considering Chuck's solution - have the end-user call in the GPF address to our new toll-free support line. We'll send the end-user a complementary slice of bread.

Day 384. New schedule; delivery now expected in three months. Toastal quality is sub-par. The addition of two more cooling fans keeps the electronics to a reasonable temperature, but removes too much heat from the toast. I'm struggling with baffles to vector the air, but the thrust of all these fans spins the toaster around.

Bob seems worse. All day long we hear him keening "Kill them all! Kill them allllll!." After the acquisition our medical plan was downgraded so there's little help available for him. "I've seen it all before," Chuck confided in me, "I told 'em not to remove the mental health benefits."

Day 410. We switched from C++ to Java. "That'll get them pesky memory allocation bugs, for sure" Chuck told his team of 15 programmers. This seems like a good idea to me, since Java is platform independent, and there are rumors circulating that we're porting to a Sparcstation.

Day 480. New schedule; delivery now expected in three months, just as soon as we get those last few bugs resolved. To reduce power consumption the computer now sequences fans alternately, but this seems to cause toastal burning during Java's garbage collection phase. Chuck has assured us that a new release of the Virtual Machine is almost due, which will probably cure this problem.

The carted Bob off on a stretcher today. It's a shame all of the new hires in engineering never got to know him in his prime. They watched sullenly as the paramedics wheeled him out, muttering things like "Another one down. They'll never take me out like that."

Day 530. I mastered the temperature problems by removing all of the fans and the heating elements. The Pentium is now thermally bonded to the toast. We found a thermal grease that isn't too poisonous. Our marketing people feel the slight degradation in taste from the grease will be more than compensated for by the "toasting experience that can only come from a CISC-based 32 bit multitasking machine running the latest multi-platform software."

We're having some problems with the TCP/IP suite Chuck's networking group (now up to 23 programmers) wrote. Management agreed to purchase a commercial package, though our royalty costs for various software components is already up to $23 per toaster.

His OS department figured out how to get real time software upgrades downloaded with hardly any effect on toastal quality. They're trying to reduce boot time to 10 minutes.

The user's manual is taking shape. The product documentation team has done a tremendous job, producing a 4 color 700 page manual in only twice the time anticipated.

When I asked what we'll do with all of these developers after the product ships, Chuck told me "why, move them to the help desks, of course! Plus, we'll need a decent sized group for bug fixes."

Day 610. Delivery date unknown. Bob slipped away from the asylum last night and managed to insert a virus into our network. As I left work this morning the police were dragging him away, cackling and screaming with a maniacal grin on his face.

The virus destroyed all of our software. "I meant to tell them to start a version control team," Chuck mumbled. "Well, this is really good news. I have some great ideas on how to improve the code. It always pays to toss out version 1 anyway."

Editor's note: This diary was found clutched in Mr. Widget's hand after his body was recovered from the fire. Acme's press spokesman's commented "we sincerely regret Mr. Widget's suicide, but remain committed to the best in toastal quality through the use of the latest technology."

In related news, Mr. Charles Compguy was made Acme's CEO today.

We Need Simpler Ways to Access I/O on MCU

In Muse 321 I discussed the problem of dealing with very complex I/O on modern MCUs. Several readers wrote responses which, for some reason, fell to the end of my to-do list.

Ben Egglestone wrote:

My take on it is vendor libraries is they are useful for getting to know what to do/ interpreting the datasheets, but for production code with anything low level they are rarely useful for two reasons (in my examples I'm thinking about opening a timer, but often applies to almost any "peripheral" like a port):

1) They are too generic in their names  - you write "OpenTimer0", when you want to say "StartButtonPressTimer" i.e. something that is relevant to the design you are working on.

2) They are too generic in the behaviour - sometimes they automatically start the timer, sometimes they don't, sometimes you can control whether they start it or not, sometimes you can't, sometimes you want them to start it, sometimes you don't.  They cater for all options of how to set up the resource when all you need is one otherwise you have a set-up headache.  You end up inspecting their source so much and correcting their behaviour (e.g. stopping an automatically started timer) - you may as well write it yourself.

Everyone thinks that a nice drag and drop GUI for peripheral set-up will be a silver bullet – but in the embedded world these details are often very important and until you know how that peripheral works deep down then these are just storing up bugs for you to fix later.

Harlan Rosenthal contributed this:

One of your correspondents mentioned ST's STM32CubeMX.

ST's HAL libraries, even worse than the CMSIS libraries before them, are a bloated mess of unnecessary complexity.  The runtime components are inefficient, and the initializations (where efficiency is immaterial) are unclear and badly structured.  In particular, the utility merges together all initializations, so that components are all activated at once, which may be disastrous for components which are only optionally activated, or need to delay until other conditions have been met. 

Steve Peters found a timesaver with CodeWarrior:

Regarding setting up I/O (and other things) on complex MCUs, I second Jack Everett's comment on NXP CodeWarrior Processor Expert I used on Freescale DSP.  Graphical representation can attach ISR or preconfigured utility "beans".  Wizard generates ISR shell and mainline code to configure.  Fill body with customized code.  A big timesaver, while warning about inappropriate or conflicting settings.


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

Note: These jokes are archived at

From Wes Perry:

A man in a hot air balloon realised he was lost. He reduced altitude and spotted someone below. He descended a bit more and shouted, "Excuse me, can you help me? I promised a friend I would meet him an hour ago but I don't know where I am".

The man below replied, "You're in a hot air balloon, hovering approximately 30 feet above the ground. You're between 53 and 54 degrees north latitude and around 2 degrees west longitude".

"You must be an engineer.", said the balloonist.

"I am", replied the engineer, "how did you know?"

"Well," answered the balloonist, "everything you have told me is probably technically correct, but I've no idea what to make of your information and the fact is, I'm still lost. Frankly, you've not been much help at all. If anything, you've delayed my trip with your talk."

The engineer responded, "You must be in management".

"I am" replied the balloonist, "but how did you know?"

"Well," said the engineer, "you don't know where you are or where you're going. You have risen to where you are due to a large quantity of hot air. You made a promise, which you've no idea how to keep, and you expect people beneath you to solve your problems. The fact is you are in exactly the same position

Advertise With Us

Advertise in The Embedded Muse! Over 27,000 embedded developers get this twice-monthly publication. For more information email us at

About The Embedded Muse

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

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 for more information.