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

Hi,

for a low-cost design I need a small 8-bit microcontroller (1-2k Flash
will do) and now the question is whether I need to plan for an
external resonator or an internal oscillator is good enough. My
application will have to communicate through a serial interface to the
outside world. I don't know yet if that's going to be a UART or SPI or
I2C, could be different for some of our customers.

It is my understanding that a synchronous interface such as SPI or I2C
should work without problems even if the transmition rate for I2C is
not 400 kbit/s but rather something like 250 kbit/s. Same is true for
SPI.
For the UART the story is a little different, I think I need an
accuracy of 2.5% or better. Many micros list a wonderful "trimmed to
1% accuracy" but after looking closer, the temperature drift for some
Microchip devices does not permit usage of the UART over -40/85
although they advertise 1% !?!
Low power was another consideration, so I looked into the MSP430 but
that internal oscillator is a POS. It comes up fast, end of good news
about this one.
Overall the Philips LPC900 oscillators are specified with +/- 2.5%
over temp range and voltage range.  They also offer very nice
combinations of serial interfaces already in the low cost devices. Any
experience with these devices in regards to the internal oscillator
would be greatly appreciated.

Thanks for your feedback, Schwob

"Schwob" <schwobus@aol.com> wrote in message 
news:123e50e1.0408141619.5d4d54a4@posting.google.com...
> It is my understanding that a synchronous interface such as SPI or I2C
> should work without problems even if the transmition rate for I2C is
> not 400 kbit/s but rather something like 250 kbit/s. Same is true for
> SPI.

Correct. Asynchronous protocols don't matter much (if at all).

> For the UART the story is a little different, I think I need an
> accuracy of 2.5% or better. Many micros list a wonderful "trimmed to
> 1% accuracy" but after looking closer, the temperature drift for some
> Microchip devices does not permit usage of the UART over -40/85
> although they advertise 1% !?!

You have the basic idea right. The UART will be more sensitive to a drifting 
clock at lower (yes, lower) baud rates. It all depends upon whether or not 
you need accuracy with interprocessor communication or if the internal 
timers need to be semi-accurate. If they're going to be in an environment 
where the temperature varies signficantly, you can find that your CPU will 
run fast and slow, and that may be irritating - depending upon your 
application, of course.

-->Neil 

Schwob wrote:

> Hi,
> 
> for a low-cost design I need a small 8-bit microcontroller (1-2k Flash
> will do) and now the question is whether I need to plan for an
> external resonator or an internal oscillator is good enough. My
> application will have to communicate through a serial interface to the
> outside world. I don't know yet if that's going to be a UART or SPI or
> I2C, could be different for some of our customers.
> 
> It is my understanding that a synchronous interface such as SPI or I2C
> should work without problems even if the transmition rate for I2C is
> not 400 kbit/s but rather something like 250 kbit/s. Same is true for
> SPI.
> For the UART the story is a little different, I think I need an
> accuracy of 2.5% or better. Many micros list a wonderful "trimmed to
> 1% accuracy" but after looking closer, the temperature drift for some
> Microchip devices does not permit usage of the UART over -40/85
> although they advertise 1% !?!
> Low power was another consideration, so I looked into the MSP430 but
> that internal oscillator is a POS. It comes up fast, end of good news
> about this one.
> Overall the Philips LPC900 oscillators are specified with +/- 2.5%
> over temp range and voltage range.  They also offer very nice
> combinations of serial interfaces already in the low cost devices. Any
> experience with these devices in regards to the internal oscillator
> would be greatly appreciated.
> 
> Thanks for your feedback, Schwob

  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

...

> 
>Any
> experience with these devices in regards to the internal oscillator
> would be greatly appreciated.
> 
> Thanks for your feedback, Schwob


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

Neil Bradley wrote:
> "Schwob" <schwobus@aol.com> wrote in message
>
>> It is my understanding that a synchronous interface such as SPI
>> or I2C should work without problems even if the transmition rate
>> for I2C is not 400 kbit/s but rather something like 250 kbit/s.
>> Same is true for SPI.
> 
> Correct. Asynchronous protocols don't matter much (if at all).

ITYM synchronous.

> 
>> For the UART the story is a little different, I think I need an
>> accuracy of 2.5% or better. Many micros list a wonderful
>> "trimmed to 1% accuracy" but after looking closer, the
>> temperature drift for some Microchip devices does not permit
>> usage of the UART over -40/85 although they advertise 1% !?!
> 
> You have the basic idea right. The UART will be more sensitive to
> a drifting clock at lower (yes, lower) baud rates. It all depends
> upon whether or not you need accuracy with interprocessor
> communication or if the internal timers need to be semi-accurate.
> If they're going to be in an environment where the temperature
> varies signficantly, you can find that your CPU will run fast and
> slow, and that may be irritating - depending upon your
> application, of course.

No, the critical thing is agreement between the source and
receiver.  If they have separate clocks, the accuracy requirement
depends on the timing of the sampling of the individual bits and
the length of the bit stream per unit (usually 8 bit units, plus
stop and start bits, for 10).  Draw some signalling waveforms,
marking the sampling points, and it will become clear.

Synchronous protocols, on the other hand, carry the clock with
them so agreement is automatic (within reason, again depending on
the sampling technique).

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

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.




