原创 What does typical mean? Take two

2014-6-18 17:58 1029 3 3 分类: 消费电子

Last year, I wrote a blog on the folly about using “typical” specs when designing systems. My sense is that a lot of feedback were from older engineers. As one of those myself, I have to confess that eons ago, as a freshly-minted EE, I was a rather careless designer. Need a pull-up? Any old resistor would do. Capacitors? Sure, select one based on voltage and capacitance. I rarely thought about tolerances, temperature effects, and the myriad other factors that make a circuit reliable in production.

But sometimes there were problems, and I learned that between the lab and the manufacturing line lies a huge gulf.

Fortunately, a mentor appeared, an older engineer who was a complete pain in the you-know-what. He critiqued everything. We had to justify the smallest design decisions. He’d demand small changes to meet his notion of getting things reliable.

We all hated him.

 

But a strange thing happened. These carefully-reviewed designs worked. All the time. Customers weren’t ticked off. And it turns out that it’s actually interesting and rewarding to think through design decisions with care.

 

Another mentor appeared, a chemical engineer turned sailing bum. He taught me to apply the engineering method to building and maintaining ocean-going sailboats, where failures can be life-threatening. No fitting was too unimportant to think about from a stress, wear, and materials standpoint. Dan taught me to generalize the engineering mindset to life in general. Some politician makes an odd claim? Do the numbers. What’s likely to happen to the teenagers on that weekend at the beach? Do a worst-case analysis and develop contingency plans.

 

It drives my wife crazy.

 

In that article about typical specs I complained that the vendors spew “typical” numbers, but they admit that these aren’t tremendously useful for design. That thwarts any attempt to do careful engineering analysis when building a system.

Consider this excerpt from an ARM datasheet:
 


My mentor of yore is rolling is rolling in his grave. This dearth of hard data makes it impossible to create a reliable design.

As reader DaveSchabel replied in the comments to my earlier article “I'm not sure if the manufacturers realize that poor datasheets often eliminate an otherwise superior device from design-ins.”

It wasn’t always this way. Here’s an example from TI’s 1976 TTL Databook for the 7447A BCD to seven segment decoder/driver:
 


Note that all of the specs have a max or min number, and the data shows what conditions those numbers apply to (e.g., Vol is with Vcc-MIN, Vih=2, Vil=0.8, Ioh=-200 uA). The typical specs aren’t much different from the worst-case numbers. Compare that to some MCUs whose max sleep current, in those rare cases where one is listed, might be two orders of magnitude greater than the listed typical.

Admittedly, in the olden days just a few pages were enough to fully document a part. Today a thousand page spec isn’t uncommon, and that immense document commonly leaves out important information. Properly characterizing a component isn’t easy.

Here’s another datasheet – it’s from a box of Entenmann’s donuts:
 


These are worst-case specs. They are guarantees. Contractual terms between Entenmann’s and the buyer. You know what you’re getting.


Min/max specs, too, are guarantees. “Typical” is not. Why would one risk using a part that the vendor refuses to guarantee?

Just last month an FAE from a large vendor told me some of their typical numbers are really marketing tools. Does that mean they can change with the competitive landscape? “Our competitor just dropped their typ specs; we better do the same!"

Me, I want a guarantee.

What’s your take?

文章评论0条评论)

登录后参与讨论
相关推荐阅读
jack.breakpoints 2016-04-18 17:49
What would you change about C?
If you’re an old-timer you’ve most likely written code in a large number of languages that have ma...
jack.breakpoints 2016-04-18 17:33
A look at a new embedded heap manager
Many of us don’t give much thought about the math our compilers do. Toss off a call to a sine func...
jack.breakpoints 2016-04-15 17:12
Why names are critical
The Linux printk function has various logging levels, which include KERN_EMERG, KERN_ERR and other...
jack.breakpoints 2016-03-14 19:02
What do you think of ultra-low power watchdogs?
I have written extensively about designing ultra-low power systems that operate from coin cells. U...
jack.breakpoints 2016-02-26 21:58
Comment headers: The best and the worst
I read a great deal of code. The vast majority is in C with some C++ and a bit of assembly sprinkl...
jack.breakpoints 2016-02-12 17:58
What's your take on knobs?
In a recent Embedded Muse Richard Wall reviews the latest version of Digilent’s Analog Discovery U...
广告
我要评论
0
3
1
2
3
4
5
6
7
8
9
0
广告
关闭 热点推荐上一条 /6 下一条