Re: General Q: Interrupt vs. Polling



On Oct 12, 5:52 pm, Tim Wescott <t...@xxxxxxxxxxxxxxxx> wrote:
Borrall Wonnell wrote:
Hi all,

I haven't been able to find much literature regarding this topic, so I
figured I'd post a question.
An external device writes data to two buffers (A and B) in my DSP.  The
basic idea is:

Write a block of data to Buffer A
Interrupt DSP (indicate Buffer A is full)
Write block of data to Buffer B
Interrupt DSP (indicate Buffer B is full)
Repeat

The DSP processes data in buffer A while data is being written to
buffer B (and vice versa).  I have assumed that the DSP can process the
data before the next interrupt occurs.

As I see it, I can approach this in a couple of ways:
1) DSP processes all data within the ISR
2) Set a flag in the ISR and poll for the flag in a main (always
running) routine.

I don't like option #2 because it seems inefficient (spinning in a loop
until the flag is set).  Then again, doing all the work within the ISR
appears to be against standard practices; most recommendations are to
keep the ISR short.

Are there any other options that I've failed to consider?  This seems
like it would be a common problem for DSP designers.This is a typical problem in real-time programming, and there are a lot
of good answers to it.  I'm taking the liberty of cross-posting this to
comp.arch.embedded, in hopes that you'll get a recommendation for a book
that has most of them.

Here are the common ones, in increasing order of complexity:

1.  If _all_ you are going to do is process just that data then you
could put it in the ISR.  But then things will break when you implement
the next interrupt-driven thing.

You can make your ISR's nestable, but this can cause problems.  The
first problem is that your hardware may not agree with you about what
interrupts have greater priority.  The second problem is that
_everything_ becomes an ISR, which requires significantly more care in
coding.  A corollary to the second problem is that most embedded
software engineers shy away from nested ISRs, sometimes violently.

2.  Setting flags in various ISR's and processing them in the main loop,
as mentioned elsewhere, works well.  Unfortunately it constrains _all_
of the processing to be as short as the shortest allowable response
time.  This can be a pain if someone comes along later and puts a big
floating-point calculation in that low-priority task, thereby blowing
the important stuff out of the water -- so it'll work, but it's best to
only use it on small applications and with a tight, disciplined team.

3.  You could use a preemptive RTOS, set a semaphore in the ISR and pend
on it in your main loop.  This is way overkill if you're only doing one
interrupt-driven thing, but a real life saver if you're doing a number
of things that are interrupt-driven, or periodic, or whatever.  The
nicest thing about an RTOS is that it does a great job of decoupling the
important stuff from the less important stuff -- to the extent that in a
team environment you can hand the less important stuff to lesser
engineers, with all associated implied advantages.

RTOS's don't have to cost much -- the July or August issue of Embedded
Systems Design magazine had an article on a particularly light-weight
preemptive RTOS.  Micro-C/OS-II (AKA mucus) is quite cost-effective,
also -- and if you're using a recent TI processor the tool chain will
come with an RTOS.

--

Tim Wescott
Wescott Design Serviceshttp://www.wescottdesign.com

Posting from Google?  Seehttp://cfaj.freeshell.org/google/

"Applied Control Theory for Embedded Systems" came out in April.
See details athttp://www.wescottdesign.com/actfes/actfes.html- Hide quoted text -- Show quoted text -

Hard to generalise, it depends so much on the proccessor and the
application. Nesting ISRs works fine if your proccessor has seperate
vectors and allows priorites and/or level masking. Polling interrupt
flags from an idle loop works well for proccessors with a shared
interrupt vector providing latency isnt a problem.

.

Relevant Pages

  • Re: How to manipulate a receiving buffer
    ... You'll need to disable your receive interrupt during ... flush_receiving_buffalways clear the buffer to empty (for ... dont want to put packet recognizing logical into the ISR. ... After the upper level code has read all of the chars from the buffer, ...
    (comp.arch.embedded)
  • Re: General Q: Interrupt vs. Polling
    ... An external device writes data to two buffers in my DSP. ... Interrupt DSP (indicate Buffer A is full) ... DSP processes all data within the ISR ... Set a flag in the ISR and poll for the flag in a main (always ...
    (comp.dsp)
  • Re: ZwWriteFile and buffer reuse
    ... Is it your ISR code???????? ... interrupt routine that ZwWrite routine is completed. ... You cannot touch a buffer passed to NtReadFile/NtWriteFile while it is ...
    (microsoft.public.development.device.drivers)
  • Re: General Q: Interrupt vs. Polling
    ... An external device writes data to two buffers in my DSP. ... Interrupt DSP (indicate Buffer A is full) ... DSP processes all data within the ISR ... Set a flag in the ISR and poll for the flag in a main (always ...
    (comp.dsp)
  • Re: General Q: Interrupt vs. Polling
    ... Interrupt DSP (indicate Buffer A is full) ... doing all the work within the ISR ...
    (comp.dsp)