On Thu, 19 Aug 2004 08:21:45 +0100 (BST), simon@twoplaces.co.uk (Simon
Turner) wrote:

>On Wednesday, in article
>     <20040818.2000.302242snz@pcserv.demon.co.uk>
>     paul$@pcserv.demon.co.uk "Paul Carpenter" wrote:
>
>> Using a cheap 4 * NTSC subcarrier 14.3818MHz crystal[1], made in huge volumes
>> with economies of scale to make them cheaply and with high accuracy.
>> This frequency is then divided by 12 then divided by 65536, to give an
>> approx 18.2Hz interupt rate (actually 18.287..Hz), to achieve 18Hz interupt
>> would require a divisor of 66582.407, more than 16bits of the 8254. This
>> feeds interupt and timer software that has loads of kludges in to add part
>> seconds every n or x or y seconds, to get nearly right. It was never designed
>> to be a time piece, we all know how deterministic PC software is. The errors
>> come from many parts, so not a valid comparison. Why they did not try to
>> achieve 20Hz interupt rates instead still amazes me, as this would have a
>> much more accurate timebase clock relative to counters of seconds.
>
>It has long been suggested that the designers were *trying* to get an
>18.2 Hz clock rate, to make counting hours simple: a 16-bit counter,
>incremented once per cycle at 18.20444444 Hz, rolls over exactly once
>per hour.  It would have been rather neat (for some value of "neat")
>if they had managed it.  (Of course, this may be post-debacle
>revisionism; but it has a ring of plausibility to it.)

If you only need a time of day clock with one second resolution and
the other internal functions do not have to be synchronous to the
change of the last digit in second, those strange interrupt rates
should not be a problem, when the phase accumulator principle is used
as in NCOs (Numerically Controlled Oscillators).

A phase accumulator is set to count for instance microseconds. At each
clock interrupt, the phase accumulator is incremented by the number of
microseconds since the last clock interrupt. In the 18.2..Hz case
54925.4095.... is added at each interrupt. If only integer arithmetic
is available, the value has to be truncated to 54925. When the time
needs to be displayed, the microsecond count is divided by 1000000 and
the quotient gives the seconds and remainder the microseconds (which
grow in about 55 ms steps). 

This clock can be simply calibrated, if an external reference is
available (such as GPS) by calculating the actual crystal frequency.
If the crystal is above nominal, instead add 54924 or even smaller
values to the phase accumulator. If below nominal, add a large number
to the phase accumulator.

Due to trucation/rounding of the added value, the microsecond count
can be as much as 0.5 us off at each interrupt, thus nearly 10 us off
each second or a 10 ppm error,  or about one second off each day. This
is not of a problem in systems, in which needs to be booted many times
each day. 

This time error could be reduced by counting e.g. nanoseconds.

A more severe problem is that the algorithm needs a division
instruction, which might not be available in simple hardware. Instead
of counting microseconds, use a separate 32 bit counter to count
1/2^32 units of time. With the 18.2.. Hz interrupt rate, during each
clock interrupt 235902838 (235902837,62.. rounded up) is added to the
phase accumulator. When this accumulator overflows )i.e. the Carry bit
is set), it is time to update the second count in a separate register.

The cumulative timing error is minimal compared to the typical
frequency errors of the NTSC crystal. No special instructions are
needed, so even with simple 8 bit processors, the clock interrupt only
needs to perform 4 add with carry instructions to update the phase
accumulator and a fifth to update the second count (when the phase
accumulator overflows), of course in addition of the instructions of
loading and storing these values. If high long time accuracy is not
needed, the phase accumulator could be reduced to 24 or 16 bits,
reducing the number of instructions needed in the clock ISR.

With this principle quite strange clock interrupt rates can be used to
count the time of day quite accurately. Since the time is updated only
at each clock interrupt, the displayed TOD can be off by as much as
the clock interrupt rate, in the PC case about 55 ms.

Paul

