From: Bobby Joe on
On Sep 8, 8:53 am, Bill <a...(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/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.

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.

From: Bill on
On Tue, 08 Sep 2009 22:53:39 +0200, David Brown
<david.brown(a)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,
From: Bill on
On Tue, 08 Sep 2009 13:06:58 -0400, Mel <mwilson(a)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,
From: Bill on
On Tue, 8 Sep 2009 09:38:27 -0700 (PDT), "langwadt(a)fonz.dk"
<langwadt(a)fonz.dk> wrote:

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

This is interesting. I'm taking a look at the SSC. Never used it
before. Looks like it might be possible, but I'll wait to finish
reading.

Thanks!
From: Bill on
On Tue, 8 Sep 2009 18:00:40 -0400, "Martin Riddle"
<martin_rid(a)verizon.net> wrote:

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

That has already been proposed by others, and won't work either,
without CPU intervention. Please read my other posts.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8
Prev: Fourier Transform Tutorial
Next: Issues with LED grid driving