I'm currently evaluating the AD7793 \Sigma-\Delta converter. I'm using an A duino Due (SAM3X8E) connected to the ADC through SPI with CS permanently ti ed low. I use the Arduino's SPI library to control the SPI UART and AD's li brary (available on-line) to access the ADC.
After correcting a couple of bugs in both libraries, I'm able to read the A D7793 on-chip registers but something wired happens. From two of them, I do n't get the values sated on the datasheet. Were's what I get (power-on defa ults):
Good news: you just misread the datasheet. The AD7793 is supposed to respond "0xXB".
Cheers
Phil Hobbs
--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics
160 North State Road #203
Briarcliff Manor NY 10510
hobbs at electrooptical dot net
http://electrooptical.net
Ah, I just saw what you are talking about. You are saying the return value you are reading corresponds to a different part! I missed that before.
Check the data sheet for the 7792 and see if the status value matches. Maybe a part was mislabeled somehow or maybe these parts are the same die tested to different specs using a laser trim to set the ID code?
The 7792 is basically the same as the 7793, the only difference being the n umber of bits - 92 is 16 and 93 is 24. The datasheet for both parts is actu ality the same. At first I was convinced that I was having a timing error since the differe nce from A to B is the LSB, but if this is true, I don't understand why i'm reading 0x48 instead of 0x88 on the status reg (now the difference is on t he two MSB) and all the others are being read correctly.
On the other hand, if this is an error on the datasheet, AD would have swit ched the ID codes for both parts (so 92 would be B and 93 A) and wrongly st ated the default value of the status reg (should be 48 instead of 88).
So, before I plunge into the code armed with a scope, my question for you m ore experienced guys is: do you think this could be just an error on the da tasheet?
We use the AD7793 in several products, over 3000 pieces so far, and they work great. But we just read the analog value and ignore the ID and status registers. The 7792 and 7793 are probably the same chip inside, with some bits zapped or something.
ADI is making more errors on their data sheets than they used to, and seldom corrects them. Just got burned on the ADR363.
Why are mixed-signal part data sheets so terrible?
--
John Larkin Highland Technology, Inc
jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com
I don't have the data sheets here so I can't keep up with the values and part numbers. But I believe you are saying your ID matches the '92 and not the '93 while the status value does not match either part. I'm not clear on the status reg when you say the "default" value. What is the meaning of the bits that are different?
It has been a while since I've used SPI, but I seem to recall there is a signal that controls the framing. Isn't that the CS? There is a clock, data in and data out then the CS strobe says all the data has been shifted in so latch it, no? You say you aren't using CS, does that work?
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.
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.
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.
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 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
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
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):
I was thinking about NXP (and ST) in particular when I included the Europeans. Their datasheets are, um, skimpy.
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.
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.
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.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.