"Paul Carpenter" <paul$@pcserv.demon.co.uk> wrote in message
news:20040818.2000.302242snz@pcserv.demon.co.uk...
> On Wednesday, in article <cfv4uf$p6p$1@news.netpower.no>
>      david@no.westcontrol.spam.com "David Brown" wrote:
> >"Paul Carpenter" <paul$@pcserv.demon.co.uk> wrote in message
> >news:20040817.1842.302217snz@pcserv.demon.co.uk...
> >> No it is a concept block about forgetting the effects of dividing down
a
> >> faster clock to get a more accurate slower clock.
> >>
> >> Consider the problem of cheap digital clocks/watches that use a
32.768KHz
> >> oscillator, using cheap as possible components but still only drift a
few
> >> seconds a month or even year. This is because the second timing is
> >produced
> >> by dividing down the 32.768KHz by 32768 (15bits) to produce the 1
second
> >> pulse, so the error rate is the oscillator drift * 1/32768 !!
> >>
> >I don't know whether to laugh or cry at this post.  If a 32.768 KHz
crystal
> >is 1% out, then when the signal is divided by 32768 to get a second
pulse,
> >the second pulse will be 1% out.  It's that simple!  It doesn't matter a
>
> When the divisor used is an EXACT match with the prefered divisor then
yes.
> When the divisor used is integer rounded it is not an exact match with
> prefered divisor, and does have an effect on what is going to happen.
>

That's certainly true.  I must admit I've been assuming that exactly
matching divisors have been used throughout this thread.  Being a power of
2, 32768 is convenient to use as a divisor, but it is hardly a requirement -
baud rate divisors are seldom a power of two.  But the value still doesn't
matter (unless you think of a crystal specified in Hz as having an inherrent
+/- 0.5 Hz tolerance).

> If expected divisor is 32890 and only 32768 can be achieved the ratio is
> different due to the combination of the effects, what was missed off
> of the above was "* expected divisor" (due to late night)..
>
> i.e.    expected divisor         1
>       * ---------------- or * -------------- * expected divisor
>         actual divisor        actual divisor
>
> For EXACT matching ratios (e.g. powers of two) this would reduce to '1'
>

If your hardware can't divide by something other than a power of two, then I
would agree.  However, while digital clock manufactorers are looking to save
the smallest fraction of a cent, I don't think a divide by 32890 circuit
would add greatly to the manufacturing costs, so it's not something I
considered relevant.  The emphasis of your post seemed to me that the
relevance of 32.678 KHz was that it needed a relatively small divisor to get
a one-second pulse, and that was what I reacted to.  Certainly other posters
in this thread have thought the size of the divisor to be relevant - if you
don't, then I appologise for assuming you made the same mistake.

> >**** if the crystal is at 32.768 KHz or 9.192631770 GHz (the oscillation
> >frequency of the most common type of atomic clock) - the percentage error
of
> >the source frequency translates directly to the percentage error in the
> >divided frequency.
>
> Both of those examples are exact powers of two, chosen for that precise
> reason.
>

9.192631770 GHz is not a power of two, and was not "chosen" - it comes from
a particular electron transition in cesium ions.  Actually, the ISO
definition of a second is 9192631770 such transition times.

> >The main reason 32.678 kHz crystals are used in watches is because 32.768
> >kHz crystals are used in watches - i.e., the economics of volume make it
> >cheaper to make that particular frequency with high accuracies.  A low
> >frequency was picked because a low frequency means low power.
>
> Also the NOMINAL value of the crystal is an exact power of two.
> No rounding of divisors putting errors in the way, and simpler logic
> required, less logic also means less power.

There is no "rounding" of divisors if the nominal value of the crystal were
an exact multiple of a Hz.  In fact, there is rounding of divisors in
digital watches with 32kHz crystals, since they routinely show hundreths of
a second.  The hundreths are not exact, but the rounding is catered for when
seconds are counted.  In the early days of digital watches, when there were
more discrete components, picking a power of two for the divisor was a good
idea, since the circuitry for a divide-by-power-of-two scaler is easier than
a divide-by-arbitrary-integer scaler, but for modern designs, the difference
is negligble.

