MAX11043 - trying to avoid interrupts at 200kHz...

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
Reply to
Steve at fivetrees
Loading thread data ...

A hardware FIFO was the first thing that crossed my mind. But I think you've excluded it. (You might use a dedicated mcu for the FIFO with custom, slightly wider than 1-bit serial shifting if you wanted?)

I'm using a SiLabs C8051F061, right now, running its 16 bit SAR ADC at more than 500kHz and having no problems with it. But it includes a DMA unit inside, so things just lope along fine. Data is taken in bursts lasting a few milliseconds so it's easy on the micro interrupt system.

In another system, I used an ADSP-21xx to operate a 16-bit ADC at

600ns per sample, driving the control lines entirely in software and storing data on the fly. But it has 25ns cycle time and can pack a memory read, memory write, and alu operation in a single cycle.

No outbound ethernet for streaming the data out in either case, though.

Have you considered the thought that someone matched up the wrong parts for the application?

Jon

Reply to
Jon Kirwan

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?

Yes I can see it is a complicated device to setup, but I do not see what the issue with getting code to run on simple proving of getting four simulutaneous samples using SPI DMA. Using a GPIO to drive CONVRUN and EOC to trigger DMA subsystem.

Is there an issue getting the clock and data phasing right to match the devices for SPI?

Sounds like a sledgehammer to crack a nut, if you were going to externally FIFO with some sort of PLD/FPGA, then I would consider DMAing the parallel data.

It may be they did not understand your question.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
 Timing Diagram Font
  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
 For those web sites you hate
Reply to
Paul Carpenter

Why 200kHz interrupt would be nuts? Handling one high priority interrupt at 200kHz shouldn't be a problem for AVR32.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

formatting link

Reply to
Vladimir Vassilevsky

I've never used an AT32UC3A but is there any way to use an external I/O pin to pause the DMA? If not, then how about running the SPI in slave mode with the clock coming from an external source that is triggered by the EOC pin? This would effectively match the DMA speed with the conversion rate of your ADC.

I just did a quick look at the datasheet to see if I couldn't figure this out myself but I'm lost... the description of the PSR in the DMA controller in section 21.5.4 (page 159 of 826) says "See the part specific documentation for details". Huh?

Reply to
Tom

s

not

U

So why is that a problem ?

nd

on

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

Reply to
-jg

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.

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
Reply to
Steve at fivetrees

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 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@pcserviceselectronics.co.uk
    PC Services
 Timing Diagram Font
  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
 For those web sites you hate
Reply to
Paul Carpenter

s

not

U

nd

on

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:

formatting link

Dimiter

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

Dimiter Popoff Transgalactic Instruments

formatting link

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

formatting link

Reply to
Didi

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

formatting link

Reply to
Vladimir Vassilevsky

Heh again. Distributors here in the UK (e.g. Farnell) have (and have had) reasonable stock, otherwise I wouldn't touch it with a bargepole.

It happens that this device suits us exceedingly well, and boy, have we researched this...

Excellent point, except for the fact that one reason we got into this project was to get away from a certain TI family of 192kHz audio ADCs, which have a noise-shaping issue (so I'm told) which my boss is keen to leave behind... And said boss has told us to lose the self-same 192kHz audio ADCs, which we'd included as another option, from our prototype. (Said prototype also exists to prove a bunch of other technologies, all equally fraught, and is really intended to allow us to validate them all.)

There are times when I wish I were a monk. Today has been one of those days.

Steve

--
http://www.fivetrees.com
Reply to
Steve at fivetrees

I understand that there is no way to hardware-trigger the DMA in SPI master mode but what if you configure the SPI for slave mode and then start the DMA? Will the DMA wait until some external source (like a counter) starts generating CLK pulses and shifting the data from the ADC to the CPU? If it will, then all you need to add is a counter that is triggered by EOC and generates 64 CLK pulses before waiting for another EOC.

Reply to
Tom

would a 200KHz interrupt really be that bad?, write it in assembler if needed, can't be that many instructions if all it needs to do is copy a few bytes and return. I'd rather use 5-10% of the cpu on an interrupt than try to try and kludge together fifos and a bunch of logic and hope it works.

-Lasse

Reply to
langwadt

You, sir, are a blinking hero. That idea not only has legs, it works out even better than that. The EOC signal goes false when all bits are shifted out, so there's no need for a counter. Basically, this method adds the capability to be an SPI master to the MAX11043, which was the simplifying insight we were lacking (and which we've spent the afternoon kicking ourselves about). It's really quite beautiful.

There's one little remaining bit of kludginess - while the MAX11043 has data in, data out (and clock in), the AVR has MOSI and MISO (and clock in/out). MISO and MOSI reverse directions when changing from master to slave, but that's ok, I can deal with that in hardware (driven by a pair of GPIO pins). We do need to talk to the MAX11043 too, to configure it...

We still need to prove that a 16-bit DMA transfer is complete before the next 16 bits are shifted in (the max the AVR can handle in one chunk), but we're working on that.

Thanks, Tom, I owe you a pint.

Steve

--
http://www.fivetrees.com
Reply to
Steve at fivetrees

One of my colleagues has already tested this idea, by injecting a 200kHz signal into an IRQ pin. He tells me there's time for the ISR to be called and to return, and almost nothing else. Certainly not time enough to do anything useful.

I've not double-checked his work ;).

Steve

--
http://www.fivetrees.com
Reply to
Steve at fivetrees

At what speed are you running it? maxed out by a simple 200KHz interrupt doesn't sound right

-Lasse

Reply to
langwadt

200KHz is 5uSec per interrupt.

An ISR that takes 5uSECONDS !!!

Yes, this does not sound right.

What processor and speed are you (OP) using ??

A Z80 at 4MHZ interrupt is less than 5uSec.

don

Reply to
don

Reply to
Steve at fivetrees

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.