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

On Tue, 08 Sep 2009 09:59:00 -0600, don <don> wrote:

>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

I don't need English to be my first language to understand datasheets.

What do you exactly mean? Which piece of information did I miss?

On 8 Sep., 17:23, Bill <a...@a.a> wrote:
> On Tue, 08 Sep 2009 09:11:13 -0500, Vladimir Vassilevsky
>
> <nos...@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,

don't remember seeing much of anything spi especially DAC/ADCS that
didn't require all kinds of trick like bit banging CE, dummy data,
extra clocks etc..

guess it is a combination of analog guys doing digital design trying
to make it as small as possible with out thinking of what it will talk
to and digital guys doing SPI interfaces not realising all the special
cases that exist in the real world.

anyhoo, have a look at the SSC instead and see if it doesn't fit your
needs better than the SPI.

-Lasse

Bill wrote:

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

From what I'm seeing here, when the PDC is in charge, the SPI doesn't work 
in 8-bit transactions.  It works in a single transaction involving as many 
8-bit bytes as the PDC demands.  I see /CS go low, and while it's low 24 
clock pulses come out in a single burst, then /CS goes high and life goes 
on.  (This is with the code I posted.  Thank the deity for digital storage 
scopes.)

        Mel.

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

Freescale microcontrollers with queued SPI peripherals have no problems 
doing long SPI transfers.  Each individual transfer is from 8 to 16 
clocks, but you can specify that the chip select will not be deasserted 
after the first transfer, so that you can easily get 22 clock transfers. 
  There are many ColdFire's (and older 683xx devices) with a queued SPI, 
and the latest PPC-based MPC5xxx devices have even more powerful SPI 
peripherals connected to flexible DMA.

I don't know if that's what the guys at TI were thinking about, and I 
doubt if it really helps you here, but there *are* microcontrollers 
available that can handle all this in the background by DMA (/if/ you 
can understand the documentation...).

On Sep 8, 6:53=A0pm, Bill <a...@a.a> wrote:
> Hi,
>
> I'm trying to pull out data from the ADS8320 (a 16-bit ADC by Analog
> Devices. See bottom of page 10 inhttp://focus.ti.com/lit/ds/symlink/ads83=
20.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?
>
It appears strange. From my experience, normally TI would definitely
have some reasons for any such strange things.

In this scenario, bit banging appears reasonable. Well, that might
increase the CPU load.

The best help would be from the TI support.

Karthik Balaguru

"Bill" <a@a.a> wrote in message 
news:rq0da55nb0kfd0mns4kf5cijnsuv9v9knc@4ax.com...
> On Tue, 08 Sep 2009 09:59:00 -0600, don <don> wrote:
>
>>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
>
> I don't need English to be my first language to understand datasheets.
>
> What do you exactly mean? Which piece of information did I miss?

At the bottom of figure 3:

NOTE: Minimum 22 clock cycles required for 16-bit conversion. Shown are 
24 clock cycles.
If CS remains LOW at the end of conversion, a new datastream with 
LSB-first is shifted out again.



3, 8 bit transfers.

Cheers 

On Sep 8, 8:53=A0am, Bill <a...@a.a> wrote:
> Hi,
>
> I'm trying to pull out data from the ADS8320 (a 16-bit ADC by Analog
> Devices. See bottom of page 10 inhttp://focus.ti.com/lit/ds/symlink/ads83=
20.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.

I'm not familiar with your chip but if you are correct that the SPI
DMA transfer only allows a max of 16 bits per CS then you could fix
this in hardware. Although I believe it too is inelegant it does allow
you to use the software the way you want.

All you do is create some way so that every other CS is ignored or not
passed to the chip. That way you can initiate two SPI transfers in a
row but the ADC will seem them as one(the second CS will be removed in
some way in the hardware).

There are many ways to do this but does require extra hardware. A
simple flip flop should work or any clock div by 2 method or
equivalent.

On Tue, 08 Sep 2009 22:53:39 +0200, David Brown
<david.brown@hesbynett.removethisbit.no> wrote:

>> 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.
>> 
>
>Freescale microcontrollers with queued SPI peripherals have no problems 
>doing long SPI transfers.  Each individual transfer is from 8 to 16 
>clocks, but you can specify that the chip select will not be deasserted 
>after the first transfer, 

The AT91SAM7S256 also allows that. The CSAAT (Chip Select Active After
Transfer) that I keep mentioning in my other posts is exactly that.
But that is of no use here. It does not allow me to use DMA. I still
need manual intervention from the CPU to change that CSAAT bit so that
it is 1 for the first transfer, and 0 for the second transfer (the CS
cannot be always 0, because the ADC would never trigger a new
conversion). The DMA won't do that for me. And won't bit bang CS for
me, either.

In other words. Yes, I can specify that the chip select will not be
deasserted after the first transfer. But how about after the second
transfer? I need that the chip select WILL BE deasserted after the
second transfer. And all that needs CPU intervention. The DMA cannot
automatically reconfigure a peripheral between transfers.


>so that you can easily get 22 clock transfers. 
>  There are many ColdFire's (and older 683xx devices) with a queued SPI, 
>and the latest PPC-based MPC5xxx devices have even more powerful SPI 
>peripherals connected to flexible DMA.
>
>I don't know if that's what the guys at TI were thinking about, and I 
>doubt if it really helps you here, but there *are* microcontrollers 
>available that can handle all this in the background by DMA

There are tens of "MPC5xxx" devices. Could you specify one?

>(/if/ you can understand the documentation...).

Doesn't that sound a bit unpolite? Of course I can. Why shouldn't I?


Best,

On Tue, 08 Sep 2009 13:06:58 -0400, Mel <mwilson@the-wire.com> wrote:

>Bill wrote:
>
>> 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.
>
>From what I'm seeing here, when the PDC is in charge, the SPI doesn't work 
>in 8-bit transactions.  It works in a single transaction involving as many 
>8-bit bytes as the PDC demands.  I see /CS go low, and while it's low 24 
>clock pulses come out in a single burst, then /CS goes high and life goes 
>on.  (This is with the code I posted.  Thank the deity for digital storage 
>scopes.)

No, no. It doesn't work that way. The PDC moves N units of
information, each unit being whichever length (from 8 to 16 bits) the
SPI has been configured to work with. You must be seeing a single
transfer there (in your 24 clock cycles).

Show me where, in the datasheet, the PDC forces the SPI to work in
transfers of 8 bits, or in a multiple of 8 bits. I couldn't find it.

Best,

On Tue, 08 Sep 2009 13:06:58 -0400, Mel <mwilson@the-wire.com> wrote:

>> 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.
>
>From what I'm seeing here, when the PDC is in charge, the SPI doesn't work 
>in 8-bit transactions.  It works in a single transaction involving as many 
>8-bit bytes as the PDC demands.  I see /CS go low, and while it's low 24 
>clock pulses come out in a single burst, then /CS goes high and life goes 
>on.  (This is with the code I posted.  Thank the deity for digital storage 
>scopes.)

No, no. It doesn't work that way. The PDC moves N units of
information, each unit being whichever length (from 8 to 16 bits) the
SPI has been configured to work with. You must be seeing a single
transfer there (in your 24 clock cycles).

Show me where, in the datasheet, the PDC forces the SPI to work in
transfers of 8 bits, or in a multiple of 8 bits. I couldn't find it.

Best,