>
> >But if logic and physics fail those of you who don't understand timing
> >errors, fall back on experience - the most accurate (in terms of how
> >accuractly it measures time, not how accuractly you happen to have set
it)
> >clock in your room is probably your digital watch, running off a crystal
in
> >the kHz range.
>
> Nominal frequency is exact power of two.
>
> >  The least accurate will be your PC's clock, running off a
> >crystal in the MHz range.
>
> Using a cheap 4 * NTSC subcarrier 14.3818MHz crystal[1], made in huge
volumes
> with economies of scale to make them cheaply and with high accuracy.
> This frequency is then divided by 12 then divided by 65536, to give an
> approx 18.2Hz interupt rate (actually 18.287..Hz), to achieve 18Hz
interupt
> would require a divisor of 66582.407, more than 16bits of the 8254. This
> feeds interupt and timer software that has loads of kludges in to add part
> seconds every n or x or y seconds, to get nearly right. It was never
designed
> to be a time piece, we all know how deterministic PC software is. The
errors
> come from many parts, so not a valid comparison. Why they did not try to
> achieve 20Hz interupt rates instead still amazes me, as this would have a
> much more accurate timebase clock relative to counters of seconds.
>
> >But the most accurate you have access to will be
> >if you have a GPS receiver, since they get their time from satellites
with
> >atomic clocks running in the GHz range.  Perhaps that will make you
realise
> >that the source rate and the divisor do not matter !
>
> GPS is chosen to be an accurate time piece, otherwise GPS will not work.
> This has to be designed to be an extremely accurate time piece first using
> an exact power of two for the purpose of not introducing rounding errors.
>

You are correct the GPS was designed for and requires a very high accuracy
clock.  The power of two argument is completly wrong, however.  Having an
*integer* divisor is very relevant - part of the (many) inaccuracies in PC
clocks comes from kludges to get non-integer divisors.


> [1] The frequency was chosen for using the clock to drive the output from
a
>     CGA card to a TV using NTSC output. Using it as the clock for the
timing
>     circuit of the system clock was more an afterthought of reducing
numbers
>     of oscillators.
>
> --
> Paul Carpenter | paul@pcserv.demon.co.uk
> <http://www.pcserv.demon.co.uk/>        Main Site
> <http://www.gnuh8.org.uk/>              GNU H8 & mailing list info.
> <http://www.badweb.org.uk/>             For those web sites you hate.
>

On Wednesday, in article
     <20040818.2000.302242snz@pcserv.demon.co.uk>
     paul$@pcserv.demon.co.uk "Paul Carpenter" wrote:

> Using a cheap 4 * NTSC subcarrier 14.3818MHz crystal[1], made in huge volumes
> with economies of scale to make them cheaply and with high accuracy.
> This frequency is then divided by 12 then divided by 65536, to give an
> approx 18.2Hz interupt rate (actually 18.287..Hz), to achieve 18Hz interupt
> would require a divisor of 66582.407, more than 16bits of the 8254. This
> feeds interupt and timer software that has loads of kludges in to add part
> seconds every n or x or y seconds, to get nearly right. It was never designed
> to be a time piece, we all know how deterministic PC software is. The errors
> come from many parts, so not a valid comparison. Why they did not try to
> achieve 20Hz interupt rates instead still amazes me, as this would have a
> much more accurate timebase clock relative to counters of seconds.

It has long been suggested that the designers were *trying* to get an
18.2 Hz clock rate, to make counting hours simple: a 16-bit counter,
incremented once per cycle at 18.20444444 Hz, rolls over exactly once
per hour.  It would have been rather neat (for some value of "neat")
if they had managed it.  (Of course, this may be post-debacle
revisionism; but it has a ring of plausibility to it.)

-- 
Simon Turner                                    DoD #0461
simon@twoplaces.co.uk
    Trust me -- I know what I'm doing!          -- Sledge Hammer

On Thu, 19 Aug 2004 10:26:25 +1200, in article
     <UHQUc.3954$zS6.446259@news02.tsnz.net>
     no.spam@designtools.co.nz "Jim Granville" wrote:

>Paul Carpenter wrote:
><snip>
>> Using a cheap 4 * NTSC subcarrier 14.3818MHz crystal[1], made in huge volumes
>> with economies of scale to make them cheaply and with high accuracy.
>> This frequency is then divided by 12 then divided by 65536, to give an
>> approx 18.2Hz interupt rate (actually 18.287..Hz), to achieve 18Hz interupt
>> would require a divisor of 66582.407, more than 16bits of the 8254. This
>> feeds interupt and timer software that has loads of kludges in to add part
>> seconds every n or x or y seconds, to get nearly right. It was never designed
>> to be a time piece, we all know how deterministic PC software is. The errors
>> come from many parts, so not a valid comparison. Why they did not try to
>> achieve 20Hz interupt rates instead still amazes me, as this would have a
>> much more accurate timebase clock relative to counters of seconds.
>
>  Probably design laziness, and a "we'll fix it later" mindset....
>Given the 8254 hardware, and the Xtal you mention, they could have got 
>to within 2.78ppm of 20Hz, with 59924 divisor, and that is within the
>trim range of any crystal.

