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?
Best Answer
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.
...