Darren King wrote:

> I can understand using the Recieve Interupt as that would allow you to
> buffer bytes and then read them when you get the time, but why would
> you need a send Interupt?

  You are quite correct in your curiousity.  They are rarely used.  Most
transmit loops go along the lines of:

  While true do {
  txc=(producer_function)
  While not tx_reg_empty
    do { another_task_segment }
  send(txc)
  }

  You could of course use a transmit buffer but there will always be the
possibility that the "producer" function will run fast enough to fill it
and you then have to wait on the buffer anyway.  The buffer will spend
its time mostly either full or empty, not useful in either case.

  Receiver functions OTOH  will mostly be able to keep up with the
input but you need a buffer in case they *temporarily* don't.  If the
receiver buffer ever fills then you have a crash.  You may use flow
control to avoid this.

  The classic example of this are the CR/ LF functions on a VDU which
involve shifting many characters whilst just printing each character is
dead easy.

  In summary, you use a receiver buffer as you can't afford not to,
while having no transmit buffer may at worst slow down communications.

  As to the PIC, yes, one IRQ vector means you have to poll for all
possibilities in the service routine.  In itself a good reason for
using no more interrupts than you can avoid, preferably one or two.

  My suggestion is that RXD is an excellent use of an interrupt, TXD and
"heartbeat" timers aren't in most cases..
--
  Cheers,
        Paul B.