"Al Borowski" <al.borowski@EraseThis.gmail.com> wrote in message
news:411f350c$0$16339$5a62ac22@per-qv1-newsreader-01.iinet.net.au...
>
>
> ...
>
> >
> >Any
> > experience with these devices in regards to the internal oscillator
> > would be greatly appreciated.
> >
> > Thanks for your feedback, Schwob
>
>
> 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
>

"CBFalconer" <cbfalconer@yahoo.com> wrote in message 
news:411F4D38.BF6EEF59@yahoo.com...
> Neil Bradley wrote:
>> "Schwob" <schwobus@aol.com> wrote in message
>>> It is my understanding that a synchronous interface such as SPI
>>> or I2C should work without problems even if the transmition rate
>>> for I2C is not 400 kbit/s but rather something like 250 kbit/s.
>>> Same is true for SPI.
>> Correct. Asynchronous protocols don't matter much (if at all).
> ITYM synchronous.

No, I meant asynchronous, where things like I2C and SPI have separate clock 
and data lines. The clock lines can vary wildly and it'll still work. That 
won't happen with a UART which requires synchronous clocking to occur - on 
byte boundaries at least.

>> a drifting clock at lower (yes, lower) baud rates. It all depends
>> upon whether or not you need accuracy with interprocessor
>> communication or if the internal timers need to be semi-accurate.
>> If they're going to be in an environment where the temperature
>> varies signficantly, you can find that your CPU will run fast and
>> slow, and that may be irritating - depending upon your
>> application, of course.
> No, the critical thing is agreement between the source and
> receiver.

That is what I meant above by "accuracy with interprocessor communication".

> Synchronous protocols, on the other hand, carry the clock with
> them so agreement is automatic (within reason, again depending on
> the sampling technique).

And that was my point above as well.

Thank you for disagreeing with me, only to restate my points. ;-)

-->Neil 

Neil Bradley wrote:
> "CBFalconer" <cbfalconer@yahoo.com> wrote in message
>> Neil Bradley wrote:
>
>>> "Schwob" <schwobus@aol.com> wrote in message
>>>> It is my understanding that a synchronous interface such as SPI
>>>> or I2C should work without problems even if the transmition rate
>>>> for I2C is not 400 kbit/s but rather something like 250 kbit/s.
>>>> Same is true for SPI.
>>>
>>> Correct. Asynchronous protocols don't matter much (if at all).
>
>> ITYM synchronous.
> 
> No, I meant asynchronous, where things like I2C and SPI have
> separate clock and data lines. The clock lines can vary wildly
> and it'll still work. That won't happen with a UART which
> requires synchronous clocking to occur - on byte boundaries at
> least.

No, you do mean synchronous.  The clock line does the
synchronizing.  UARTs are generally asynchonous, as there is
previous agreement as to the clock rate, start/stop bits delimit
the individual transmitted bytes, and there can be any desired
time between such bytes.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

"CBFalconer" <cbfalconer@yahoo.com> wrote in message 
news:411FC1AD.91751819@yahoo.com...
> Neil Bradley wrote:
>> "CBFalconer" <cbfalconer@yahoo.com> wrote in message
>>> Neil Bradley wrote:
>>>> "Schwob" <schwobus@aol.com> wrote in message
>>>>> It is my understanding that a synchronous interface such as SPI
>>>>> or I2C should work without problems even if the transmition rate
>>>> Correct. Asynchronous protocols don't matter much (if at all).
>>> ITYM synchronous.
>> No, I meant asynchronous, where things like I2C and SPI have
>> separate clock and data lines. The clock lines can vary wildly
> No, you do mean synchronous.

No, I meant synchronous. I'm referring to the period of time when the byte 
itself is transferred. During byte transmission, a UART requires both ends 
to be completely synchronous. Of course the positions of when those bytes 
come is completely asynchronous. In a clock/data driven environment like 
I2C, you can clock at a completely irregular rate during the byte and it 
won't matter. You can't do that with a UART.

-->Neil 

I believe that UART stands for "Universal ASYNCRONOUS Receiver
Transmitter". You need to go back and study the difference between
sync and async.

Doug

"Neil Bradley" <nb_no_spam@synthcom.com> wrote in message
news:10hvisv6ucimkf3@corp.supernews.com...
> "CBFalconer" <cbfalconer@yahoo.com> wrote in message
> news:411FC1AD.91751819@yahoo.com...
> > Neil Bradley wrote:
> >> "CBFalconer" <cbfalconer@yahoo.com> wrote in message
> >>> Neil Bradley wrote:
> >>>> "Schwob" <schwobus@aol.com> wrote in message
> >>>>> It is my understanding that a synchronous interface such as SPI
> >>>>> or I2C should work without problems even if the transmition rate
> >>>> Correct. Asynchronous protocols don't matter much (if at all).
> >>> ITYM synchronous.
> >> No, I meant asynchronous, where things like I2C and SPI have
> >> separate clock and data lines. The clock lines can vary wildly
> > No, you do mean synchronous.
>
> No, I meant synchronous. I'm referring to the period of time when the byte
> itself is transferred. During byte transmission, a UART requires both ends
> to be completely synchronous. Of course the positions of when those bytes
> come is completely asynchronous. In a clock/data driven environment like
> I2C, you can clock at a completely irregular rate during the byte and it
> won't matter. You can't do that with a UART.
>
> -->Neil
>
>