Why should I (not) use an internal oscillator for 8-bit micros - Page 3

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: Why should I (not) use an internal oscillator for 8-bit micros
On Mon, 16 Aug 2004 09:08:13 +0200, "David Brown"

Quoted text here. Click to load it
It's no wonder that there are so many framing errors on Async comms
when some people don't understand the basic concepts of Async and
Sync comms.

Sync transmits the clock either directly (on a clock line) or
indirectly (embedded in the data) so that the receiver know when to
look at the data bits.

Async uses the "start" bit of each byte to tell the receiver to start
timing to look at the bits of this one byte only.  

The term Asynchronous here means that the sender can send data at
anytime without having to worry about whether or not the receiver is
in sync.

How many designers try to send or receive at say 5% tolerance instead
of aiming for as close to 0% as possible.  Makes for interesting
interfacing when one unit is 5% high and the other 5% low because
they've been designed by "prima donnas" who know better than the rest
of the world.

As for crystal versus baud rate tolerances - if the crystal is 1% low
then the baud rate is 1% low. Simple as that - always allowing for the
fact that you are using the "correct" frequency crystal to start with
and allowing for any division errors in the baud rate generator/clock.


Alan

++++++++++++++++++++++++++++++++++++++++++
Jenal Communications
Manufacturers and Suppliers of HF Selcall
P O Box 1108, Morley, WA, 6943
Tel: +61 8 9370 5533 Fax +61 8 9467 6146
Web Site: http://www.jenal.com
e-mail: http://www.jenal.com/?p=1
++++++++++++++++++++++++++++++++++++++++++

Re: Why should I (not) use an internal oscillator for 8-bit micros

Quoted text here. Click to load it
required
don't
tolerance.
shared
A
it
have
would
accuracy.
a
within
when
on
hard
different

Not quite - the term "asynchronous" here means "not synchronous" - i.e., the
opposite of your correct definition of "synchronous".  The receiver is
*never* in sync with the sender in async communication, since it does not
have a clock signal on which to sychronize.

Quoted text here. Click to load it

5% tolerance is for the *total* error.  Normally that means that you need to
be within 2.5% at each end, unless you happen to know for sure that one end
will be much tighter tolerance.  Of course, only a fool would aim for
something that is only just within the theoretical limit of what was
possible!  A realisitic rule of thumb would be to aim for 1% match - any
crystal or ceramic oscillator will do, but an internal oscillator or an R-C
oscillator would need trimming.

Quoted text here. Click to load it

That is, of course, correct - I'm slightly stunned that there are people
working in this field who apparently fail to grasp that.  Hopefullly,
"apparently" is the operative word, and that it is merely the wording of
their posts that is ambiguous, rather than their understanding.

Quoted text here. Click to load it



Re: Why should I (not) use an internal oscillator for 8-bit micros
On Mon, 16 Aug 2004 13:06:48 +0200, "David Brown"
Quoted text here. Click to load it
Perhaps I could have explained it better.  But the point is that the
Async receiver uses the leading edge of the start bit to trigger it's
own internal timing mechanism which should produce sampling at the
correct time for the incoming data.  It is not, as you say, in sync
with the incoming data as it doesn't have a clock to sync to. However
the internal sampling clock needs to be less than 5% different from
the clock that produced the data to reliably decode the data.

This is always presuming that the receiving UART (or software) has
been designed properly to sample in the middle of the data bit (in the
case of a single sample per bit UART) or at the correct times for a
multi-sample per bit UART.  

In fact multi-sample per bit UARTS "could" make the tolerance
situation worse!

There is also a third type of synchronous data where the clock is not
sent but the receiver and the transmitter have to have accurate clocks
which are synchronised by a preamble only.

Quoted text here. Click to load it

It's unfortunate that there appear to be a (large) number of people
out there that don't seem to know the basic of data transmission and
end up writing code that produce wrong baud rates - especially when it
comes to bit-banging.  I always try to get as close to 0% tolerance as
possible with baud rates to cater for all the funny ones.

Alan

++++++++++++++++++++++++++++++++++++++++++
Jenal Communications
Manufacturers and Suppliers of HF Selcall
P O Box 1108, Morley, WA, 6943
Tel: +61 8 9370 5533 Fax +61 8 9467 6146
Web Site: http://www.jenal.com
e-mail: http://www.jenal.com/?p=1
++++++++++++++++++++++++++++++++++++++++++

Re: Why should I (not) use an internal oscillator for 8-bit micros

Quoted text here. Click to load it
the

The only scheme I know of for multi-sample receivers is to take 3 samples in
the middle of the bit (which is typically divided into 16 sub-bit time
slots), and use majority voting to get the result.  This shouldn't affect
the tolerance (the middle sample is going to fall exactly half-way within
the nominal bit - samples are taken *between* time slots) directly, as far
as I can see.  Having 16-times oversampling will add another +/-(1/16) bit
time to the total error, which I suppose should also be taken into account.
Certainly for 4-times oversampling receivers it would be a significant
difference, reducing your total error margin to 25%, thus requiring about
2.5% match between the sender and the receiver.