That was my view from a quick look at calcs and the Tech refs.

>  Did they use all 3 8254 channels ? - ISTR one was for refresh, but the

The other timer was used programmable Tone generator for the speaker, this
I checked just now in some old IBM XT and AT Tech Reference manuals I have.
Even then they were worried about getting sound effects to help you type
a letter :-^

>next sensible design step would have been to cascade two timers, and 
>cascade-clock using the 20Hz sq wave output, which would have meant
>even windows could keep good time. ( of course, windows was a long way
>in the future, and who would ever need more than 640K anyway.... :)
>-jg

Even using a 20Hz interupt rate would have made less work for coding
and system overhead, and a minor improvement on determinisity. I can
remember how often things had to be coded to get around the problems
of getting 'normal' multiples of seconds for events reasonably reliably.

-- 
Paul Carpenter		| paul@pcserv.demon.co.uk
<http://www.pcserv.demon.co.uk/>        Main Site
<http://www.gnuh8.org.uk/>              GNU H8 & mailing list info.
<http://www.badweb.org.uk/>             For those web sites you hate.

Paul Carpenter wrote:
<snip>
> Using a cheap 4 * NTSC subcarrier 14.3818MHz crystal[1], made in huge volumes
> with economies of scale to make them cheaply and with high accuracy.
> This frequency is then divided by 12 then divided by 65536, to give an
> approx 18.2Hz interupt rate (actually 18.287..Hz), to achieve 18Hz interupt
> would require a divisor of 66582.407, more than 16bits of the 8254. This
> feeds interupt and timer software that has loads of kludges in to add part
> seconds every n or x or y seconds, to get nearly right. It was never designed
> to be a time piece, we all know how deterministic PC software is. The errors
> come from many parts, so not a valid comparison. Why they did not try to
> achieve 20Hz interupt rates instead still amazes me, as this would have a
> much more accurate timebase clock relative to counters of seconds.

  Probably design laziness, and a "we'll fix it later" mindset....
Given the 8254 hardware, and the Xtal you mention, they could have got 
to within 2.78ppm of 20Hz, with 59924 divisor, and that is within the
trim range of any crystal.

  Did they use all 3 8254 channels ? - ISTR one was for refresh, but the
next sensible design step would have been to cascade two timers, and 
cascade-clock using the 20Hz sq wave output, which would have meant
even windows could keep good time. ( of course, windows was a long way
in the future, and who would ever need more than 640K anyway.... :)

-jg

On Wednesday, in article <cfv4uf$p6p$1@news.netpower.no>
     david@no.westcontrol.spam.com "David Brown" wrote:
>"Paul Carpenter" <paul$@pcserv.demon.co.uk> wrote in message
>news:20040817.1842.302217snz@pcserv.demon.co.uk...
>> No it is a concept block about forgetting the effects of dividing down a
>> faster clock to get a more accurate slower clock.
>>
>> Consider the problem of cheap digital clocks/watches that use a 32.768KHz
>> oscillator, using cheap as possible components but still only drift a few
>> seconds a month or even year. This is because the second timing is
>produced
>> by dividing down the 32.768KHz by 32768 (15bits) to produce the 1 second
>> pulse, so the error rate is the oscillator drift * 1/32768 !!
>>
>I don't know whether to laugh or cry at this post.  If a 32.768 KHz crystal
>is 1% out, then when the signal is divided by 32768 to get a second pulse,
>the second pulse will be 1% out.  It's that simple!  It doesn't matter a

When the divisor used is an EXACT match with the prefered divisor then yes.
When the divisor used is integer rounded it is not an exact match with
prefered divisor, and does have an effect on what is going to happen.

If expected divisor is 32890 and only 32768 can be achieved the ratio is
different due to the combination of the effects, what was missed off
of the above was "* expected divisor" (due to late night)..

i.e.    expected divisor         1
      * ---------------- or * -------------- * expected divisor
        actual divisor        actual divisor

For EXACT matching ratios (e.g. powers of two) this would reduce to '1'

>**** if the crystal is at 32.768 KHz or 9.192631770 GHz (the oscillation
>frequency of the most common type of atomic clock) - the percentage error of
>the source frequency translates directly to the percentage error in the
>divided frequency.

