12

My last question brought up some discussion about application notes and (bad?) practice. See the comments under the various answers.

Until now I thought: "Ok these application notes are written by electrical engineers working at some big companies, who probably know what they are doing."

But after reading the comments from my last question, I dont know whom to trust. If I had been studying electrical engeneering or had enough pratical experience, I probably would have enough knowledge to see bad practice / wrong application notes. But I am just a hobbyist.

So what should I do? Just go ahead and hope, that everything works fine, until something breaks. So I know the next time: dont do this. According to the comments in the linked question, this could be realy frustrating, because some faults come and go randomly. Maybe I do not even realize, that the design I took from the application note was wrong. I would probably search for a mistake in my design, because I am the unexperienced guy...

One thing I have learned so far from the comments in the other question is, that I should always look through the datasheets and search for things that exceed the operation ratings of the devices (it is not safe to just stay within the maximum ratings).

Is there anything else I should check in an application note, so I could identify a probably bad design and ask someone (e.g. here), whether it is realy bad design?

Community
  • 1
PetPaulsen
  • 2,335
  • 4
  • 22
  • 34
  • This has great value to many users, I am sure, but I think it needs to be CW. I am converting it so that this can be even more of a popularity contest. – Kortuk Feb 01 '12 at 19:25

4 Answers4

15

Ask Olin :-) - but wear a flame suit.

