Connect with us

DSP and memory

Discussion in 'Electronic Design' started by Jon Slaughter, Aug 5, 2007.

Scroll to continue with content
  1. 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?

  2. Eeyore

    Eeyore Guest

    I can answer that for you but it seems you aren't interested.

    Have you learnt what an op-amp is and how it works yet ?

  3. 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.

  4. Nope.. I'm still learning the fundamental basics part 0.001... you know.
    about resistors, capacitors, conductors, etc... Once I move on to 0.1 I
    think I can understand the huge differences between op amps and differential
    amps. Maybe If I'm lucky I'll be able to have 1/1000% of the knowledge you
    have in your big toe before I pass on.
  5. 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.

  6. Eeyore

    Eeyore Guest

    Start at Chapter 1 if you are a novice, and read through until completion of
    Chapter 9. After
    Chapter 9 is completed, the reader can jump to any chapter and be confident that
    are prepared for the material. More experienced people such as electronic
    digital engineers, and non-electronic engineers can start at Chapter 3 and read
    Chapter 9.

    It's on page 3.

  7. You only need external memory if you don't have enough internal
    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
    Correct, it is not needed.
    If the DSP has enough internal memory, then yes.

  8. Bob

    Bob Guest

    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.

  9. Eeyore

    Eeyore Guest

    It's worth pointing out that most *audio* ADCs are entirely dumb and once you've
    provided their clocks they will simply output data continuously, usually in a
    serial format such as I2S.

  10. Nico Coesel

    Nico Coesel Guest

    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.

  11. 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.
  12. Thanks, I think I got it under control now. (As far as conceptually what I
    want to do... now I just gotta figure out all the hardware ;/)

  13. 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.

  14. Didi

    Didi Guest

    I don't know. The evm just said "To buffer the data" or something. I'm not
    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 -
    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...

    Good luck,

  15. 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

    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)

  16. Didi

    Didi Guest

    I will have to buffer that data though regardless of how I use it and I
    This is correct, you can only work on past data. Cicular buffering is
    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
    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
    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/

    That being said, in your case, at a 5 uS sampling and 100 MMAC/S you
    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
    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
    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

Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day