Both of those examples are exact powers of two, chosen for that precise
reason.

>The main reason 32.678 kHz crystals are used in watches is because 32.768
>kHz crystals are used in watches - i.e., the economics of volume make it
>cheaper to make that particular frequency with high accuracies.  A low
>frequency was picked because a low frequency means low power.

Also the NOMINAL value of the crystal is an exact power of two.
No rounding of divisors putting errors in the way, and simpler logic
required, less logic also means less power.

>But if logic and physics fail those of you who don't understand timing
>errors, fall back on experience - the most accurate (in terms of how
>accuractly it measures time, not how accuractly you happen to have set it)
>clock in your room is probably your digital watch, running off a crystal in
>the kHz range.

Nominal frequency is exact power of two. 

>  The least accurate will be your PC's clock, running off a
>crystal in the MHz range.

Using a cheap 4 * NTSC subcarrier 14.3818MHz crystal[1], made in huge volumes
with economies of scale to make them cheaply and with high accuracy.
This frequency is then divided by 12 then divided by 65536, to give an
approx 18.2Hz interupt rate (actually 18.287..Hz), to achieve 18Hz interupt
would require a divisor of 66582.407, more than 16bits of the 8254. This
feeds interupt and timer software that has loads of kludges in to add part
seconds every n or x or y seconds, to get nearly right. It was never designed
to be a time piece, we all know how deterministic PC software is. The errors
come from many parts, so not a valid comparison. Why they did not try to
achieve 20Hz interupt rates instead still amazes me, as this would have a
much more accurate timebase clock relative to counters of seconds.

>But the most accurate you have access to will be
>if you have a GPS receiver, since they get their time from satellites with
>atomic clocks running in the GHz range.  Perhaps that will make you realise
>that the source rate and the divisor do not matter !

GPS is chosen to be an accurate time piece, otherwise GPS will not work.
This has to be designed to be an extremely accurate time piece first using
an exact power of two for the purpose of not introducing rounding errors.

[1] The frequency was chosen for using the clock to drive the output from a
    CGA card to a TV using NTSC output. Using it as the clock for the timing
    circuit of the system clock was more an afterthought of reducing numbers
    of oscillators.

-- 
Paul Carpenter		| paul@pcserv.demon.co.uk
<http://www.pcserv.demon.co.uk/>        Main Site
<http://www.gnuh8.org.uk/>              GNU H8 & mailing list info.
<http://www.badweb.org.uk/>             For those web sites you hate.

"Paul Carpenter" <paul$@pcserv.demon.co.uk> wrote in message
news:20040817.1842.302217snz@pcserv.demon.co.uk...

> No it is a concept block about forgetting the effects of dividing down a
> faster clock to get a more accurate slower clock.
>
> Consider the problem of cheap digital clocks/watches that use a 32.768KHz
> oscillator, using cheap as possible components but still only drift a few
> seconds a month or even year. This is because the second timing is
produced
> by dividing down the 32.768KHz by 32768 (15bits) to produce the 1 second
> pulse, so the error rate is the oscillator drift * 1/32768 !!
>

I don't know whether to laugh or cry at this post.  If a 32.768 KHz crystal
is 1% out, then when the signal is divided by 32768 to get a second pulse,
the second pulse will be 1% out.  It's that simple!  It doesn't matter a
**** if the crystal is at 32.768 KHz or 9.192631770 GHz (the oscillation
frequency of the most common type of atomic clock) - the percentage error of
the source frequency translates directly to the percentage error in the
divided frequency.

The main reason 32.678 kHz crystals are used in watches is because 32.768
kHz crystals are used in watches - i.e., the economics of volume make it
cheaper to make that particular frequency with high accuracies.  A low
frequency was picked because a low frequency means low power.

But if logic and physics fail those of you who don't understand timing
errors, fall back on experience - the most accurate (in terms of how
accuractly it measures time, not how accuractly you happen to have set it)
clock in your room is probably your digital watch, running off a crystal in
the kHz range.  The least accurate will be your PC's clock, running off a
crystal in the MHz range.  But the most accurate you have access to will be
if you have a GPS receiver, since they get their time from satellites with
atomic clocks running in the GHz range.  Perhaps that will make you realise
that the source rate and the divisor do not matter !

