How does one normally handle interfacing an ADC with a DSP when the sample rate is fairly slow(audio)?
Do I have to buffer or use external memory or can I just poll or use some interrupt driven mechanism?
If I have an ADC setup for audio sample rates can't I just have the dsp periodically request the data from the ADC? without any type of buffering? Or when the ADC is ready to transmit just use interrupts(which I guess would be the master clock on the ADC)?
I've read a little and they talk about buffering the data after the ADC but I'm not sure if this is necessary? Specially since my application is real time if I end up having to buffer more than one sample or two then I'll probably end up with problems.
My idea was to feed the data from the adc to the dsp and store the samples in dsp memory instead of externally. Is this possible?
The digital signals are what passes between the ADC and a DSP. They are very easy to interface. I've done both parallel load and serial, without any problems. You might have to consider level shifting, depending on the ADC digital I/O levels and the DSP's I/O levels. But other than that, it's hard to imagine much problem here.
Buffer the digital data?? Like in a FIFO? No. Just read it in. You can write code to do that on the DSP.
Yes. In some cases I've done, I control the ADC's analog sampling window and the conversion start and end, in fact running all of the digital lines from the DSP without external support on that side. No problems I'm aware of.
You might choose to use interrupts. You could poll, as well.
I'm still not sure what you mean by buffering here, except that in very high speed cases where the DSP cannot keep up with the data flow a FIFO may be required and driven externally by faster logic. I use a rather slow DSP, control all the lines directly, and I can operate the
16 bit ADC at its maximum rate of 1.4MHz without any external support required ... plus do all the necessary calculations, and so on.
Yes. I think a number of demo boards already come with all the software needed for audio stuff, too.
yes, this is what I was thinking. But for an ADC EVM module they were talking about a buffer after the data and I couldn't understand why.
I don't know. The evm just said "To buffer the data" or something. I'm not sure if it meant a memory buffer or some type of driver or what.
This might be the reason. The EVM was for a very fast ADC like 200MSPS or something so I suppose that could have been the reason. Also it was probably interfacing with the computer since it was an EVM.
You only need external memory if you don't have enough internal memory. Yes, you can simply use interrupts or a polling mechanism, your choice depending on how your application wants to work.
Yes you can, and that's how it would normally be done. You only need buffering if your DSP can't manage to process the data in real time.
If you need say 100KHz sampling rate then you could simply have a hardware timer generate an interrupts every 10us, then your interrupt routine sends a request to the ADC for a sample.
Depends on what ADC you choose and how you want to do it. If you do as above then your processor needs to sit around waiting for the sample to complete, and that may or may not be adequate for your application. So in that case you may choose to clock the ADC at a specific rate and have the ADC generate an interrupt when the sample is ready to be read.
Jitter and accuracy of sampling rate. If timing is set by a seperate ADC clock that's fine. If you set the sampling interval by the execution time of a loop in your software that takes a different time depecing on how it branches or by somthing that can vary like ADC conversion time how are you going to make a digital filter with a stable accurate frequency response?
As allways what you can get away with depends on your application.
You usually get an interrupt when data arrives from the ADC. The easiest way to process the data is to do all the processing inside the interrupt routine. You'll have to do the processing anyway (within one sample period) so transferring the data to the main process just takes extra CPU cycles.
--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl
Thats true. For my purposes I think that will work fine. Although I don't think I'm even close to the software side of it as I'm trying to figure out all the hardware so I can put something together eventually.
well, I figured that since the dsp is running about 100x faster that that I wouldn't have that big of an issue polling... mainly since my application is simply computing FIR's easily within the timeframe of a sample period.
I think I'm going to go the interrupt way as it just seems easier and more natural to me... wasn't sure if this was the way to do it though.
They most definitely mean FIFO buffering, typically done inside the DSP memory. IOW, you do not need to FIFO-buffer the data entering the DSP, and - judging by the DSPs I have used TI54xx - you will find lots of very sophisticated/clever mechanisms to implement circular buffers (FIFOs) both by DMA and the processor. Chances are you will not have to worry about an IRQ per sample - although at audio frequencies this is easily doable - you will be able to setup your ADC stream in a circular buffer in memory. Real time is another matter, and while IRQ per sample might do the job for simpler tasks, it will bring in little value. It is enough to have an IRQ once per doing full buffer circle, then you'll know the time of every sample; and since this will reduce the overall overhead, the latency will be lower...
I'm not sure I follow what your getting at. For my application I'm processing 192khz(or maybe just 96khz) with a DSP that has about 100MMACS or even more. Since, at least at this point, all I'll be doing is simple convolutions I should have plenty of time to process a sample point? I will also eventually need to take the FFT but I feel that if I end up running out of time I can just upgrade the processor.
i.e., it should be about 10^8/2/10^5 which gives me about 500MACS per sample.
Now this is regardless of how I get the samples except for the cost of doing that which shouldn't be more than a few cycles I suppose.
In any case I can't see how the method could be improved that much for what I'm doing because saving a few cycles isn't that critical at such a low sampling rate.
I will have to buffer that data though regardless of how I use it and I think it will be a circular buffer. I'll need a "short term history" of the sampled data along with a "short term history" of previous compuations(or IIR's and FIR's).
Can you elaborate on the method you are refering to that is better than using IRQ per sample? I think your are saying that I should just feed the ADC into a circular buffer and just continuously process the buffer? (if that is the case then I'm not sure if its better because because its a real time process and I have to do all the processing on a sample within the time period... if I do it faster then I have to wait and if I do it slower then its not real time. (So the only issue is doing it fast enough and I think, for now at least, I don't have to worry about that)
This is correct, you can only work on past data. Cicular buffering is the method of choice in DSP - to an extent they can have specfically designed opcodes and registers to make that cost "no time".
Yes, this is how I would do it. There can be exceptions, but typically this would be the way to go.
Obviously your code has to be faster than the data rate, yes. Todays DSPs are deeply pipelined, and they do reach their MMAC/cycle rate only in a loop (so filling the pipeline - which can easily take
5 or 10 cycles - is negligible). (A rough example, if you manage a loop working on 10 rather than on 1 sample you may do 10 times better on that). Then there is the IRQ context save/restore + pipeline flush/ refill.
That being said, in your case, at a 5 uS sampling and 100 MMAC/S you will have about 500 cycles/sample, which may well be enough for a simple enough task - or perhaps a bit more. But you can easily spend 50 or even 100 cycles on IRQ processing/pipeline refill alone in that scenario, which is 10-20% of your horsepower budget, and your code will not look any simpler because of using IRQ per sample. However, if you clearly see how to make it using an IRQ each sample there is nothing wrong doing it so. And since apparently you are learning perhaps the best path is to do it first so, then push the system until it runs out of horsepowers and buy some yourself back doing it the other way (the code difference will not be that huge, you will still do the same algorithm, just the synchronisation will need to change).
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.