> I'd suggest that the original poster not try to do this, but rather sends
a
> single byte and waits for a response from the PIC before sending the
next..

Yes, I'd like to reinforce that.  I've done this sort of thing many times.
Usually I have both communications directions organized as opcodes followed
by data bytes dependent on the opcode.  I make sure that the UART input
buffer on the PIC is big enough to hold the largest command.  The host is
only allowed to send a new command after the previous one has been ACKed.
Of course there are timeout rules and such to avoid lockup.

> Doing this at a higher level then the PC UART will make is more likely to
be
> portable, but it will make it slower.

I agree.  I think it's a lot better to use just the basic RS-232 features on
the host that will be available anywhere.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, olin@embedinc.com, http://www.embedinc.com

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