Octal Buffers and an ADC

Go To Last Post
21 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Im looking at the AD9240 ADC. The datasheet is located at: www.analog.com/en/prod/0,,AD9240... It's a serial device so that there are 14 pins representing a single bit. Obviously it would be a bad idea to directly interface a microcontroller because if I inadvertantly configure the pins as outputs I might destroy something. Looking at the data sheet it shows the SN54HC541 buffer. Is this sufficient protection for the ADC? www.focus.ti.com/lit/ds/symlink/...
Thank you for your help.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ADCs are usually interfaced directly, there isn't much that can go wrong.

Leon

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

leon_heller wrote:
ADCs are usually interfaced directly, there isn't much that can go wrong.

Leon


Ok. So I can ditch the buffers and just interface directly to an Atmega. What are these devices typically interfaced to? The implementation is really simple but rather heavy on the number of pins needed to interface.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well for starters let's correct a few things you said in your initial post. Firstly, it is NOT a serial device, it is a parallel device. Secondly, the 14 pins represent a single sample, not a bit. (each pin is 1 bit of the overall sample value) Accidentally configuring your MCU pins as outputs, when you are trying to read from the ADC will be bad, with or without, buffers.

Parallel devices like this are designed to sit directly on a CPU's bus, with minimal additional logic.

If you want to save pins, pick an I2C or SPI based (serial) device. On a general CPU, serial devices would require additonal interface logic. The AVR already has many of these serial interfaces built in, so you can readily use them, and save both external logic, and pins over the parallel implementation.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

glitch wrote:
Well for starters let's correct a few things you said in your initial post. Firstly, it is NOT a serial device, it is a parallel device. Secondly, the 14 pins represent a single sample, not a bit. (each pin is 1 bit of the overall sample value)

Sorry.
Quote:
If you need to save AVR I/O pins you could use an A/D converter with a SPI serial interface. I just tried the Parametric Search function at the Analog Devices website and got several hits for a 14 bit, single supply ADC with SPI interface. Unfortunately I am not able to figure out how to cut and paste the link .

Thanks for the suggestion. The AVR is just going to be buffering the data so it's not a problem. As long as I have access to an external interupt and the uart I'll be fine.
Quote:
Accidentally configuring your MCU pins as outputs, when you are trying to read from the ADC will be bad, with or without, buffers.

True though why do they have the buffers in the evaluation board? You'll either blow up a buffer or the ADC. Is it just a sacrificial part? The buffer is $.70 while the ADC is $18.19.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So that it can drive a cable? The outputs of the buffer have series resistors.

Leon

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

buffers are used for a number of reasons.

If the part being interfaced to does not have an ouptut enable/disable, then buffers are used to disconnect it from the bus so that other devices can be accessed.

If the interface logic on the part and bus are at different voltage levels, the buffers are used to translate between the two.

Buffers are also used to increase drive strength on a bus, this may be important in high speed, or long distance applications.

In this case the part does not appear to have an output enable/disable pin, in which case the output drivers are always running, so you would want buffers if you were to put it on a bus with other devices. On the eval board they are there because the sinals will be going out over a cable.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

glitch wrote:
buffers are used for a number of reasons.

If the part being interfaced to does not have an ouptut enable/disable, then buffers are used to disconnect it from the bus so that other devices can be accessed.

If the interface logic on the part and bus are at different voltage levels, the buffers are used to translate between the two.

Buffers are also used to increase drive strength on a bus, this may be important in high speed, or long distance applications.

In this case the part does not appear to have an output enable/disable pin, in which case the output drivers are always running, so you would want buffers if you were to put it on a bus with other devices. On the eval board they are there because the sinals will be going out over a cable.


Thank you so much. Now all I have to do is pick an input configuration. I'll call Analog about that tomorrow because their data sheet is confusing me about Figure 35.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why do you need such a fast ADC?

Leon

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

leon_heller wrote:
Why do you need such a fast ADC?

Leon


Im measuring the voltage decay of a fuel cell as it's switched open.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You do realize that the AVR is not capable of handling the 10MSPS datarate. At 14bits, you need 2 bytes to store each sample, that's 20 mega-bytes of data per second. Even if you only used half the sample value, you can't pipe the data through the AVR fast enough (2cycles / sample @ 20MHz).

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You don't need a 10 MSPS ADC for that! That chip is intended for RF systems.

Leon

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

glitch wrote:
You do realize that the AVR is not capable of handling the 10MSPS datarate. At 14bits, you need 2 bytes to store each sample, that's 20 mega-bytes of data per second. Even if you only used half the sample value, you can't pipe the data through the AVR fast enough (2cycles / sample @ 20MHz).

Is there any solution to this problem? I could use a completely different microcontroller. I would like to know how you determined the datarate. The only other solution I can think of is rather torturous.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As I said, you just don't need an ADC with that spec. Simply choose a more suitable one!

Leon

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Adam_Y wrote:

Is there any solution to this problem? I could use a completely different microcontroller. I would like to know how you determined the datarate. The only other solution I can think of is rather torturous.

How I determined the data rate? That's easy... 10MSPS that's 10 mega samples per second, in other words 10 million samples per second. Each sample is 14 bits, thus you need 2 bytes to store it, so that is 20 million bytes of data per second, or 20 mega-bytes (per second) of data.

There are several ways to accomplish this, a faster CPU being one of them, but even then, that is a lot of data & I/O. Perhaps a better solution is to use a deep fifo to store the results (depth depends on how long of a sample period you need), and then read & process the captured data from the FIFO at a more leisurely pace.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

leon_heller wrote:
As I said, you just don't need an ADC with that spec. Simply choose a more suitable one!

Leon


The problem is that this isn't the first try. The first try was at 600kb/s and failed.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why is this even a trial & error thing?? You should be able to calculate the sample rate you need.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

glitch wrote:
Why is this even a trial & error thing?? You should be able to calculate the sample rate you need.

The trial and error thing was not my fault.:) This is a project that Im taking up and it just so happened that they tried another analog to digital converter before I came.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just how fast does a fuel cell decay? Do you have any idea or are you trying to find out? If this is a research thing, I would suggest that you beg, borrow, whatever, a digital 'scope and just look at it.

It seems very unlikely that such a cell would have a decay time constant faster than a few hundred microseconds, maybe 10s of microseconds. With one sample faster than every 2 microseconds, that previous one SHOULD have done it.

How did it "fail"?

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For monitoring a fuel cell virtually an ADC would do, surely.

Leon

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
It seems very unlikely that such a cell would have a decay time constant faster than a few hundred microseconds, maybe 10s of microseconds. With one sample faster than every 2 microseconds, that previous one SHOULD have done it.

I really explained the project horribly which is probably why the confusion is happening. I will be cutting off the current to a fuel cell and watching the voltage change. I believe the problem is the timespan. The data we are getting occurs in the timespan of microseconds. One document I found cites 10s of microseconds.
Quote:
Just how fast does a fuel cell decay? Do you have any idea or are you trying to find out? If this is a research thing, I would suggest that you beg, borrow, whatever, a digital 'scope and just look at it.

It's not a research project otherwise an oscilloscope would be perfect.
Quote:
There are several ways to accomplish this, a faster CPU being one of them, but even then, that is a lot of data & I/O. Perhaps a better solution is to use a deep fifo to store the results (depth depends on how long of a sample period you need), and then read & process the captured data from the FIFO at a more leisurely pace.

Sorry. I forgot all I need is at least 100 data points. On top of that I should have researched more. Please forgive me for the confusion. I've been dealing with construction work so my mind is a little frazzled.