Searching \ for '[PIC]: Internal RC oscillator for serial comm?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ios.htm?key=serial
Search entire site for: 'Internal RC oscillator for serial comm?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Internal RC oscillator for serial comm?'
2001\01\07@135517 by Stephen B Webb

flavicon
face
I believe there was a discussion on here before regarding the internal RC
oscillator on the the PIC (f84) and how it wasn't accurate enough to build
a serial communication routine around.

I am curious to know if the unpredictable oscillator behavior is evident
only over long time periods, or if it is a problem for adjacent bit
periods.

Basically what I am thinking is to determine the incoming bit period based
on the first (known) received byte, and using this bit period value for
the next 1/2 second.  Would a scheme like this be viable?

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\01\07@180311 by Bob Ammerman

picon face
> Basically what I am thinking is to determine the incoming bit period based
> on the first (known) received byte, and using this bit period value for
> the next 1/2 second.  Would a scheme like this be viable?

Absolutely!

You have an error budget of at least a couple percent in typical 8N1 async
comms.

Since you are setting your bit time relative to received bit time, you will
effectively get that entire budget for your end of the link (including your
error in estimating the received bit time, of course).

Unless your Vcc is bouncing up and down, or you are zapping the chip with a
freeze spray, chances are the RC osc will be quite stable over short
(subsecond) intervals.

Just be sure you do a good job of estimating the bit time from the received
data. A couple of useful tricks:

1: Measure from a rising edge to another rising edge, or from a falling edge
to another falling edge. This eliminates any asymmetry in response to the
two edges as an error source.

2: Measure more than a single bit time, then divide by the appropriate
value. This gives you a longer 'baseline' for your computation.

For example, if you use a character like B'10000010' you can time from the
1->0 to the next 1->0 and then divide by 6 to get the actual bit time.

Since dividing by 6 is a bit painful you could use B'10001000' and then
divide by four (just a couple of shifts).

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


More... (looser matching)
- Last day of these posts
- In 2001 , 2002 only
- Today
- New search...