Quoted text here. Click to load it

Do you mean when the receiver's clock speed is adjusted to match a preamble
(typically a 010101 pattern) ?  As far as I know, that is used for LIN
communication, which is basically standard uart except that a preamble is
used to counter for clocks with greater than 5% mis-match (i.e., LIN slaves
are typically cheapo devices with internal oscillators).  There are plenty
of other schemes for adjustments - CAN controllers adjust their sub-sampling
clock on each bit, to avoid the error building up too much over a 80-bit
frame.

David


Quoted text here. Click to load it



Re: Why should I (not) use an internal oscillator for 8-bit micros
On Sun, 15 Aug 2004 17:16:31 -0400, "Doug Dotson"
[top posting fixed]

Quoted text here. Click to load it

One must distinguish between BIT synchronous/asynchronous or BYTE or
MESSAGE synchronous. the asynchronous in UART refers to the fact that
one or more bytes may be transmitted at any time. The time between
bytes must be at least 1 or 2 stop bits, but can as long as one wants.
On the bit level though it can be either synchronous or asynchronous.
I think that when a clock is transmitted together with a byte level
asynchronous protocol, it is refered to as isonchronous.

Regards
   Anton



Re: Why should I (not) use an internal oscillator for 8-bit micros

Quoted text here. Click to load it

No, here (as applied to a usart) asynchronous means that the data can be
sent at any time as opposed to synchronous where data is sent all the time.
Many USART (UART) have both synchronous and asynchronous modes. In
synchronous mode the usart normally sends sync bytes when it has no data to
send, and does not send a start and stop bit. The usart really does send
only 8 bits per byte. In asynchronous mode the line is quite until there is
data to send, then the usart sends a start bit to signal that data is about
to be sent, the data and finally a stop bit. The edge that signals the start
of the start bit is used to start a timer that causes bits to be sampled
near or just after the middle of the bit period. The edge is not used as a
clock signal (think about send two zeros, there is not transition between
them). Bits are sampled near the middle of the bit rather than the start to
overcome signal propagation problems. A good usart will sample the bit 3 or
more times and use a majority vote for the actual bit value.

Synchronous as applied to I2C and SPI refers to the data being sampled
relative to a separate clock.

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler





Re: Why should I (not) use an internal oscillator for 8-bit micros
Quoted text here. Click to load it

SPI is a synchronous protocol.  This does not imply that the clock has
to be free-running or at a fixed frequency.

A UART is asynchronous, because it requires no clock to be provided with
the data.  The clock is generated locally, and resynchronized at the
leading edge of the start bit.  "Asynchronous" is the "A" in "UART".

Re: Why should I (not) use an internal oscillator for 8-bit micros

Quoted text here. Click to load it

Thank you for stating in MUCH BETTER TERMS what I had meant to say
originally!

-->Neil



Re: Why should I (not) use an internal oscillator for 8-bit micros

Quoted text here. Click to load it

  This is a relatively new field, so you are right to watch the fine print!
  At the least, you should look at the Voltage / Temperature deviations,
if there is a mechanism to calibrate, as well as if the deviation
needs to be allowed at BOTH ends of the link.

  Thus XTAL <-> RegVoltTempComp OSC may be workable, but
BatteryVoltTempCompOSC  <-> BatteryVoltTempCompOSC may be out of spec.

  Aging, or drift over time, is not often defined for these on On Chip
oscillators, but you will see this defined for better crystals, and high
spec resistors. [Of course, these can cost more than cheapo uC]

  Voltage variations, the designer can do something about, by choosing
a good spec regulator 1-2% is quite doable, sub 1% is available at a
price. Temperature is not as easy, so ideally the chip vendor has done
a good job there.

  If the RC Osc has some trim scheme, then you can allow for a Baud Trim
Handshake, and that can protect you against long-term drift effects.
  I think the Philips LPC family allow this.

The safest approach is a PCB design with an option for an external
Cyrstal/resonator, plus a SW design that can Fine Baud trim,
if needed :)

-jg


Re: Why should I (not) use an internal oscillator for 8-bit micros


...

Quoted text here. Click to load it


Some microcontrollers allow you to fine tune the oscillator in software
(some PIC chips allow this). You may be able to get an external device
to send several "U"'s as test bytes, and use some trickery to calibrate
the oscillator properly.

cheers,

Al


Re: Why should I (not) use an internal oscillator for 8-bit micros
The LIN Standard allows for trimming of the Slave Oscillators, by sending a
Sync Byte ( 0x55 ) before every message, this allows slaves which are using
low cost internal oscillators to trim themselves.

Motorola now have a range of HC908QL parts that do this autmatically without
any software overhead.




Quoted text here. Click to load it



Site Timeline