标签: datasheets

Dejan Durdenic sent me an interesting email (reproduced below with permission): "If you look at part datasheets, they actually did not change for over 40 years. OK, the form has changed and it's now PDF instead of paper sheets or databooks, but contents are still the same." "Modern CAD software integrates 3D models into PCB design, then you have SMD landing patterns etc. etc. I think the time has come for some kind of a new standard to be defined that will integrate all of the relevant information into one file or set of files. So, when you download 'datasheet' from vendor's site, it will contain not only electrical specs. and details like now, but also schematic symbols, landing patterns for SMT, 3D mechanical model (very important for connectors, relays and similar bulky parts and manufacturers surely have the best one), IBIS and SPICE models where appropriate, maybe even some basic driver source code for complex devices like microcontrollers." An interesting idea. Why don't component vendors provide us with electronic files that will make their products easier to incorporate in our designs? Vendors of complex embedded semiconductors like SOCs do provide extensive software support. One company I know has 600 firmware engineers writing code to support a complex chip... and they give the code away. In fact, their engineers wind up doing most of the design of their customers' products, all to encourage the use of the rather inexpensive chip. ( The volumes are enormou s). Some companies provide reference schematics. Others go further – Analog Devices, for instance, adds Gerber files and the like to their reference designs. But most companies give us little other than PDF descriptions. Years ago product development proceeded at a far more leisurely pace than today. Pre-Web it took time to gather (by mail) design documents and datasheets. Competition was much more limited than it is now. But the Internet, globalisation, and the extraordinary complexity of the components we use have changed all of that, and most engineers I know are in a death march to get products out fast. Too many just do not have the time to really understand the parts in any depth. We're desperate for vendor-supplied code (which, all too often, looks great at first but is crap in a real application). I agree with Dejan: vendors could gain significant market share if they went beyond just providing code; they should provide useful electronic design files for their parts. Though there are compatibility issues between tools, in many cases converters are available. After all, they've probably created these files for their own use.  

A long time ago, hardware people designed all of their circuits. But in the vacuum tube days some wise engineer created modules. An example was a dual triode flip flop that would generally plug into a standard octal socket. Now others could reuse that design by buying the module and including it in their product. Later the integrated circuit formalized this notion, and today there's a veritable ocean of standard parts available. Datasheets carefully characterize their behavior; we buy them and wire them onto a board. That's the holy grail of reuse, and in some cases the software community does the same thing. We recycle an object module and link it into a new application. Alas, for reasons both good and bad we often monkey with the source instead, even though NASA has shown that once one changes more than about 25% of the source lines there's little benefit to reuse. Traditionally, vendors who supply proprietary code that will be included in a production system (like protocol stacks, operating systems and the like) provided libraries compiled on a particular CPU architecture. You link these into your code. But for as long as I can remember engineers grumbled that the provided API was both interface and insulation. Insulation, because who knows what boundary conditions lurk behind the often-inadequately documented API? Insulation, because it can be impossible to track down bugs that live in the nebulous region between your own code and that of the vendor. Who hasn't gotten frustrated by the poor docs that sometimes cause us to prototype an API call, tossing almost random data at a package in an attempt to understand just how one goes about properly interfacing to a package? We see it in the hardware, too, when a peripheral's control registers either don't work as advertised, or there's some bizarre combination of bits that drive the thing into a crazy mode. And yet there's a part of me that doesn't want exposure to the internals of some other company's code. I really don't want the source; I want a clean, clearly-defined interface that works as advertised. Returning to the hardware analogy, it's fun but unnecessary to look at the schematic of a flip flop. The interface at the pins is really all that's important. But in the software world we've all been burned enough that trust is scarce. Then there's the stability issue, especially in these strange economic times. If I have a package's source there's much less risk if the company goes out of business. I may not want to support the code, but that's better than getting set adrift by the seller's bankruptcy. Yes, it's possible to set up a source code escrow, but what are the legal implications of dealing with that escrow? Why add layers of hassle? What do you think? Is not having the source a deal-breaker? Or, conversely, does the source make a vendor's product more compelling to you?