- Connect on:
Biography has not been added
- Typically typical
As many ones already pointed out, I firstly consider Min/Max specs for fundamental parameters, then the Typ ones just for values that need a "reference" in calculation, but that aren't so strict for functions. Again: if a manufacturer doesn't give the design limits for a very important parameter (in my application), I promptly avoid that part. I can tell I've seen people designing circuits (even very simple) based only on typical numbers, testing on a single unit, and start thousands parts manufacturing. Then, when some (or many) parts returns as "malfunctioning", they start choosing the manufacturer that suits best the so limited design (...), marking the others as "unreliable" (...) I'm sure that manufacturers should be clearer on given numbers, but designers should be aware that applying a 25V capacitor on a 25V line isn't such a cool convenience :) Two example complaints for manufacturers. MCUs supply current below 1 microAmp... I think there are so many variables (besides what is *really* active at those currents) that these specs have to be handled with care, as the circuit itself (or environmental humidity will account for more...) Thermal data: find as many ICs with "thermal protection" as you can, with Tja, Tjc data, and you'll be king. Mfrs seem to avoid data on it like a plague, "we've told it's protected, what more would you need?". Maybe "how to avoid entering protection state"? So the best you can do is often figure out data from similar packages: now, that's typical!
- Hope and horror
How do they make their reports? Two main answers pop up to mind, and you can take them in any order. a) They get payed for reports: and I mean it in the broadest sense you can get it b) They grow their self-esteem and "professional appeal" What then if they're wrong? Pace it too fast, in any near future you'll just remember what has become true ("hey, how advanced they were..."), and forget most of the wrong predictions -- as it already happens with any /other/ fortune-teller. I foresee I'm 99% right (...)
- Five dangerous coding standard rules
I agree with the article up to a certain point. As mentioned by someone else, there always are special cases, that need a workaround. So, when your cross compiler can't optimize a division with a shift, and that makes the difference, you're forced to use a shift: a good practice would be to comment clearly your code, and explain. The last case mentioned, with "static const" as a substition for "#define" brings in some troubles to people trying to optimize for code/memory space, as someone already wrote above -- having the variable allocated in memory. Even more, as described "enum" are better suited for a collection of related items; "static const" have module visibility, while "#define" is very often used in header files, included by many source files. So the last "rule" is that there are too many exceptions, to formulate an optimal rule.