From: -jg on
On Dec 16, 12:41 pm, "Steve at fivetrees"
<st...(a)NOSPAMTAfivetrees.com> wrote:
> I'm trying to interface to a MAX11043 (4-channel synchronous ADC with SPI
> output). It has an end-of-conversion pin, which when active means that a
> bunch of data is available to read via SPI.
>
> Which is fine, except I want to run this baby at 200kHz (ish). Which means
> that using the EOC pin as an IRQ input is fairly nuts. (CPU is an AVR
> AT32UC3A.) The ADC data will be shipped out, raw, in Ethernet messages - not
> one sample at a time ;) - so needs to be aggregated into main memory for
> despatch (with some extra room for Ethernet delays, say 1s-worth). The CPU
> does have a SPI DMA subsystem, but needs to be primed in code...

So why is that a problem ?

>
> So - one way of solving this is to find (or design) a FIFO with SPI in, and
> SPI (or any other form of DMA-able CPU subsystem - again seems nuts to
> shuffle this one byte at a time) out. Short of a Lattice IP core, I'm
> finding nothing off-the-shelf. Could design some logic to use a parallel
> dual-port FIFO, but seems wrong: I'd have to convert from SPI to parallel on
> the way in, and the reverse on the way out.
>
> I've asked Maxim the obvious question: how do I interface to this thing?
> They've not been able to help.

Most SPI parts are designed sensibly - so they can stream data once
initialized.

If configure of DMA is too complex, then a few lines of code should
run a FIFO in SW, in the interrupt.

You could use a CPLD, but normally such a step is only needed if you
have a real brick-wall problem, like (eg) a SPI that only receives 16
bits and a SPI ADC that only sends 12 bits...

-jg


From: Steve at fivetrees on
"Paul Carpenter" <paul(a)pcserviceselectronics.co.uk> wrote in message
news:MPG.25924824fda56715989747(a)172.16.0.1...
> In article <OZGdnW0K7fNcg7XWnZ2dnUVZ8t6dnZ2d(a)pipex.net>,
> steve(a)NOSPAMTAfivetrees.com says...
>> I'm trying to interface to a MAX11043 (4-channel synchronous ADC with SPI
>> output). It has an end-of-conversion pin, which when active means that a
>> bunch of data is available to read via SPI.
>>
>> Which is fine, except I want to run this baby at 200kHz (ish). Which
>> means
>> that using the EOC pin as an IRQ input is fairly nuts. (CPU is an AVR
>> AT32UC3A.) The ADC data will be shipped out, raw, in Ethernet messages -
>> not
>> one sample at a time ;) - so needs to be aggregated into main memory for
>> despatch (with some extra room for Ethernet delays, say 1s-worth). The
>> CPU
>> does have a SPI DMA subsystem, but needs to be primed in code...
>
> So why not do the code for SPI with DMA?
>
> If you are sending data in Ethernet packets, you will be buffering the
> data to build up your packet size, so what is the problem with filling
> buffers using DMA?

Maybe I wasn't clear enough - the problem is that, while the CPU can do SPI
under DMA control, the DMA sequence is initiated in software. I can see no
way at all of starting an SPI DMA sequence in hardware, which was my
original expectation. Therefore we either have to trigger an IRQ on EOC, and
start the DMA sequence in the ISR, or design an SPI FIFO which would
generate IRQs less frequently and cause larger chunks of SPI data to be
transferred (or indeed DMA the data in some other way). I'm hoping I'm
missing something simpler.

>> I've asked Maxim the obvious question: how do I interface to this thing?
>> They've not been able to help.
>
> It may be they did not understand your question.

Heh. I actually just asked for any other data on the MAX11043, such as
application notes... I was told there is no other data.

Steve
--
http://www.fivetrees.com


From: Paul Carpenter on
In article <-eGdnbKi0oh5ObXWnZ2dnUVZ8hOdnZ2d(a)pipex.net>,
steve(a)NOSPAMTAfivetrees.com says...
> "Paul Carpenter" <paul(a)pcserviceselectronics.co.uk> wrote in message
> news:MPG.25924824fda56715989747(a)172.16.0.1...
> > In article <OZGdnW0K7fNcg7XWnZ2dnUVZ8t6dnZ2d(a)pipex.net>,
> > steve(a)NOSPAMTAfivetrees.com says...
> >> I'm trying to interface to a MAX11043 (4-channel synchronous ADC with SPI
> >> output). It has an end-of-conversion pin, which when active means that a
> >> bunch of data is available to read via SPI.
> >>
> >> Which is fine, except I want to run this baby at 200kHz (ish). Which
> >> means
> >> that using the EOC pin as an IRQ input is fairly nuts. (CPU is an AVR
> >> AT32UC3A.) The ADC data will be shipped out, raw, in Ethernet messages -
> >> not
> >> one sample at a time ;) - so needs to be aggregated into main memory for
> >> despatch (with some extra room for Ethernet delays, say 1s-worth). The
> >> CPU
> >> does have a SPI DMA subsystem, but needs to be primed in code...
> >
> > So why not do the code for SPI with DMA?
> >
> > If you are sending data in Ethernet packets, you will be buffering the
> > data to build up your packet size, so what is the problem with filling
> > buffers using DMA?
>
> Maybe I wasn't clear enough - the problem is that, while the CPU can do SPI
> under DMA control, the DMA sequence is initiated in software. I can see no
> way at all of starting an SPI DMA sequence in hardware, which was my
> original expectation. Therefore we either have to trigger an IRQ on EOC, and
> start the DMA sequence in the ISR, or design an SPI FIFO which would
> generate IRQs less frequently and cause larger chunks of SPI data to be
> transferred (or indeed DMA the data in some other way). I'm hoping I'm
> missing something simpler.

