Pic List,
Is the internal osc. of the 12C508/9 stable and accurate enough for RS-232?
It seems to work, but can I depend on it? Microchip says resonators are
too variable for serial work, and so I have always used crystals. Is the
internal osc on these chips stable enough for reliable indoor operation?
Thanks,
John
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
Pic List,
Is the internal osc. of the 12C508/9 stable and accurate enough for RS-232?
It seems to work, but can I depend on it? Microchip says resonators are
too variable for serial work, and so I have always used crystals. Is the
internal osc on these chips stable enough for reliable indoor operation?
Thanks,
John
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
No. I believe the internal RC osc is rated at +- 8%. That may not seem
like too much error, but when doing RS-232, the error is cumulative. Over
a 10 bit word, you could drift up to 80% of a bit, pushing your sample well
into the next bit.
It is not impossible to use an RC though. The maximum error occurs over
time, temperature, voltage and process. It will not CHANGE rapidly. If
you could calibrate the processor speed periodically, you could get away
with such large errors. Doable, but requires a specific plan for dealing
with the uncertainties.
Resonators are accurate enough. Most are better than 3% over temperature
and voltage, INCLUDING ageing. That results in a maximum error of 1/3 bit.
>Pic List,
>Is the internal osc. of the 12C508/9 stable and accurate enough for RS-232?
>It seems to work, but can I depend on it? Microchip says resonators are
>too variable for serial work, and so I have always used crystals. Is the
>internal osc on these chips stable enough for reliable indoor operation?
>Thanks,
>John
>
>
>__________________________________________________
>Do You Yahoo!?
>Talk to your friends online with Yahoo! Messenger.
>http://im.yahoo.com
>
At 09:37 AM 3/27/00 -0600, John C. Frenzel wrote:
>Pic List,
>Is the internal osc. of the 12C508/9 stable and accurate enough for RS-232?
>It seems to work, but can I depend on it? Microchip says resonators are
>too variable for serial work, and so I have always used crystals. Is the
>internal osc on these chips stable enough for reliable indoor operation?
As discussed before, the total error budget over 10 bits (start, 8 data,
stop) is 1/2 bit-time, but the stop bit is a special case, in that it just
has to be there. The last edge of the stop bit dosen't even really exist,
so I'd calculate the max error allowable as 1/2 bit time in 9 bits.
This works out to 5.5% error in timing. Of course that assumes that the
receiver is exactly correct, which seems doubtful. 2.75% is a more
workable figure. (Let the other guy be at least as sloppy as you are)
So in the chip spec, what's the tolerance on the internal osc over the
voltage/temp range you anticipate using? If it's looser than 2.75%, then
you're questionable. If it's looser than 5.5%, you're not survivable.
Realize though, the other guy may have eaten more than half the error
budget in his receiver!
The other side of this is, hobby or production line? A hobby project can
push the envelope a lot harder than a commercial product. I see things
"working" in hobby projects all the time that would be a "fire the
engineer" in a commercial environment.
Isn't serial fun?
:)
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.2 for non-commercial use <http://www.pgp.com>
>Resonators are accurate enough. Most are better than 3% over temperature
>and voltage, INCLUDING ageing. That results in a maximum error of 1/3 bit.
To pick a nit, that's not the maximum error if you're bit-banging. From
the design point of view, you'd have to consider that the minimum error.
You also have to consider the accuracy of your algorithm, and the effects
of any interrupts you may have turned on. Unfortunately, nobody else can
tell you what that will be, you'll have to walk the code yourself.
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.2 for non-commercial use <http://www.pgp.com>
>Pic List,
>Is the internal osc. of the 12C508/9 stable and accurate enough for RS-232?
>It seems to work, but can I depend on it? Microchip says resonators are
>too variable for serial work, and so I have always used crystals. Is the
>internal osc on these chips stable enough for reliable indoor operation?
>Thanks,
>John
>
... to which several replies were made. I agree with all the
responses thus far, but would like to stress that it is good practice to
use more than one stop bit whenever you can. This allows the receiver to
resync to the next start bit, so that errors don't accumulate (as they
would if exactly one stop bit is used). For most applications, the speed
reduction from using 8N2 instead of 8N1 is imperceptable.
We make several RS232 based products based on the '508 with the
internal RC osc, and find consistent operation as long as the rate isn't
pushed beyond 9600 baud. With a crystal time base, you could easily get
57600 and could probably push 90K (in bursts).
> As discussed before, the total error budget over 10 bits (start, 8 data,
> stop) is 1/2 bit-time
I would not suggest that a bit sent 1/2 bit time late is always correctly
received. A 16x oversampling UART will need the edge 2/16 _before_ the
bit middle (to ensure that the "middle" 3 samples are always correct).
Other receiver designs may vary.
At least the mentioned 2/16 should be substracted from 1/2 _before_ dividing
the rest into the equal error budgets for the two parties.
The stopbit must be included into the calculation (and not stripped out
as you did) because the error can be "early" _or_ "late". When the stopbit
is sent _late_, the receiver might sample the previous bit as stopbit.
With all that taken into account, the maximum error per party on 8N1 comm
is 1.875%.
But it assumes that when you mathematically know you're 1.875% off, that
you physically don't introduce _more_ errors. In reality you do! XTAL
and line driver tolerances limit that further, so even a baudrate
divider value that hits 1.875% exactly can still lead to comm errors.
Therefore you should never exceed 1.5% approx.
2.75% is definately way too much!!!!! Almost twice the rationally
suggested value, and therefore eating almost everything of the (real
world) error budget.
For a visual understanding of the RS232 clock error, take a look at: http://www.ustr.net/8051pc/starting.htm
and check from the middle to the end of that page, "CLOCK SIGNAL", where
you will see that up to 2.1% of frequency shift is yet acceptable, for
8N1 assync comm.
Wagner.
>
> > As discussed before, the total error budget over 10 bits (start, 8 data,
> > stop) is 1/2 bit-time
>
> I would not suggest that a bit sent 1/2 bit time late is always correctly
> received. A 16x oversampling UART will need the edge 2/16 _before_ the
> bit middle (to ensure that the "middle" 3 samples are always correct).
>
> Other receiver designs may vary.
>
> At least the mentioned 2/16 should be substracted from 1/2 _before_ dividing
> the rest into the equal error budgets for the two parties.
>
> The stopbit must be included into the calculation (and not stripped out
> as you did) because the error can be "early" _or_ "late". When the stopbit
> is sent _late_, the receiver might sample the previous bit as stopbit.
>
> With all that taken into account, the maximum error per party on 8N1 comm
> is 1.875%.
>
> But it assumes that when you mathematically know you're 1.875% off, that
> you physically don't introduce _more_ errors. In reality you do! XTAL
> and line driver tolerances limit that further, so even a baudrate
> divider value that hits 1.875% exactly can still lead to comm errors.
>
> Therefore you should never exceed 1.5% approx.
>
> 2.75% is definately way too much!!!!! Almost twice the rationally
> suggested value, and therefore eating almost everything of the (real
> world) error budget.
> > As discussed before, the total error budget over 10 bits (start, 8 data,
> > stop) is 1/2 bit-time
>
> I would not suggest that a bit sent 1/2 bit time late is always correctly
> received. A 16x oversampling UART will need the edge 2/16 _before_ the
> bit middle (to ensure that the "middle" 3 samples are always correct).
If your frequency is off because of an inconvenient clock speed, rather
than temperature variations, AND you're receiving using some sort of
software-driven UART, THEN you ought to be able to adjust the time of
your first sample (from the nominal 1/2 bit time) to allow for larger
percentages of KNOWN ERROR. ie, if you're sampling a bit slow, then
take the first sample earlier so that the last sample will still be
within the last bit. If you're sampling a bit fast, start later. A
KNOWN ERROR can be corrected for, it's only the unknown errors that you
need to keep within parameters. (unfortunately, this doesn't help when
transmitting, since even your "known error" is an unknown error for the
receiver.
YAHOO.COM> on 03/27/2000 10:37:01 AM
