As most of you probably know, finding information hidden in a datasheet can be really, really confusing. There is no standardized way datasheets are arranged, they are often translated from another language by someone with subpar translation skills, and, let's face it, the content can be just down right mind-numbing.
As such, we have created a tutorial that guides you through "How to Read a Datasheet." This tutorial is the first of many "bite-size primers" (yum!) you will start to see go live in the next few weeks. We hope that this helps you decipher that datasheet you've been slogging through for a few days!
Hey SF, I really appreciate you guys, and now this series. <br />
I started reading the data sheets about 3 years ago when I was introduced to the Arduino. I tried and tried to understand all of it, but it was like Greek. Over time, it has become a little easier as I am learning more. But there are still things that only a 'real' engineer would understand.<br />
So, that said, I am not an engineer. I am the average Joe with a severe maker streak. I grab onto these things rather quickly, but as a guy who has not been to college for it, there is a TON to learn. You guys and folks like you (Adafruit, Igo, Arduino...) are really awesome for helping us get our legs underneath us where others would rather see us fail. I am not sure if we are a threat or what, but there seems to be plenty of resistance to the idea standard world getting control of some of this stuff. <br />
<br />
I would love to see a break down on how to pull info like the address for I2C and then take it a step further on how you might use it to write that into code. This is something that I just am having a really rough time wrapping my head around. <br />
<br />
Anyhow.. thanks! You guys rock. Please keep doing what your are doing.
I've just come to accept that a datasheet isn't going to be easy to read. Half of the time, the datasheet is just a sales sheet that talks about the features of the product and what the different product numbers mean. You have to contact the manufacturer directly to get a real datasheet.<br />
<br />
Good intuition is always useful as well. I was adding an Altera FPGA to a PCB and was reading through all the documentation. Altera was recommending decoupling capacitors in the 'mF'. I remarked to my mentor that I'd never heard of decoupling caps in the millifarads, seemed large. At the design review, one of the engineers asked why the decoupling caps were so large, and we all found out that in the documentation for that particular FPGA, Altera chose to use 'mF' to mean microfarad.
Tutorials for newbs on how to read datasheets and schematics are wonderful idea's, although I don't think it takes an engineering degree to figure it out your own, just time and a bit of critical thinking. <br />
<br />
But the move to surface mount has hurt in the fact that it's not so trivial to burn something up now, as the rework is a pain and even if you're using a dip adapter your wasting an expensive IC and its adapter. not to mention there are crazy amounts of new form factors for footprints it seems, and everybody has their own. That drives me absolutely mad sometimes. a database of footprints would be nice, and I know SF has one for the stuff it carries in eagle, but one like the chip databases that not only has all the differing footprints, but in all the other common layout programs as well.<br />
<br />
And since SF is able to reach into china for cheap parts, could you guys please consider carrying a surface mount resister assortment kit that doesn't cost a crazy amount? something that matches another stores 1/4W axial kit in indiv. values would be super cool.
With the obvious enormous differences between analog and digital devices, a standardized datasheet makes no sense.<br />
<br />
Not to mention the fact that specialized and hybrid devices can need 50 or 100 pages of datasheet to describe their operation.<br />
<br />
Do we really want to make all datasheets a hundred pages long just to standardize them? Or do we want to leave out critical info in order to keep everything standardized.<br />
<br />
Who cares what the noise figure is of an LED? Who wants to know the power handling capability or rise time of a thermistor?<br />
<br />
What we're really in need of is standardization of datasheets for "similar" types of components.<br />
<br />
While the government and military procurement contracts go a long way to create some sort of standardization of specs - still more industry standards committee meetings are in order to create more common component definitions. Unfortunately, such meetings cost money and may not be in the best interests of some of the players.<br />
<br />
I think it best that we not count on corporations to do the job, and either learn to read and understand what is written, or create our own "standards" and rewrite the component specifications of others as a public service.<br />
<br />
Otherwise, it ain't gonna happen.
The arm documentation is an horror, every manufacturer makes what they want, each one do what they want, thats and all the stupid lack of free functional compilers and IDE's, is based in gcc but you must pay to use it!!
This is one reason I'm loyal to PICs even though I've been tempted to switch to other micros: they may be slow and have pathetic amounts of RAM but they've got some of the best datasheets I've ever seen.<br />
<br />
Every function on the chip is documented by a short summary, a detailed description, a table of the registers involved, a timing diagram and most importantly a listing of assembly or C code that's tested and known to work!<br />
<br />
AVR documentation is quite good as well but I still prefer Microchip's format.<br />
<br />
What I hate most are some of those ARM chips which comes with a second proprietary DSP core or networking hardware that you can't get the full documentation without entering into an NDA. And even then, the documentation tend to suck.
Now there's a job for somebody:<br />
Sit in a room with a list of ICs,<br />
A breadboard,<br />
An oscilloscope,<br />
A logic analyzer,<br />
A Multimeter,<br />
A magnifying glass,<br />
A ruler,<br />
Adobe Acrobat,<br />
<br />
Write useful Datasheets, with accurate pinouts, descriptions, etc...<br />
I mean, yea yea, somebody's getting paid to do that for the manufacturers but for the sake of the consumer, how about a second opinion? lol...
I grew up on datasheets, lol. I don't fear them anymore, but it can be incredibly frustrating and there seems to be a lack of accountability on the part of the manufacturer. I've seen incorrect datasheets float around for the same IC for months before they get revised...
In addition to the fine tutorial, now days, there are more considerations. Data sheets are written by humans, thus may have errors, omissions, changes, etc. So:<br />
<br />
a) Read the entire data sheet, especially the parts that you have made up your mind do not apply to you. It ALL applies.<br />
<br />
b) Check with the vendor for errata. Get it. Read it. Whether or not you think it applies to your project.<br />
<br />
c) Don't trust it 100%; get a second opinion. Find a forum, users group, etc. where real world experiences exist about surprises.<br />
<br />
d) Design defensively and be prepared for changes. If at all possible consider getting a development board from the vendor.<br />
<br />
Not all these things are possible all the time. Sometimes, YOU are the first victim to use the new part.
Couldn't agree more. Especially with D. Defensive design is something that few engineers these days are doing, and at a time when it needs to be applied even more. (Think the Apple iPhone's antenna: "You're holding it wrong." Thanks, Steve.)<br />
<br />
I agree with buying the eval/dev kits, but at times when that's not an option, I always point people to the reference designs and application notes. They do help fill in the blanks in a datasheet. <br />
<br />
Congrats on the job offer :-)
Would you like a job? You are so right... RTFM is your friend! Or, RTFE (e - everything!)
Best idea ever...<br />
<br />
I am almost done with my 3rd semester of my Electrical Engineering major, and I have yet been taught anything about datasheets. The lab instructors just throw them at us and expect us to figure it out. Typically though, in the lab, things are simple enough and do not require much more than a basic pin diagram. But in my free time when I am trying to program PIC's and stuff I dread having to dig through any datasheet.
A good tutorial would be how to read the timing/clock scheme and translate it to Arduino, Basic Stamp, PIC, etc. commands (i.e. ShiftIn, ShiftOut, , PulseIn, msDelay)<br />
Thanks!
This might be the best product SFE's ever developed. Thanks once again, guys!
I don't know if it's just that I'm getting old and cantankerous but it seems like they aren't what they used to be. I've been slogging through an NEC uP datasheet trying to understand how to use some of the peripherals & it's like it was written by someone from Mars.<br />
<br />
I don't think that an ISO/IEEE spec would help though. People would look at the spec & once the minimum was met they'd stop. It'd be like plumbers & electricians "but it meets Code!". What no one seems to realize is specs & codes are the MINIMUM acceptable.
jdf2525 "I don't know if it's just that I'm getting old and cantankerous"<br />
<br />
Oh! Don't get me started... It's not just you. I've just about given up on even spending the time to read data-sheets. I recently made a board with 3 different chips that the data-sheets didn't know what NC means. It means, and has meant for many years, No Connection. It does not mean <br />
"don't connect or else things will blow up." <br />
<br />
One, a 12A switching supply (2 on the board), had 3 pins (out of 133 in an LGA package) to be used to reinforce the physical mounting. These were further explained as "no internal connection". This was true for 2 of the 3, the third pin forcefully shut down the output. How long did it take me to find that? when the LGA pins are under the chip on a 12 layer board? when the data-sheet explicitly says "no internal connection"?<br />
<br />
Another, a Flash memory, went even further to state that the NC pins could be driven or left floating. As per normal human practices, these pins were merged into the ground plane, along with several interspersed labeled ground pins. The only thing is, two of these NC pins were actually unlabeled VCC pins, resulting in a direct short through the chip to the ground plane. How long did it take to find that?...<br />
<br />
Another chip on this board, a 1517 pin (not a typo!) BGA, had one set of pins labeled NC, and another labeled DNU (Do Not Use). Do you think I am going to believe what the data-sheet actually says as I wire up a $4000 chip? <br />
<br />
Timing diagrams are even worse. Polarity matters! Phase relationship matters! TIMING matters! That is why it is called a timing diagram. The information provided in some 'timing diagrams' is completely un-helpful. Pretty pictures... yeah, I get it, you can work "Paint" or something similar. A pencil scribble drawing with correct information would be much more useful.<br />
<br />
The data-sheet is supposed to be so that you don't have to get a chip, breadboard it, and randomly try wires and interface circuitry till you can get it to work. Instead, all too often today's data-sheets are created by people who really don't care. Standards aren't what is needed. What is needed are people who care, and who have at least half a clue.
Captain, I am detecting large amounts of flaming in this sector!!<br />
<br />
However, I feel your pain. Yet -- not to kick you whilst on the ground, I advise against connecting anything that is labeled as "NC" to anything. They do say "no connection" for a reason...<br />
<br />
And I do agree with you about the fact that people need to care in order to translate/transmogrify/create datasheets. (The transmogrification is for interpreting Chinese/Japanese)
Not a flame, just the facts. The original poster noted the declining quality of many current 'data-sheets'. I am simply agreeing, with recent examples.<br />
<br />
NC, no connection, means, and has meant for many years, no - decades, that there is No Connection to circuitry inside the chip. One of the examples I gave went further to expand the definition as "No internal Connection" and "these may be driven or left floating". To distort this to mean that you should not make any connection to this point defies logic. <br />
<br />
There are a wide variety of other terms that are available for "Do Not Connect", "Do Not Use", "For Testing Only", etc. Perhaps the examples I gave could have used "/Power-Supply Shutdown" on one, and "Vcc" for the others, rather than "NC".<br />
<br />
It is apparent that many of the people who are writing these 'data-sheets' don't consider them important enough to even turn on the spell-checker, much less actually insure that the information is accurate. <br />
<br />
In any writing, it is important to write in a way that is easy to understand. In technical writing it is important to write in a way that is difficult to mis-understand. Technical writing is an art, an art that many people simply do not have.<br />
<br />
Or use my site, ChipDB: www.chipdb.net<br />
It has pinouts and basic specs for a few hundred common ICs. (4000, 7400, microcontrollers, etc.) And if a part you like isn't on the site, you can add it.<br />
<br />
I built ChipDB because I hate slogging through PDF datasheets on my slow Linux machine just to find out what pin x on some chip is for, I hope it can be of use to the SparkFun community!
msarnoff: Or use my site, ChipDB: www.chipdb.net<br /><br />
That site looks really cool. You should talk with the guys behind Octopart.com about it.<br />
Oddly enough, these pass few days I have been slogging through Analog Devices datasheets. I think IEEE or ISO need to develop a standard for datasheets. In fact, I'm surprised there is not one already, considering how important they are.
Great tutorial! It'll definitely help people out in finding the info they need for the ICs they are looking at getting.