On Sat, 26 Jul 2014 09:11:30 -0400, Steve Goldstein <sgoldHAM@alum.mit.edu> wrote:>On Fri, 25 Jul 2014 16:46:53 -0700, John Larkin ><jlarkin@highlandtechnology.com> wrote: > >> >>Why are mixed-signal part data sheets so terrible? > >IMO it's because the parts can be very complicated, and the datasheets >are often not written by the designers but by apps people, frequently >younger engineers, who just aren't as familiar with their intricacies. >Designer reviews are often cursory because many designers think this >work is boring or beneath them and don't take it seriously. And these >are _all_ engineers, who often lack technical writing skills. > >I've been working on a datasheet for a fairly complex mixed-signal >product for much of the last two months, and intermittently for >several months before that. It's now at 112 pages, and still only >covers internal stuff we need to guide the design team, like register >and functional definitions. It doesn't yet include the required >customer-facing things like detailed specifications, applications >data, and performance plots (that have to wait for silicon). It's >based on several successful prior product generations, so I can re-use >parts of those earlier datasheets, but *every* section so far has >required extensive data table and text changes to cover the expanded >functionality of the new product; it's safe to say that I've had to >modify every paragraph for content, clarity, and accuracy. The public >datasheet will be a bit shorter because I can remove the proprietary >internal and DFT stuff. I *am* the (lead) designer, and still find >errors during reviews of what I thought were completed sections. > >Writing a good datasheet is surprisingly hard work. It's a pity that >more companies (and engineers) don't recognize the importance of the >task and treat it with the respect it deserves.The analog parts of things like ADCs and DACs are usually pretty good. It's the digital sections, like the SPI interfaces, that can be really awful.. both in design and in documentation. The timing diagrams are often horrors. We use one ADI chip that has an SPI command to change which clock edge the SPI interface works on! I have a product that used a Burr-Brown ADC, which TI has replaced with a "drop-in equivalent." Except that I used to use \CS to select the chip, and now the appnotes all ground \CS. Writing a good manual is hard work, too. Lots of examples, rather than abstraction and meta-expressions, helps. A "quickstart" example would be great: "To make this DAC work like a DAC, do this...". Hey, how about a Windows program that asks you what you want to so, and furnishes the exact data (and waveforms) that will do it? I've done things like that for some of our products. 112 pages is impressive, but it suggests that the part is very complex. In some mixed-signal parts, like ADCs, they are way too complex. I don't need an ADC to have a complex internal calibration subsystem; I will do calibrations in the uP or FPGA. It's crazy to have a DAC that has pages and pages of (typically confusing) documentation about dozens of internal registers. -- John Larkin Highland Technology Inc www.highlandtechnology.com jlarkin at highlandtechnology dot com Precision electronic instrumentation
AD7793 error?
Started by ●July 25, 2014
Reply by ●July 26, 20142014-07-26
Reply by ●July 26, 20142014-07-26
On Sat, 26 Jul 2014 09:40:31 -0400, krw@attt.bizz wrote:>On Sat, 26 Jul 2014 09:11:30 -0400, Steve Goldstein ><sgoldHAM@alum.mit.edu> wrote: > >>On Fri, 25 Jul 2014 16:46:53 -0700, John Larkin >><jlarkin@highlandtechnology.com> wrote: >> >>> >>>Why are mixed-signal part data sheets so terrible? >> >>IMO it's because the parts can be very complicated, and the datasheets >>are often not written by the designers but by apps people, frequently >>younger engineers, who just aren't as familiar with their intricacies. >>Designer reviews are often cursory because many designers think this >>work is boring or beneath them and don't take it seriously. And these >>are _all_ engineers, who often lack technical writing skills. > >More likely, they're overworked and have other fish to fry. Checking, >particularly other people's work, is the first thing to go out the >window. > >>I've been working on a datasheet for a fairly complex mixed-signal >>product for much of the last two months, and intermittently for >>several months before that. It's now at 112 pages, and still only >>covers internal stuff we need to guide the design team, like register >>and functional definitions. It doesn't yet include the required >>customer-facing things like detailed specifications, applications >>data, and performance plots (that have to wait for silicon). It's >>based on several successful prior product generations, so I can re-use >>parts of those earlier datasheets, but *every* section so far has >>required extensive data table and text changes to cover the expanded >>functionality of the new product; it's safe to say that I've had to >>modify every paragraph for content, clarity, and accuracy. The public >>datasheet will be a bit shorter because I can remove the proprietary >>internal and DFT stuff. I *am* the (lead) designer, and still find >>errors during reviews of what I thought were completed sections. > >Processor architecture documents are similar. A few thousand pages is >certainly not unusual. The public datasheets that large are common. >Ours were written by the architects, then rewritten by the designers, >and again by the verification engineers. > >>Writing a good datasheet is surprisingly hard work. It's a pity that >>more companies (and engineers) don't recognize the importance of the >>task and treat it with the respect it deserves. > >Apparently, it's often done after the part is cooked. That never >works out. > >Anyone else notice that Asian and European datasheets are particularly >bad? Content free. It's not just the translation (but that's a part >of it).The NXP ARM chips are good, but the documentation is often terrible. I think lots of chips nowadays include purchased IP blocks, like Ethernet or ADCs or whatever, that come with their own style and quality of documentation. How much current does the ADC in that ARM chip use? Nobody knows. And you futz with the queued SPI interface until it works. -- John Larkin Highland Technology Inc www.highlandtechnology.com jlarkin at highlandtechnology dot com Precision electronic instrumentation
Reply by ●July 26, 20142014-07-26
"jmariano" <jmariano65@gmail.com> wrote in message news:95516264-0d30-4a8c-9fc1-00640dca9e16@googlegroups.com... Dear All, I'm currently evaluating the AD7793 \Sigma-\Delta converter. I'm using an Aduino Due (SAM3X8E) connected to the ADC through SPI with CS permanently tied low. I use the Arduino's SPI library to control the SPI UART and AD's library (available on-line) to access the ADC. After correcting a couple of bugs in both libraries, I'm able to read the AD7793 on-chip registers but something wired happens. From two of them, I don't get the values sated on the datasheet. Were's what I get (power-on defaults): Register Datasheet I get ----------------------------- ID 0xXB 0x4A <- datasheet states that ID code for 7792 is 0xXA STATUS 0x88 0x48 IO 0x00 0x00 MODE 0x000A 0x000A CONF 0x0710 0x0710 OFFSET 0x800000 0x800000 FULLSCALE 0x5XXX00 0x54BB00 Do you thing this could be a mistake on the datasheet or is something wrong in my code? (I really don't have a clue!) Regards jmariano +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ If you have (n)CS permanently low on an SPI link the device cannot synchronise. I assume you are trying to use a gated burst on the SPI clock? Normally the device synchronises on the first edge after the nCS line drops- otherwise you effectively have the devices input and output shift registers potentially misaligned to your expected data. Andy
Reply by ●July 26, 20142014-07-26
On Sat, 26 Jul 2014 07:25:10 -0700, John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:>On Sat, 26 Jul 2014 09:40:31 -0400, krw@attt.bizz wrote: > >>On Sat, 26 Jul 2014 09:11:30 -0400, Steve Goldstein >><sgoldHAM@alum.mit.edu> wrote: >> >>>On Fri, 25 Jul 2014 16:46:53 -0700, John Larkin >>><jlarkin@highlandtechnology.com> wrote: >>> >>>> >>>>Why are mixed-signal part data sheets so terrible? >>> >>>IMO it's because the parts can be very complicated, and the datasheets >>>are often not written by the designers but by apps people, frequently >>>younger engineers, who just aren't as familiar with their intricacies. >>>Designer reviews are often cursory because many designers think this >>>work is boring or beneath them and don't take it seriously. And these >>>are _all_ engineers, who often lack technical writing skills. >> >>More likely, they're overworked and have other fish to fry. Checking, >>particularly other people's work, is the first thing to go out the >>window. >> >>>I've been working on a datasheet for a fairly complex mixed-signal >>>product for much of the last two months, and intermittently for >>>several months before that. It's now at 112 pages, and still only >>>covers internal stuff we need to guide the design team, like register >>>and functional definitions. It doesn't yet include the required >>>customer-facing things like detailed specifications, applications >>>data, and performance plots (that have to wait for silicon). It's >>>based on several successful prior product generations, so I can re-use >>>parts of those earlier datasheets, but *every* section so far has >>>required extensive data table and text changes to cover the expanded >>>functionality of the new product; it's safe to say that I've had to >>>modify every paragraph for content, clarity, and accuracy. The public >>>datasheet will be a bit shorter because I can remove the proprietary >>>internal and DFT stuff. I *am* the (lead) designer, and still find >>>errors during reviews of what I thought were completed sections. >> >>Processor architecture documents are similar. A few thousand pages is >>certainly not unusual. The public datasheets that large are common. >>Ours were written by the architects, then rewritten by the designers, >>and again by the verification engineers. >> >>>Writing a good datasheet is surprisingly hard work. It's a pity that >>>more companies (and engineers) don't recognize the importance of the >>>task and treat it with the respect it deserves. >> >>Apparently, it's often done after the part is cooked. That never >>works out. >> >>Anyone else notice that Asian and European datasheets are particularly >>bad? Content free. It's not just the translation (but that's a part >>of it). > >The NXP ARM chips are good, but the documentation is often terrible. I think >lots of chips nowadays include purchased IP blocks, like Ethernet or ADCs or >whatever, that come with their own style and quality of documentation.I was thinking about NXP (and ST) in particular when I included the Europeans. Their datasheets are, um, skimpy.>How much current does the ADC in that ARM chip use? Nobody knows. And you futz >with the queued SPI interface until it works.If you think that's bad, try their RF chips. They intentionally hide the innards so they have to do pretty much everything. TI has been known to have undocumented registers, too. The designers don't even know what they do ("try all the combinations").
Reply by ●July 26, 20142014-07-26
<krw@attt.bizz> wrote in message news:lfb7t9pd3f0mldv7kladtoel4nbjm5n6cr@4ax.com...> Anyone else notice that Asian and European datasheets are particularly > bad? Content free. It's not just the translation (but that's a part > of it).Here's an amusing example I ran across recently: http://www.adafruit.com/datasheets/WS2812B.pdf Note the power supply voltage: remind you of a certain Sandra Bullock movie? What happens when it drops below ... The formatting is just janky, clearly a novice writing in Word. The mech / layout drawings have text going every which way; the "VDD 5 DOUT" with the 5 backwards, especially. Good luck with those timings. Tim -- Seven Transistor Labs Electrical Engineering Consultation Website: http://seventransistorlabs.com
Reply by ●July 26, 20142014-07-26
<krw@attt.bizz> wrote in message news:fjp7t956dub6gpciinaromqocihvc0borq@4ax.com...> If you think that's bad, try their RF chips. They intentionally hide > the innards so they have to do pretty much everything. TI has been > known to have undocumented registers, too. The designers don't even > know what they do ("try all the combinations").Most people boggle their mind over the NSA/GHCQ's demilling of The Guardian's laptops (the ones they had Snowden docs on), the obscure chips they ground away -- PSU controllers and stuff. Doesn't seem strange to me. Many of those have low-functionality registers (i.e., poking bits into them doesn't put 5V on the CPU core or something drastic like that), that are easily acessible (via SMBus, etc.), which could be used to store information in a somewhat obscure way. Not much of course, but enough for a key at least. And taken over the whole system, probably enough for a message. As for undocumented registers, certainly there are things the manufacturers put in there for their own purposes; whether they're locked, invisible, functional or what, who knows; but it's likely the NSA has some ideas. Easily possible the NSA even has them synthesizing extra bits, or allocating otherwise-unused corners of array memory, for clandestine purposes. Even if they don't have design information from the manufacturer (or from decapping and inspecting the chip), it's probably enough that it's a possibility, even if they don't have it as a capability. As for destruction, even if the registers are SRAM or DRAM, they can retain info between power cycles, so they might go out of their way to destroy anything stateful, just in case. Tim -- Seven Transistor Labs Electrical Engineering Consultation Website: http://seventransistorlabs.com
Reply by ●July 26, 20142014-07-26
On 7/26/2014 9:40 AM, krw@attt.bizz wrote:> On Sat, 26 Jul 2014 09:11:30 -0400, Steve Goldstein > >> Writing a good datasheet is surprisingly hard work. It's a pity that >> more companies (and engineers) don't recognize the importance of the >> task and treat it with the respect it deserves. > > Apparently, it's often done after the part is cooked. That never > works out. > > Anyone else notice that Asian and European datasheets are particularly > bad? Content free. It's not just the translation (but that's a part > of it).I was working with one of the Atmel MCUs and realized they had no spec on the crystal. So I had nothing to provide to the crystal company to make sure I got a crystal that would work. I asked the FAE for info on this and it ended up with some data added to the data sheet. However, they gave the info for four specific frequencies in the range without specifying which values should be used between those frequencies. lol Once they made a change to the data sheet, I guess it was enough work that they weren't going to fill in the blanks. They probably have to go through a review process that means a 5 minute change to the document takes many man hours of work. -- Rick
Reply by ●July 26, 20142014-07-26
On 2014-07-26, Tim Williams <tmoranwms@charter.net> wrote:><krw@attt.bizz> wrote in message > news:lfb7t9pd3f0mldv7kladtoel4nbjm5n6cr@4ax.com... >> Anyone else notice that Asian and European datasheets are particularly >> bad? Content free. It's not just the translation (but that's a part >> of it). > > Here's an amusing example I ran across recently: > http://www.adafruit.com/datasheets/WS2812B.pdf > Note the power supply voltage: remind you of a certain Sandra Bullock > movie? What happens when it drops below ... > > The formatting is just janky, clearly a novice writing in Word.> The mech / layout drawings have text going every which way; the "VDD 5 > DOUT" with the 5 backwards, especially. > > Good luck with those timings."VDD DOUT" are pin labels "5" is a dimension (5mm) -- umop apisdn --- news://freenews.netfront.net/ - complaints: news@netfront.net ---
Reply by ●July 26, 20142014-07-26
On 7/26/2014 6:18 PM, Jasen Betts wrote:> On 2014-07-26, Tim Williams <tmoranwms@charter.net> wrote: >> <krw@attt.bizz> wrote in message >> news:lfb7t9pd3f0mldv7kladtoel4nbjm5n6cr@4ax.com... >>> Anyone else notice that Asian and European datasheets are particularly >>> bad? Content free. It's not just the translation (but that's a part >>> of it). >> >> Here's an amusing example I ran across recently: >> http://www.adafruit.com/datasheets/WS2812B.pdf >> Note the power supply voltage: remind you of a certain Sandra Bullock >> movie? What happens when it drops below ... >> >> The formatting is just janky, clearly a novice writing in Word. > > >> The mech / layout drawings have text going every which way; the "VDD 5 >> DOUT" with the 5 backwards, especially. >> >> Good luck with those timings. > > "VDD DOUT" are pin labels "5" is a dimension (5mm)The point is that you turn your head one way to read the dimensions and turn your head the other way to read the labels. The convention is to turn the text counter clock wise or not at all, not to turn anything clockwise. Some times this happens because an image is drawn the correct way but then rotated to fit on the page better. The choices then are to have some text rotated clockwise or to have some text upside down. I guess the clockwise text is preferred. In this case the labels did not need to be rotated at all. Also the dimensioning lines are not drawn properly... I expect this was drawn by someone inexperienced using conventional drawing tools. -- Rick
Reply by ●July 26, 20142014-07-26
On Sat, 26 Jul 2014 15:10:16 -0500, "Tim Williams" <tmoranwms@charter.net> wrote:><krw@attt.bizz> wrote in message >news:fjp7t956dub6gpciinaromqocihvc0borq@4ax.com... >> If you think that's bad, try their RF chips. They intentionally hide >> the innards so they have to do pretty much everything. TI has been >> known to have undocumented registers, too. The designers don't even >> know what they do ("try all the combinations"). > >Most people boggle their mind over the NSA/GHCQ's demilling of The >Guardian's laptops (the ones they had Snowden docs on), the obscure chips >they ground away -- PSU controllers and stuff. > >Doesn't seem strange to me. Many of those have low-functionality >registers (i.e., poking bits into them doesn't put 5V on the CPU core or >something drastic like that), that are easily acessible (via SMBus, etc.), >which could be used to store information in a somewhat obscure way. Not >much of course, but enough for a key at least. And taken over the whole >system, probably enough for a message. > >As for undocumented registers, certainly there are things the >manufacturers put in there for their own purposes; whether they're locked, >invisible, functional or what, who knows; but it's likely the NSA has some >ideas.Undocumented, sure. We had registers the users knew nothing about but none were user accessible. That's not what I was talking about, though.>Easily possible the NSA even has them synthesizing extra bits, or >allocating otherwise-unused corners of array memory, for clandestine >purposes. > >Even if they don't have design information from the manufacturer (or from >decapping and inspecting the chip), it's probably enough that it's a >possibility, even if they don't have it as a capability. > >As for destruction, even if the registers are SRAM or DRAM, they can >retain info between power cycles, so they might go out of their way to >destroy anything stateful, just in case.All completely irrelevant.
