Salut PicList, c'est encore moi!
Salut, comment tu va?
.....................................................

 Scott Dattalo wrote:
> ...But for a real system where serial data is coming
> in and going out while the PIC is busy doing stuff,
> you need to be able to handle these tasks simultaneously.
> There are many approaches to this problem, and
> depending on the system requirements each has its
> merit. I tend to prefer interrupt driven code with circular
> buffers for the transmit and the receive processes.
> If memory is an issue, then polled drivers may be more
> appropriate. Maybe someone one day will release
> a driver based on his code...

 Polling sure is a sometimes thing. I've come to this
in my recent project: PC controlling some hardware
through PIC by RS232.

 My PIC's software consists of few dozens modules, which
are launched one after one continuously. Some register
holds "handle". When current module sees "its" active
handle, it transmits byte of his data to send, then deactivates
the handle. The handle is incremented and activated by
first module of the loop over some fixed number of polling
steps to ensure that bytes are not send "too often" to PC.

 The second module of the loop monitors incoming bytes
checking RCIF of the PIR1. When byte has come, it
receives it into some register and places the handle into
another register, getting it from the incoming context. So
the module associated with this handle can process the
byte.

 A fare amount of redundancy (continuous transmission,
context expenses) helps fault tolerance.
 Regular transmission could easily be monitored by scope
and non-real-time MS Windows could be more predictable,
as for me in my particular case.

 Mike. (Just my 2 uninterruptable coins :-)

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