Thanks guys,

I will go and look at the URL Olin send me, but your comments are =
appreciated very much.=20

Thanks again

Regards

Nic Scheepers



> -----Original Message-----
> From: Mike Singer [mailto:msinger@POLUOSTROV.NET]
> Sent: 10 November 2002 22:49
> To: PICLIST@MITVMA.MIT.EDU
> Subject: Re: [PIC]:hardware UART on the 16F877
>=20
>=20
> Salut PicList, c'est encore moi!
> Salut, comment tu va?
> .....................................................
>=20
>  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...
>=20
>  Polling sure is a sometimes thing. I've come to this
> in my recent project: PC controlling some hardware
> through PIC by RS232.
>=20
>  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.
>=20
>  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.
>=20
>  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.
>=20
>  Mike. (Just my 2 uninterruptable coins :-)
>=20
> --
> http://www.piclist.com hint: The PICList is archived three different
> ways.  See http://www.piclist.com/#archives for details.
>=20
>=20
>=20

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