Unlike data sheets, which SHOULD be holy writ (but often don't quite make it), Application Notes are a very "mixed bag". It does not pay to just take what is in an AN as gospel, although you'd hope it was at least usable without magic smoke.

The following is opinion (of course).
people are most welcome to offer counterpoints to any assessment I make.

Code: When it comes to sample code that comes with AN's, you can expect that it is liable to be "somewhat rushed" if it was written speifically for the AN, and of perhaps grater quality if it builds on existing applications and libraries. Olin, who is far more qualified to speak on this than I am, will tell you that MOST AN code is poor or dangerous. It happens that Olin's company are top Microchip representatives and that Olin is the sort of perfectionist that you'd want as your developer and not want as your boss ;-). ie you can probably be slightly lss scathing about AN code that Olin is, but listen carefilly to his advice.

Hardware: With reference to hardware, you'd hope that an AN writer was highly competent. If the AN is regarding a reference design that they suggest you can use as the basis for a commercial product then you'd also hope they had put their top people on it. BUT if you make a lot of ICs and you want to suggest ways that people can use YOUR product then you can expect "the boy" to write at least some of them. SO be discerning - look at what is suggested and be prepared to find some bloopers.

Chip bloat: A factor which I recalled again tonight when looking at a TI app note is that there is a tendency to "gild the lily' - to use many ICs where fewer may do. Anyone would think they had some sort of interest in getting the IC's into circulation, or something.

Writer reputation counts for much - this is one place where "appeal to authority" has some merit. If Jim Williams wrote it then trust it. Jim died recently and all too many of the other classically trustable names have gone the same way.

Company reputation counts somewhat.

LT are usually good. Mainly with Jim to blame.

AD / Analog devices are usually very good.

NatSemi are a bit of a mixed bag with much good but nothing certain.

Microchip make great products but do rather tend to churn out the app notes.

Burr Brown tend to be keepers of the Holy Grail [tm} but having been acquired by TI the name could get used differently.

TI are usually quite good over many decades. They have acquired NatSemi and BurrBrown and others in recent years and will hopefully bring th average up and not down.

Zetex (acquired by Diodes Inc) make great great great parts (great!) but have been known to write less than perfect app notes.

Nichia tend not to write app notes but if they did you could probably frame them.

Luxeon/Lumileds / Ghost of Philips past write superb technical notes for LEDs. LLP understand LEDs unlike almost any others on the market and can be used to grow your knowledge base when looking at other products.

Atmel/AVR: Should stick to digital which they know very well. Actually usually very good - using body diodes as zero crossing detectors was a fit of momentary madness.

Hewlett Packard: Old School HP technical stuff was utterly utterly utterly superb. Utterly. Novo Riche HP if they produce app notes of relevance should be treated with care. Pass by on other side if in doubt. Agilent carries much of the mantle of the old HP and can largely be trusted.

Motorola of old not too bad at all. On Semi followed fairly well. Spun off children maybe also.

...

Community
  • 1
Russell McMahon
  • 147,325
  • 18
  • 210
  • 386
9

My solution with app notes: Simply ignore them. Think of them as Electronics for Dummies, too often written by dummies.

You may think that app notes are written by the same skilled people that designed the part, but that's just not true in many cases. I have seen company structures where most app notes were generated by the customer technical reps, and even marketing in a few cases. The tech reps write them because they are tired of answering the same question or finding the customer doing the same stupid thing over and over again. Marketing writes them because they want to show off how to use the product in a particular application they'd like to sell more into. Of course every company has at least some process for vetting app notes, but don't count on that being too rigorous. In some cases the design engineer may not even see the app note before it goes out. In other cases he's got real work to get on with and can't spend the proper time critiquing a flood of marginal app notes so sighs and gives approval or passes it off to a junior engineer who is too scared to say no to senior people.

Basically, the really good engineers are too valuable to write app notes. At best this is done by "application engineers".

The ultimate truth is in the datasheet. If you know what you're doing, there's really no need for app notes. At best they didn't screw up something. If you don't know what you're doing you shouldn't be responsible for the design. I suppose app notes can be adjunct material to help demystify things, but it's best to consider them as written by dummies for dummies because too many are.

As Russell said, different companies and different authors (when that is even known) have different cultures that you can learn are more reliable than others. However, be very careful with that. What may appear to be a company culture may be a single engineer in that company driving things. When he leaves, the quality may change significantly. About the only thing to trust is app notes written by select individuals who you recognize and know they uphold high standards. There are very very few of those.

Even "big names" can have bad days. A long long time ago in 1980 when I was a fresh engineer right out of school working for Hewlett Packard, it was strongly suggested to me by a senior engineer to use a new voltage to frequency converter chip from National Semiconductor in my design. The senior engineer said the part was designed by this guy Bob Pease who was supposed to be some kind of analog semiconductor god. So I read the datasheet carefully and a appnote written by said Bob Pease about using this part to make a high resolution A/D. The datasheet made sense, but the app note was seriously suggesting you could make a 22 bit A/D with this thing. The circuit in the app note had obvious sources of error way way exceeding 1/4 part in a million. I thought I must be misunderstanding something, so I did the math and proved my case carefully enough to show the senior engineer. He looked at it and agreed with me and kindof laughed saying "Yeah, BoB Pease seems to be a loose cannon lately, I think National is trying to reign him in a bit". It surprised my he was so tolerant and not more upset for something I considered blatantly wrong. Then he said "That's just a appnote anyway, it still looks like a good part". That's when I understood app notes are casually written and not meant to be taken more than casually.

Olin Lathrop
  • 310,974
  • 36
  • 428
  • 915
  • 7
    Sorry Olin, are you implying that application engineers are by definition not really good engineers? IMO application engineers have to be good and have a good understanding of a part to be able to apply it best: make use of the parts best features and avoid its traps, and do so in the most economic way. For this you need to have a good understanding of the datasheet. A company can afford to have its ANs written by a "really good engineer" if it helps customers to use the part properly, so that a well-designed part gets the credit it deserves. Just my two cents. – stevenvh Feb 01 '12 at 14:26
  • 2
    See - I told you what Olin would say :-). I'll admit to loving to look through app notes. There may be ideas or bits and pieces that get lodged in the brain and later on dredged out and used some other way. I have almost never built anything from an app note directly - they provide inspiration and seed material. As long as you understand what an IC should do and can do then an app note is a good guide. Rely on it over a datasheet and you may end up using body diodes to zero crossing detect mains or something else equally silly :-) – Russell McMahon Feb 01 '12 at 14:29
  • @stevenvh: There are good app notes out there and some are written by competent engineers, but the reverse is also certainly true. You can't rely on quality. Some apps engineers are very good, some not so, just like any other group of professionals. Apps engineers seem to be more focused on getting a job done than considering every nuance of the parts. Again, there are good ones and bad ones. For example, if John Day (top notch field engineer for Microchip) says something, I'll take it seriously. Coming from others I'll do a lot more checking. – Olin Lathrop Feb 01 '12 at 15:07
  • 1
    Many data sheets leave such substantial areas of ambiguity that it would be practically impossible for an engineer to make a useful design which didn't rely upon things which aren't actually specified. For example, suppose a latch has no specified minimum propagation time, a specified hold time of -5ns at 25C, and 5ns from -40C to +85C. Would it be safe to assume that connecting /Q to D would yield a circuit that would toggle the output, without going metastable, any time a clean pulse arrived on the clock input? On what basis could one assume that such a circuit would work at even 25.6C? – supercat Feb 01 '12 at 18:58
  • On a more app-note-related issue: I would expect that most parts are designed to operate reliably with some limited amount of current being sourced or sunk from a pin which would, absent leakage, pull the pin beyond the rails. Some chips can tolerate many milliamps; some may be disrupted by a few microamps. I doubt any chip's operation would be disrupted in the slightest by being connected to a 1,000-volt supply in series with a 6.2415Zohm resistor (letting through roughly one electron per second). I wonder why there's no guaranteed safe level (even if only 1uA)? – supercat Feb 01 '12 at 19:09
  • 3
    Some app notes offer designs that seem to assume a chip is capable of withstanding some amount of current (typically between 1uA and 1mA) on the protection diodes, but a lot of data sheets don't even guarantee that 1aA (i.e. about 6 electrons per second) would be safe. What should one assume about what one will be able to 'get away with' on present or future silicon? – supercat Feb 01 '12 at 19:12
  • @supercat: One should assume nothing from a appnote. The datasheet is where to find out what exactly the chip can do. – Olin Lathrop Feb 01 '12 at 20:32
  • @OlinLathrop: What should one assume from a datasheet? For example, given a latch chip datasheet (e.g. NXP 74HC74) should one one expect that connecting D to /Q will not violate setup/hold constraints and yield metastability? It is very normal in a design to connect pins that way, but is there anything *in the datasheet itself* that would justify it? – supercat Feb 01 '12 at 21:35
  • @supercat - without looking, that sort of thing is EXACTLY what I would expect to find in a good datasheet. Some manufacturers, especially those cloning products that have been in the world for a decade or few, may scrimp on what is there. BUT a real/good datasheet will tell you about timings and levels with loadings and much much more. If it is really useful we could look at that specific example or some others that are good. Anything designable should be able to be designed out of the data sheet. Sometimes it can be :-) – Russell McMahon Feb 02 '12 at 01:34
  • @RussellMcMahon: In the NXP 74HC74 datasheet at http://www.nxp.com/documents/data_sheet/74HC_HCT74.pdf can you identify anything that specifies that propagation delay will always exceed hold time? I would expect that factors which would influence one would influence the other, such that propagation delay would in fact always exceed hold time, but I see nothing in the datasheet that says that. On the other hand, feeding a 74HC74 /Q output into the D input is a very standard design. Should a well-engineered design using a 74HC74 add 3ns of explicit feedback delay, or would that... – supercat Feb 02 '12 at 16:04
  • ...be considered wasted expense since even at 6 volts typical propagation delay is 14ns, and typical hold time is -2ns, and process improvements which would reduce propagation delay below 3ns would also almost certainly improve hold times as well? – supercat Feb 02 '12 at 16:07
  • @supercat - I deleted my last comment as I now see you were going hold/propagation ... and I was going propagation/setup. | If I understand correctly you are saying that if you take the spec sheet at face value and allow one parameter to assume worst case value in one direction and the other worst case value in the other direction THEN "there may be trouble" BUT if you "sensibly" assume that the two parameters track so that both are highish or lowish or whatever in a given case then all is well - Should a prudent designer allow for the first case? – Russell McMahon Feb 03 '12 at 10:51
  • @supercat - ... Regardless of the answer to this interesting question it does not seem highly relevant to the diode conduction issue but I do get the connection :-) | The answer to your question is, if you are sending rockets to orbit, men (or women) to war or designing failsafe life critical systems then you either assume worst/worst OR talk to the manufacturer (or both). BUT if you are making LED flashers for Happy Meals then join Q to D. In between, use your brains and experience. If it matters enough to you, do some sampling of disparate batches and check correlation of trends. – Russell McMahon Feb 03 '12 at 11:17
  • @supercat - Over the last few ears I have spent a minor but significant part of my time doing testing of components and modules of various sorts to try and second guess Asian supplier and manufacturers who seem bent on making Murphy a gross optimist. Stuff as nasty as weighing batteries and noting the mass distribution shape within a box to detect change of batch (it helped). Measuring and plotting PV pa el characteristics O/C. S/C and loaded to try and improve batch quality and much more similar. No IC parameter correlations though :-). – Russell McMahon Feb 03 '12 at 11:21
  • @RussellMcMahon: I'm leery of simply checking whether things seem to work, because I had a design of mine produced for a couple years when a batch of 10,000 units (probably about $5 manufactured cost each) started showing an intermittent failure mode. Fortunately, even though the parts were OTP, I'd designed the code to allow limited tweaking (a design which definitely proved its worth), but a design which had been very reliable with a previous batch of parts proved quite unreliable with the later batch. – supercat Feb 03 '12 at 15:28
  • @RussellMcMahon: What I'd like to see would be an additional spec "minimum output-change to input-sampling time", with a note that if two latches are on the same chip or in the same manufacturing lot, provided the downstream clock reaches IHmin within that amount of time of the upstream clock reaching ILmax, the data will be latched correctly. Or, with regard to the diode issue... – supercat Feb 03 '12 at 15:32
  • ...I'd like a spec which indicated that correct operation would be guaranteed under any of a number of circumstnaces, e.g. if one connects a non-current-limited supply to e.g. VDD+0.3 or VSS-0.3, an unspecified amount of current may flow, but will not disrupt the chip's operation; likewise, if one sources a total of e.g. 2mA into VDD-clamped pins, provided VDD is externally clamped and no single pin exceeds 500uA, the pins will be clamped to some unspecified voltage low enough to prevent operational disruption. – supercat Feb 03 '12 at 15:38
  • In other words, basically say that if external factors limit the voltage to a certain limit, the chip will limit the current to an unspecified safe level; likewise, if external factors limit the current, the chip will limit voltage to an unspecified safe level. I wonder why data sheets don't generally specify such things at all, even if overly conservatively? – supercat Feb 03 '12 at 15:41
