16-bit SPI trying to read from 22-clock cycle ADC
in [Embedded]
|
From: Bill on 10 Sep 2009 08:22 >In those instances, I always revert to assembly language for the interrupt >part. Handle things as quickly as you can, and a context switch suddenly >isn't half that bad. No more than pushing and popping a few registers. Hell, >I even did a Fast interrupt handler in C on a Motorola DSP56K. The interrupt >occured every 200 ns.... (no typo). Just... be smart... What was the clock frequency of your DSP56K?
From: Meindert Sprang on 11 Sep 2009 02:33 "Bill" <a(a)a.a> wrote in message news:dprha5p433n19mof4o2k1nqi281bf3kenr(a)4ax.com... > >In those instances, I always revert to assembly language for the interrupt > >part. Handle things as quickly as you can, and a context switch suddenly > >isn't half that bad. No more than pushing and popping a few registers. Hell, > >I even did a Fast interrupt handler in C on a Motorola DSP56K. The interrupt > >occured every 200 ns.... (no typo). Just... be smart... > > What was the clock frequency of your DSP56K? 80MHz Meindert
From: Ulf Samuelsson on 12 Sep 2009 19:05 Bill skrev: > Well, I was wrong in at least one thing: I thought that, with CSAAT=0, > CS would be deasserted (high) between consecutive "word transfers" > within one "block transfer", but it is not. I had clear from the > beginning (from diagrams and text) that there was a way to keep CS=0 > between word transfers, but I thought that it implied CSAAT=1, and it > is not true. CS is 0 between consecutive word transfers (of the same > block transfer) regardless of the value of CSAAT. > > So, yes, I can leave CSAAT=0 permanently, there is no CPU intervention > needed (other than at the beginning and at the end of each block > transfer), and I can use DMA, with two 11-bit word transfers per block > transfer. > > > This is good, but I think that it could be better. Difficult to > explain, but I'll try: > > Imagine my external ADC (with SPI interface) is sampling the analog > input at 100 ksa/s (the TI ADS8320 that I mentioned allows that). So, > 10 us between samples. Not much. Each sample needs 22-clock cycles > inside each assertion of CS=0, so each sample needs one DMA block > transfer (with for instance two 11-bit word transfers inside). Each > DMA block transfer needs CPU intervention. So, I need CPU intervention > every 10 us. That's a short time. Only 480 cycles of my 48 MHz SAM7. > Since (that I know) a DMA block transfer cannot be triggered directly > by a timer overflow or underflow, an interrupt service routine > (triggered by a 10 us timer underflow) must be executed every so > often, so that the CPU can manually trigger the DMA block transfer and > collect the data. Adding up the overhead of the interrupt context > switching and the instructons needed to move data from and to the > block buffers, to re-trigger the block transfer, and all this in C++, > I think that all that may consume a "significant" portion of those 480 > cycles. And the CPU is supposed to do something with that data, and > some other things. I see that hog as a killer, or at least as a pitty. > > If the SPI in the MCU allowed 22-bit (word) transfers, and the DMA > allowed triggering the next word transfer (inside a block transfer) > when a certain timer underflows, then the DMA blocks wouldn't need to > be so small. Each analog sample could travel in one single SPI word > transfer, and one DMA block could be planned to carry for instance > 1000 word transfers. That would be one DMA block every 10 ms. The > buffer (FIFO) memory would be larger, but the CPU intervention needed > would be much lower. There would be the same number of useful cycles, > but much fewer wasted cycles. There wouldn't need to exist an > interrupt service routine executed every 10 us, which is a killer. > That would be a good SPI and a good DMA, in my opinion, and the extra > cost in silicon is negligible, compared to the added benefit. Why > don't most MCUs allow that? Even cheap MCUs could include that. An MCU > with the price of a SAM7 should include that, in my opinion. > > Best, An idea: Run a timer which is connected to the SSC input clock and ADC clock. It also clocks another timer in PWM mode generating the ADC chip select. The ADC will see 22 active and 10 passive bits and the SSC will see 32 bits. (Did not test this) Best Regards Ulf Samuelsson
From: Ulf Samuelsson on 12 Sep 2009 19:05 Bill skrev: > Well, I was wrong in at least one thing: I thought that, with CSAAT=0, > CS would be deasserted (high) between consecutive "word transfers" > within one "block transfer", but it is not. I had clear from the > beginning (from diagrams and text) that there was a way to keep CS=0 > between word transfers, but I thought that it implied CSAAT=1, and it > is not true. CS is 0 between consecutive word transfers (of the same > block transfer) regardless of the value of CSAAT. > > So, yes, I can leave CSAAT=0 permanently, there is no CPU intervention > needed (other than at the beginning and at the end of each block > transfer), and I can use DMA, with two 11-bit word transfers per block > transfer. > > > This is good, but I think that it could be better. Difficult to > explain, but I'll try: > > Imagine my external ADC (with SPI interface) is sampling the analog > input at 100 ksa/s (the TI ADS8320 that I mentioned allows that). So, > 10 us between samples. Not much. Each sample needs 22-clock cycles > inside each assertion of CS=0, so each sample needs one DMA block > transfer (with for instance two 11-bit word transfers inside). Each > DMA block transfer needs CPU intervention. So, I need CPU intervention > every 10 us. That's a short time. Only 480 cycles of my 48 MHz SAM7. > Since (that I know) a DMA block transfer cannot be triggered directly > by a timer overflow or underflow, an interrupt service routine > (triggered by a 10 us timer underflow) must be executed every so > often, so that the CPU can manually trigger the DMA block transfer and > collect the data. Adding up the overhead of the interrupt context > switching and the instructons needed to move data from and to the > block buffers, to re-trigger the block transfer, and all this in C++, > I think that all that may consume a "significant" portion of those 480 > cycles. And the CPU is supposed to do something with that data, and > some other things. I see that hog as a killer, or at least as a pitty. > > If the SPI in the MCU allowed 22-bit (word) transfers, and the DMA > allowed triggering the next word transfer (inside a block transfer) > when a certain timer underflows, then the DMA blocks wouldn't need to > be so small. Each analog sample could travel in one single SPI word > transfer, and one DMA block could be planned to carry for instance > 1000 word transfers. That would be one DMA block every 10 ms. The > buffer (FIFO) memory would be larger, but the CPU intervention needed > would be much lower. There would be the same number of useful cycles, > but much fewer wasted cycles. There wouldn't need to exist an > interrupt service routine executed every 10 us, which is a killer. > That would be a good SPI and a good DMA, in my opinion, and the extra > cost in silicon is negligible, compared to the added benefit. Why > don't most MCUs allow that? Even cheap MCUs could include that. An MCU > with the price of a SAM7 should include that, in my opinion. > > Best, An idea: Run a timer which is connected to the SSC input clock and ADC clock. It also clocks another timer in PWM mode generating the ADC chip select. The ADC will see 22 active and 10 passive bits and the SSC will see 32 bits. (Did not test this) Best Regards Ulf Samuelsson
From: Bill on 13 Sep 2009 08:33
On Sun, 13 Sep 2009 01:05:07 +0200, Ulf Samuelsson <ulf(a)atmel.com> wrote: >An idea: > >Run a timer which is connected to the SSC input clock and ADC clock. >It also clocks another timer in PWM mode generating >the ADC chip select. > >The ADC will see 22 active and 10 passive bits >and the SSC will see 32 bits. > >(Did not test this) Hey, that's a wonderful idea!! It opens up a broad array of new possibilities :-) Thanks! |