Re: 16-bit SPI trying to read from 22-clock cycle ADC

Bill wrote:
Hi,

I'm trying to pull out data from the ADS8320 (a 16-bit ADC by Analog
Devices. See bottom of page 10 in
http://focus.ti.com/lit/ds/symlink/ads8320.pdf ) using the SPI in an
AT91SAM7S256. The problem is that the ADC needs 6 extra clock cycles
to sample the analog signal, before the 16 cycles that will output
each of the conversion result bits. So, a complete ADC cycle involves
a minimum of 22 clock cycles. Now, the SPI in the AT91SAM7 (and, as
far as I've seen, in all other MCUs), cannot generate more than 16
clock cycles within one CS activation.

How am I supposed to do this, in an elegant way? Of course I could bit
bang those lines, but I hate doing that, because it adds load to the
CPU, and doesn't take advantage of the SPI and DMA.

The AT91SAM7S256 allows holding the CS low until a new device is
addressed, so I could initiate two 11-bit readings in a row (in such a
way that the ADC would think it is a single CS assertion with 22 clock
cycles inside), and discard the bits with no information, but that's
still ugly to me. It would use the SPI, but not the DMA, and the two
readings would be different (the first one should hold CS low. The
second one should leave it high), which is kind of non-homogeneous.

Any more elegant ideas?

Thank you.

Hi,

I wrote a driver for the (similar ?) ad7705. It was driven by a int
timer based state machine to sequence start of conversion, read result
etc, over the 2 input channels. This was on a Dragonball (68k) and iirc,
the spi port may have had a short queue to make life easier. There was
no cs on the spi port, so an io port line was used for chip select. I do
remember that the ads device was a little weird in terms of programming,
and there are some 'hinted' at issues in the data sheet, but the results were fine.

It was 2004, so would need to dig out the code, but would assume the
pragmatic approach was taken. ie: just wrote / read as many bytes as
were required to get at the device and masked off the unwanted stuff.

It's far from an inelegant solution if implemented and documented
properly...

Regards,

Chris





.

Quantcast