16-bit SPI trying to read from 22-clock cycle ADC
in [Embedded]
|
From: Martin Riddle on 8 Sep 2009 18:00 "Bill" <a(a)a.a> wrote in message news:rq0da55nb0kfd0mns4kf5cijnsuv9v9knc(a)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
From: Bobby Joe on 8 Sep 2009 20:56 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 8 Sep 2009 21:30 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 8 Sep 2009 21:43 On Tue, 08 Sep 2009 13:06:58 -0400, Mel <mwilson(a)the-wire.com> wrote: >Bill wrote: > >> On Tue, 08 Sep 2009 11:23:38 -0400, Mel <mwilson(a)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,
From: Bill on 8 Sep 2009 21:45
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, |