"Neil Bradley" <nb_nospam@synthcom.com> wrote in message
news:10i4upq53dpmde3@corp.supernews.com...
> "FLY135" <fly_135(@ hot not not)notmail.com> wrote in message
> news:TFtUc.24919$nx2.3491@newsread2.news.atl.earthlink.net...
> > "Neil Bradley" <nb_no_spam@synthcom.com> wrote in message
> > news:10i4f5eh141ob9e@corp.supernews.com...
> >> And the more I post, the more people pigenhole me and look for things
> >> in my statements and write me off as an idiot, insult me, or look for
> >> ways
> >> to shift the conversation to continue to make me look wrong about
> > I think the problem was that you bastardized the
synchronous/asynchronous
> > terminology and then tried to defend it instead of just going... whoops,
I
> > fouled that up.
>
> Like I said before, translation was lost between what I was thinking and
> what I actually posted. I was NOT trying to imply that a UART is
synchronous
> communication, only that for the period of a byte transmission the two
ends
> have to be at least semi-synchronized. Note that this is different from
> synchronous (clock based) communication. I'm perfectly aware of that, and
I
> stated as such many, many times. Not sure why people aren't realizing
that.
>
> > A UART doesn't use "synchronous clocking", it uses clocks
> > that are within a frequency tolerance in order to communicate.
>
> I never once said that a UART used synchronous clocking. My original
> statement meant to say that in a sychronous transport (like I2C or SPI),
the
> clocking can be as sloppy as it needs to be and it won't matter.
>
> -->Neil
>

I'm now reasonably convinced that you understand most of how uart
communication works - and I'm quite happy to accept that you have the
experiance to get one working without the understanding (you don't need to
understand *why* 5% match is an absolute requirement, regardless of baud
rate, divisor rate, crystal rate, etc., to be able to match the clocks well
enough).  You still have this obsession with cummulative absolute errors
despite their irrelevancy to the reliability of the communication, and you
still have incorrect ideas about the effect of divisors.  However, as you
say yourself, most of the problem lies in the communication between yourself
and other posters, rather than communication between microcontrollers.  I'll
leave you with a quotation from one of your earliest posts in this thread,
which you may consider in light of your denial above, and then you'll see
why people think you are confused (not an idiot, but definitely confused as
to the terminonolgy here):

Neil Bradley" <nb_no_spam@synthcom.com> wrote in message
news:10hvb8dn9hcqoa6@corp.supernews.com...> "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.
>

schwobus@aol.com (Schwob) wrote in message news:<123e50e1.0408171246.4f10c00@posting.google.com>...
> Thanks everybody for the inputs. Sorry if I started a fight between
> synchronous / synchronized.... wording, was not my intention. In the
> end I have the feeling that most voilently agreed ;-)
> 
> 
> There were recommendations to fine tune the devices if possible. I
> have seen this option for some architectures, e.g. Microchip or
> Philips but it does not really help in many applications if the other
> communication partner does not provide data to adapt the own
> frequency, did not want to use the stnc-word. Also software to
> resample the baudrate (sort of autobauding) would be needed, using a
> timer to measure the duration of the data byte would probably the best
> method.
> 
> My goal is to have it simple, not to trimm while communicating and as
> I understand the different on-chip oscillators, this is not possible
> with many of them but it is possible with some others. There are
> devices from Silabs that fit the requirement for accuracy but not the
> requirement for my BOM (a "little" too expensive) then there are those
> LPC900 devices and one in particular looks ideal, the LPC916 with 2k
> Flash, SPI, UART and I2C all on one low cost 16-pin micro. The only
> possible catch is, there is no option to connect an external crystal.
> If somebody knows about competitive devices with similar features and
> << $1 in 10k+ quantities, please let me know because I have not been
> able to find one and it is pretty much mandatory in our company to
> present 2 REAL alternatives to the financial controller.
> 
> So, if you know about devices that offer a ggod internal osc. all 3
> options for serial communication with 2k flash and an ADC, let me
> know, if not I guess I found the best solution already.
> 
> Cheers, Schwob


Hello Schwob,

although I don't know about other devices (non-LPC900) with good
serial features AND a good enough internal oscillator for less than a
Dollar, I posted something along the lines of your questions recently
in a Yahoo user group. There seem to be some knowledgable people about
the LPC900 devices there. May be you can get help there:
http://groups.yahoo.com/group/lpc900_users/message/13
CU