However considering what has to be done (from my limited reading of
AT32UC3A datasheet) -

Initialise all peripherals (preload all registers)

Start conversion set CONVRUN

EOC interupt Start DMA of 4 x 16 bit transfers.
(hit the go bit for the channel)

End of DMA INTERUPT reset pointers and counters
Flag when buffer full for rest of app
Probably use double buffering to allow next block
to be started if still here.

The real problem is not the EOC, but that the DMA controller does not
seem to be able to be set for SPI RECEIVE to do repeated blocks of
data (due to no obvious hardware trigger/pause), until a transfer count
number of blocks are done.

This then means there is more in the End of DMA transfer interupt in
processing buffer handling and reseting DMA registers, so I can see
some of the issues.

You actually end up with 400kHz of interupts, before anything else
in your system.

I also could not see any obvious way to do parallel DMA from external
device/FIFO, which may have simplified things.

> >> I've asked Maxim the obvious question: how do I interface to this thing?
> >> They've not been able to help.
> >
> > It may be they did not understand your question.
>
> Heh. I actually just asked for any other data on the MAX11043, such as
> application notes... I was told there is no other data.

I actually think the problem is more the AVR32 and how it does SPI
under DMA due to hardware trigger issues.

On other micros I would either externally do SPI receive and use
DMA with burst mode transfers, or a FIFO for DMA at half full.
Alternatively dual ported RAM, which the SPI receive hardware
directly does its own 'dma' into, with dual buffering and interupt
on buffer full or error.

--
Paul Carpenter | paul(a)pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/> PC Services
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.gnuh8.org.uk/> GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
<http://www.badweb.org.uk/> For those web sites you hate
From: Didi on
On Dec 16, 1:41 am, "Steve at fivetrees" <st...(a)NOSPAMTAfivetrees.com>
wrote:
> I'm trying to interface to a MAX11043 (4-channel synchronous ADC with SPI
> output). It has an end-of-conversion pin, which when active means that a
> bunch of data is available to read via SPI.
>
> Which is fine, except I want to run this baby at 200kHz (ish). Which means
> that using the EOC pin as an IRQ input is fairly nuts. (CPU is an AVR
> AT32UC3A.) The ADC data will be shipped out, raw, in Ethernet messages - not
> one sample at a time ;) - so needs to be aggregated into main memory for
> despatch (with some extra room for Ethernet delays, say 1s-worth). The CPU
> does have a SPI DMA subsystem, but needs to be primed in code...
>
> So - one way of solving this is to find (or design) a FIFO with SPI in, and
> SPI (or any other form of DMA-able CPU subsystem - again seems nuts to
> shuffle this one byte at a time) out. Short of a Lattice IP core, I'm
> finding nothing off-the-shelf. Could design some logic to use a parallel
> dual-port FIFO, but seems wrong: I'd have to convert from SPI to parallel on
> the way in, and the reverse on the way out.
>
> I've asked Maxim the obvious question: how do I interface to this thing?
> They've not been able to help.
>
> Any ideas, folks?
>
> Steve
> --http://www.fivetrees.com

Perhaps not much help, but using a processor with FIFOs on the serial
ports would have done the job. I did something like that a few years
ago,
apr. 1 MSPS ADC in and 1 MSPS DAC out, 12 bits each. Was an easy ride
on
the MPC5200, though - which is probably a lot larger than your Atmel
part (but not that terribly expensive, $18 or so @ 1000).
Beautiful serial ports which can do an unimaginable number of modes,
codec, spi, AC97, UART... with 512 bytes of FIFO (both Tx and Rx).
Did not even use interrupts on that one (did so for the fun of it),
lots of such + DMA-ing on other products with the same part though.
Collecting data at your rates and sending it over tcp/ip via 100 MbpS
Ethernet would be take a small fraction of the power of the 5200,
though.

Here is the board: http://tgi-sci.com/y2demo/


Dimiter

------------------------------------------------------

Dimiter Popoff Transgalactic Instruments



http://www.tgi-sci.com

------------------------------------------------------

http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/

From: Vladimir Vassilevsky on


Steve at fivetrees wrote:

> Heh. I actually just asked for any other data on the MAX11043, such as
> application notes... I was told there is no other data.

MAXIM has well deceived bad reputation for parts availability; are you
planning to check it on your own?

For 4-channel sampling at ~200kHz for streaming over the Ethernet, the
low cost solution would be 192kHz audio ADC.

Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com