> I don't want my program locked up in tight delay loops
> during things like flashing an LED - if that will affect
> its responsiveness to input.
>
> How do most of you deal with issues like this?

I try to break everything into small atomic events that can each be
handled "quickly" without waiting on anything.  The main code is a loop
looking for events that needs handling.  If it finds one, it handles it,
then jumps back to the start of the main loop.  That also puts events into
a priority order, which can often be useful.

Some events are so high priority or would be missed by polling that they
are handled as an interrupt.  In general, defer any interrupt processing
to the main event loop if possible.  This may mean taking care of the
immediate real-time issue in the interrupt handler and setting flags so
that the remaining issues can be handled in the event loop when it gets
around to it.

Think about blinking the LED as individual "LED on" and "LED off" events.
Everything can be easily based on a timer interrupt.  Timer 2 is usually a
good choice for providing a steady clock tick interrupt.

> Should I incorporate a cheap 2nd PIC and use a few IO pins
> to tell it what to present to the user?

Unless your are completely out of cycles or program memory, this is silly.

> (2) Buffer incoming data so I can check it at my
> liesure?

What you want is a FIFO.  I've got a bunch of FIFO_xxx macros in
STD.INS.ASPIC at http://www.embedinc.com/pic.  I've also got a template
UART handler that uses the FIFOs and does interrupt driven I/O.  See the
QQQ_UART.ASPIC module.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.