> Experience is a good guide.
>
> The main issue is usually latency.  Assume for a moment a system with
> one or more uarts.  When a serial character comes in, can you poll the
> uart in time, before the next char arrives?
> Can you GUARANTEE that you will?   With interrupts, you can know that
> it will be a very short time.  The sticky thing is when you have
> multiple interrupt routines, and if they can take some significant
> time to execute.  It's always a very good idea to have your interrupt
> routines do as little as possible, letting the main line code do the
> bulk of the work.


Following up on my previous post, in this uart example, the ISR is
typically putting the character in a buffer that is then dealt with in
mainline code. The buffer has to be large enough that it does not overflow
before the mainline code gets to it. A "distributed processing" (sort of)
approach is to use a uart with a big fifo, then let the mainline code deal
with it. That means not using the on-chip uart since they only have a two
to four byte buffer (depending on the chip). However, I recently went to
the FT245R for USB and rely on its buffers. No interrupts needed! Also,
I'm using an SPI 802.11 radio module that has large buffers so I don't
need to have interrupts for it (I would if I used the uart version).

Harold


-- 
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist