(C) 2009 Hank Wallace

PREVIOUS – Embedded System Design Library: Common Trip-Ups
NEXT – Embedded System Design Library: Simplicity

This series of articles concerns embedded systems design and programming, and how to do it with excellence, whether you are new to the discipline or a veteran. This article is about problems out of our control that affect our embedded designs.

Do you think your program of 10,000 lines is complex? Well, it may be, but the hardware we run that program on is 100x as extensive, not to mention the OS. We cannot expect all that other IP to be perfect, and life sure gets interesting as a result.

How many embedded micros have you used that contained buggy peripherals? It used to be that manufacturers did not publish errata sheets for their parts, and we were left guessing. Sometimes I find errata sheets for parts I have used and I am disgusted to read that a program I wrote five years ago might be subject to that error, if a certain revision of part is used. YIKES!

I use past code as a basis for new projects much of the time, and I’m surprised at how many notations I find in my own programs that the hardware does not work as advertised. I see notes that read, “THIS IS NOT IN THE DATA SHEET.”

I used an ST AM/FM receiver chip some time ago that was so poorly documented that I had to create loops to write registers sequentially to see what all the bits did. Some of the information in the data sheet (for the hardware that was documented) was just plain wrong, or the hardware was nonfunctional. Can you spell “Rev A”?

Then, of course, if you program in Windows, there are always loads of OS bugs and documentation errors to brighten your day. For each one of those, my source contains a cheery, “Thanks, Bill.” And I have logged a bunch of those for sure.

We have to be extremely careful when using advanced features of the parts we design into our products. It’s highly likely that you are in the minority when you embark on the creation of a specialized PWM pattern, or chain hardware timers together, or behave with the least bit of creativity. Basically, if I don’t NEED to use an advanced feature of a peripheral or CPU, I avoid it, writing registers to disable all unused functions. This is safe.

Unfortunately, we have to use at least some of the hardware on-chip, and even with the simple baubles there are difficulties. Just take a scan at Microchip errata sheets and appreciate the number of problems they list with Timer 0. That’s the same Timer 0 hardware that was in place on the first PIC micro, some 20 years ago. Can they not get that right? Do they not have a comprehensive engineering validation suite for Timer 0?

I had the bad fortune of doing a USB design with a USB PIC recently. I found the USB micro models that fit my needs, found some sample code, and designed a test PCB. After construction, the sample USB code would not work. I purchased a USB sniffer program, but still no luck. I learned how the entire USB protocol works, but still no worky. However, I did find some code on a university student’s web page, and it did work! So at least the hardware was functional.

I was never able to get the Microchip sample code to work. That’s a risk we take when using these advanced, complicated peripherals. The sample programs produced by the manufacturer may simply never work, and there’s no one at the factory who knows why or cares. There are numerous other Microchip customers complaining loudly about this on the forums, but no help is forthcoming.

Another issue which catches us is the revision of chips we use. This comes in two flavors, changes to existing parts, and migration of function to upgraded parts with changes in the process.

We want our designs to be as portable as possible. To accomplish that, we must use as little of the function of each complex device as possible, to minimize our exposure to unintended changes. I cannot count how many times I’ve had a design working with Rev X of a device, only to find that Rev Y would not work. Sometimes I’ve been able to find some common ground to make both work, but often not. This has happened with modems and micros and even logic parts. But I have found that the less function I use, the more robust the design.

Regarding migration of code and hardware designs, we’re always looking for that next generation chip that will push our product to the forefront in the marketplace while allowing us to reuse most of our code and schematic. If only it were so simple.

Manufacturers advertise backward compatibility as a feature, but it rarely works out that way. Microchip is particularly bad in that respect. There are some thousands of PIC micros, theoretically compatible, but really not. It’s virtually impossible to port code from one PIC to another without having to scrutinize the data sheets of the old and new parts for differences. What is so special about a timer that they have to change the register layouts with every upgrade?

(2016 update: Just got a call from a customer who is using a PIC16C57 in a product I designed 15 years ago. That’s 15 years. It seems that Microchip recently changed the process for this part and did not take time to ensure that the oscillator gain and response is identical to the devices produced under the prior process. The net result is that the oscillator fails to function correctly! Isn’t that mind blowing? Couldn’t that graduate student on summer break have simulated the old and new oscillator block and tweaked it to the same gain and slope? So now I’m wasting time fixing a Microchip oscillator circuit for no good reason.)

Thus we must test, test, and retest all code and all hardware with every upgrade of every device. This would not be necessary if embedded designers were actually designing the chips we use, but, alas, that is not the case. The people who design the chips rarely ever build anything with them, and the marketing people care not one bit as long as their sales numbers are decent.

Even if we have a working design that is robust enough to weather chip revisions, it’s no good of we cannot buy the chips! There’s always the danger that a part will go out of production or on allocation. I saw an ad in a magazine just yesterday for a Cirrus audio DSP device. Way cool. I looked it up and it’s just what I need for a project. I checked distribution: 0 stock. So much for that. I’ll wait a year and check again.

I avoid parts shortages by designing in only parts that have a decent history, and are available by the 10,000’s in distribution. Netcomponents.com is good for determining this. There are certain manufacturers that I avoid religiously because they ship data sheets in volume, but very few parts. You should be very defensive about this. That sexy new part that replaces three chips on your PCB might be the death of your product line.

Author Biography

Hank Wallace is the owner of Atlantic Quality Design, Inc., a consulting firm located in Fincastle, Virginia. He has experience in many areas of embedded software and hardware development, and system design. See www.aqdi.com for more information.