On Tue, Feb 26, 2002 at 04:23:01PM -0700, Dwayne Reid wrote:
> At 01:18 PM 2/26/02 -0500, Byron A Jeff wrote:
> >On Tue, Feb 26, 2002 at 10:36:00AM -0500, Olin Lathrop wrote:
> > > > The grief saving answer is no. The true answer is "maybe if the
> > conditions
> > > > are right." Conditions being that the bit rate is slow enough and there
> > > > isn't drastic changes in temperature.
> > >
> > > The absolute bit speed has nothing to do with it.  The relative speed error
> > > is what matters.  You'd like to be within 3%, whether that's 300 baud +-9,
> > > or 115.2Kbaud +- 3500.
> >
> >But if you slow it down then the absolute amount of time before the error
> >is exceeded is lengthned.
> >
> >Change your examples to a time scale by inverting:
> >
> >300 bPS cell width: 3.3333 ms +- 0.3ms
> >115k bPS cell width: 0.00886805 mS +- 0.000256 ms
>
> Byron - please forgive me for disagreeing with you.  Olin is more correct
> than you.
>
> The baud rate is directly related to Fosc.  If Fosc changes by 1%, so does
> the baud rate.  You are correct in that one can have a slight amount more
> error at higher baud rates because of rounding error but that is a problem
> only if Fosc is not an exact multiple of the desired baud rate.

Now that's an explanation that I can understand. Thanks for pointing out
that the error is cumulative at any bit rate.

>
> Using the internal RC oscillator (4 MHz) *can* result significant rounding
> error at high baud rates - *IF* you are using standard baud rates.  For PIC
> to PIC communications, one can choose a non-standard baud rate with no
> rounding error at the desired speed.
>
> However, having said all that, I feel that using the internal RC oscillator
> for the timebase for serial comms is iffy at best.  I don't use it in my
> products - I have to operate over the temperature range of -40 through +85C
> in almost everything I ship.  The internal RC oscillator just isn't stable
> enough over that wide a temperature range.

What is the INTRC variability over that range?

>
> One can design a serial protocol that adjusts to the correct baud rate
> automatically.  This involves measuring the width of one or more bits in
> terms of the number of clock cycles, then adjusting the sample delays or,
> in the case of hardware UART, adjusting the baud rate registers.  But this
> requires designing an appropriate protocol from the ground up.  Again - so
> long as both ends of the link understand the requirements - no problem.

Self tracking the USART seems like a good idea.

Thanks for the heads up.

BAJ

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics