16-bit SPI trying to read from 22-clock cycle ADC
in [Design]
|
From: Bill on 8 Sep 2009 22:13 On Tue, 8 Sep 2009 14:33:44 -0700 (PDT), karthikbalaguru <karthikbalaguru79(a)gmail.com> wrote: >It appears strange. From my experience, normally TI would definitely >have some reasons for any such strange things. To be more correct, for me, it is not TI's fault. It is the fault of the designers of the SPI inside everyday MCUs. Knowing that there are 16/18/20/22/24-bit ADCs/DACs around, and that they need extra clock cycles for the sampling phase, what are they waiting to implement SPIs that can handle say 32 bits in a single transfer? I don't understand it. It would be a few microdollars more of silicon. >In this scenario, bit banging appears reasonable. Well, that might >increase the CPU load. Yes, I'm bit banging. The ADC could work up to 100 ksa/s. Thank god I'm not going that high, because in that case the CPU could do nothing else. >The best help would be from the TI support. Yes, I'm curious to ask them. Best,
From: Bill on 8 Sep 2009 22:22 On Wed, 09 Sep 2009 03:47:42 +0200, Bill <a(a)a.a> wrote: >You must be seeing a single transfer there (in your 24 clock cycles). Disregard this sentence. It makes no sense. I was thinking about my ADC. I don't know why you are seeing that. Maybe you have CSAAT set, and you are switching between different devices?
From: Martin Riddle on 8 Sep 2009 23:16 "Bill" <a(a)a.a> wrote in message news:ji2ea5pbcg12us9vbfo0op6cocfkugk7f2(a)4ax.com... > 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. What about CSAAT ? Setting it allows the CS to stay low until another CS is selected. Cheers
From: krw on 9 Sep 2009 00:10 On Tue, 08 Sep 2009 15:53:43 +0200, 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 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. Seems like a pretty poor implementation of the SPI master. I've generally rolled my own, but at least the later TI DSPs allow SPI word lengths of 1 to 32 bits. >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. Bit bang the sample clock then use SPI to transfer data? Use an FPGA to do your I/O? >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? You have a sows ear and you want a silk purse? ;-)
From: David Brown on 9 Sep 2009 02:50
Bill wrote: > 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. > I'm not familiar with the AT91SAM devices (I'm not very familiar with ARMs in general - it's nearly twenty years sine I used one), so this may or may not give you some ideas... First, is the CSAAT bit in a register adjacent to the SPI transfer register(s) ? If so, it's possible that your DMA could be set up to transfer a new value to that control register at the same time as sending another 16-bit word to the SPI transmit register. (On the Freescale devices, the equivalent to CSAAT is in a command byte that is collected from the queue along with the data to send.) Secondly, if you have several DMA channels and they are flexible enough, it might be possible to configure a chain of DMA events. For example, the SPI transfer complete could trigger a DMA transfer. Instead of writing the next SPI transmit value, this could "manually" trigger two new DMA channels. The first of these is set up to set the CSAAT bit, and the second to write the next SPI transfer. > 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? > There are indeed a fair number of them, and (AFAIK) they all have powerful SPI peripherals and lots of flexible DMA channels. So without anything else to go on (performance, flash, external bus, timers, etc.), it would be a random guess as to which would be suitable for you (though MPC55xx or MPC56xx narrows it down a little). I've used an MPC5554, if that helps at all. If you are considering changing architecture, then you should also look at the ColdFires (specially the v2 cores) - they are easier to work with. >> (/if/ you can understand the documentation...). > > Doesn't that sound a bit unpolite? Of course I can. Why shouldn't I? > Sorry, I didn't mean it to sound impolite to /you/. It's just that the documentation for these devices is complicated and often unclear. The "SPI" peripherals on the MPC55xx support serial multiplexing of internal timer channels as well as SPI (which supports multiple queues amongst other features), and it's no small job figuring out what is really needed to get the SPI running as desired. Similarly with DMA. There is also a lack of appnotes for this sort of setup, so you have to be prepared for a fair amount of work figuring things out. Once you understand it all, however, you can do all sorts of wonderful things with the MPC's peripherals. |