5

While it is quite true that many application notes are of poor quality or dubious merit written by inexperienced engineers (I use that term loosely) in an effort to simply sell product, there is more to the story.

Taking the best case of a highly experienced engineer taking his time and attempting to do a very good job, there are still inherent limitations. In particular assuming he builds and tests the circuit being described, and it works as described in his lab, it does not necessary mean that it will work for you. Building a working prototype is a lot different from building something that is easily reproducible by others under different conditions.

When you build a circuit from an application note it is highly unlikely that your parts and methods will be identical to those used by the app engineer. Something as simple as using a PC board with a different thickness could cause issues. Consider the case of a simple oscillator, if he used a capacitor specked at plus or minus 10% and his was on the high side and yours on the low it is possible that just this much difference could mean that one fails to oscillate, or oscillates at a harmonic rather than the fundamental frequency.

Particularity with analog and RF circuits it is seldom plug and play, one needs to be concerned with adjusting drive levels, naturalizing amplifiers, tuning filters etc. Getting this stuff right takes knowledge and experience.

So don't throw the baby out with the bath water. Application notes are not perfect, but they may be a great source of ideas. Take them with a grain of salt and be prepared to do the hard work of refining and testing the circuit yourself.

JonnyBoats
  • 4,108
  • 1
  • 17
  • 19
3

Application notes are a huge marketing tool for companies. These highlight your product's features, eases the learning curve for your client, and shows the quality of your support structure. All of this is done to persuade engineers to put a part on a BOM.

Granted not all companies take app notes as seriously as others, and often it is the young engineers on the team that are tasked to write them. This does not dilute their intended use. It is important to remember that app notes don't do the engineering work for you. They are templates; examples to help understand datasheet subtleties. They are rarely required, designed, or expected to be cut-and-paste modules.

spearson
  • 1,533
  • 8
  • 13