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

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.

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 )
^^^^^^^^^^^^^^^^^^^^^

LOL

> 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?

Generate transactions by SPI, but control the CS signal as GPIO.
I.e. assert the CS, read the required number of bits by SPI, deassert 
the CS.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

"Bill" <a@a.a> wrote in message 
news:5gnca5d000ql2jlabkd42od9tv1mcgr9b0@4ax.com...
> 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.

Hello Bill,

On my web site you can find a VHDL model of the ADS8320  - which won't help 
you much with using the SAM. In the end I didn't use an FPGA on that project 
but I bit banged the ADS8320 from a micro. (It was so long ago that  have 
forgotten which one !)

Can you get anywhere by doing what TI hint at and do 3 times 8 bit SPI 
transfers for each sample ?

Michael Kellett

www.mkesc.co.uk 

On Tue, 08 Sep 2009 09:11:13 -0500, Vladimir Vassilevsky
<nospam@nowhere.com> wrote:


>> 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 )
>^^^^^^^^^^^^^^^^^^^^^
>
>LOL

:-) Sorry. TI. I'm using other Analog Devices ICs.

>Generate transactions by SPI, but control the CS signal as GPIO.
>I.e. assert the CS, read the required number of bits by SPI, deassert 
>the CS.

But still, bye bye DMA.


I'm very curious... what were the guys at TI (and at some other
companies) thinking when they designed this ADC with SPI interface?
Which SPI hardware were they thinking would be able to pull out data
in one transaction? Does anyone know of an MCU with SPI hardware able
to do this? Amazing.

Best,

Bill wrote:
> 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. [ ... ]
> 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.

You have Peripheral DMA Controller, use it.  This is for a Microchip ADC, 
but the three-byte transfer might resemble your problem.  The method on the 
ADC side was written up in the MCP3008 datasheet.  Code fragment:


inline void poll_mcp3008 (int pad)
{
        // Mode-register bits to select each of the MCP3008s, with MSTR bit 
set 
..
        static const int modecsbits[4] = {0x000F0001 ^ (1 << (16+0))
                                                   , 0x000F0001 ^ (1 << 
(16+1))
                                                   , 0x000F0001 ^ (1 << 
(16+2))
                                                   , 0x000F0001 ^ (1 << 
(16+3)) 
};
        // set SPI_MR(PCS) to select the pad
        AT91C_BASE_SPI->SPI_MR = modecsbits[(pad >> 3) & 3];
        // prime buffer with a start bit, 'single' bit, and channel number
        pan_buf[0] = 1;                                 // start bit
        pan_buf[1] = 0x80 | ((pad & 7) << 4);   // 'single' bit, channel 
number, 
2 pad bits and space for high 2 bits of value
        pan_buf[2] = 0;                                 // pad space where 
low 8 
bits of value will appear
        // start a conversion
        SPI_RwBuffer (AT91C_BASE_SPI, pan_buf, sizeof pan_buf);
}


And the SPI-RwBuffer added to the spi library routines (based on the other 
SPI routines):


unsigned char SPI_RwBuffer(AT91S_SPI *spi,
                                    void *buffer,
                                    unsigned int length)
{
    // Check if the first bank is free
    if (spi->SPI_RCR == 0) {
        // set up to overlay the write buffer with incoming data ..
        spi->SPI_RPR = (unsigned int) buffer;
        spi->SPI_RCR = length;
        spi->SPI_TPR = (unsigned int) buffer;
        spi->SPI_TCR = length;
        spi->SPI_PTCR = AT91C_PDC_RXTEN | AT91C_PDC_TXTEN;
        return 1;
    }
    // Check if second bank is free
    else if (spi->SPI_RNCR == 0) {

        spi->SPI_RNPR = (unsigned int) buffer;
        spi->SPI_RNCR = length;
        spi->SPI_TNPR = (unsigned int) buffer;
        spi->SPI_TNCR = length;
        return 1;
    }

    // No free bank
    return 0;
}


In this case the data from the MCP3008 overlays the buffer that contained 
the tranmitted request.  It doesn't have to be this way, but it was easy to 
implement.  SPI device interrupts when the full 3 bytes have been 
transferred both ways.


        Mel.

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

On Tue, 08 Sep 2009 17:23:27 +0200, Bill <a@a.a> wrote:

>On Tue, 08 Sep 2009 09:11:13 -0500, Vladimir Vassilevsky
><nospam@nowhere.com> wrote:
>
>
>>> 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 )
>>^^^^^^^^^^^^^^^^^^^^^
>>
>>LOL
>
>:-) Sorry. TI. I'm using other Analog Devices ICs.
>
>>Generate transactions by SPI, but control the CS signal as GPIO.
>>I.e. assert the CS, read the required number of bits by SPI, deassert 
>>the CS.
>
>But still, bye bye DMA.
>
>
>I'm very curious... what were the guys at TI (and at some other
>companies) thinking when they designed this ADC with SPI interface?
>Which SPI hardware were they thinking would be able to pull out data
>in one transaction? Does anyone know of an MCU with SPI hardware able
>to do this? Amazing.

I haven't done a lot of (er, any) looking but one processor that I'm
using right now has a configuration register for its SPI peripheral to
do 8 to 16 bits per transfer, so two 11-bit transfers would be easy
enough to set up. NXP's LPC2119/2129. No DMA in this one, but (okay, I
did a little looking) the LPC24xx chips support configurable transfer
lengths and DMA on their SSP peripherals.

-- 
Rich Webb     Norfolk, VA

On Tue, 08 Sep 2009 11:23:38 -0400, Mel <mwilson@the-wire.com> wrote:


>You have Peripheral DMA Controller, use it.

I would gladly use it, but I don't think it is possible. DMA is not
able neither to automatically change CSAAT (Chip Select Active After
Transfer) configuration between 8-bit transactions 2 and 3, nor to bit
bang CS to my needs.

Best,

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

If Englich is not yuor frist langwige, have someone else read if to you.

See Bottom of page 10 again !

don


> 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.

>>I'm very curious... what were the guys at TI (and at some other
>>companies) thinking when they designed this ADC with SPI interface?
>>Which SPI hardware were they thinking would be able to pull out data
>>in one transaction? Does anyone know of an MCU with SPI hardware able
>>to do this? Amazing.
>
>I haven't done a lot of (er, any) looking but one processor that I'm
>using right now has a configuration register for its SPI peripheral to
>do 8 to 16 bits per transfer, so two 11-bit transfers would be easy
>enough to set up. NXP's LPC2119/2129. No DMA in this one, but (okay, I
>did a little looking) the LPC24xx chips support configurable transfer
>lengths and DMA on their SSP peripherals.

No, no... the ADC cannot see CS going up and then again down between
two transfers, because that would reset the conversion process. That
means I have to bit bang CS or change CSAAT configuration (a bit that
determines whether CS remains low after each transfer) between the two
transfers. And, of course, no possible DMA.

So, in other words, your LPC2119 cannot do that in one transfer,
either, and I doubt that the DMA in the LPC24xx will be of any use, in
this problem.

Best,