PIC vs AVR vs ARM

Terran Melconian wrote:
> On 2006-10-05, Isaac Bosompem <x86asm@gmail.com> wrote:
> >
> > CBFalconer wrote:
> >
> >> A UART needs much better precision (and stability) than you can
> >> expect from any r/c oscillator.
> >
> > Yes, from what I've read you only got an error margin of 1 or 2%. Not
> > too big if you ask me.
>
> Assume a byte is 10 bits long (one start, one stop, no parity).  If we
> sample the bits in the middle of where we think they are, then by the
> end of the byte we can be off by just under half a bit and still read
> correctly.  This looks like about 5% to me.
>
> I wonder how exactly they arrive at 1% or 2%; do you know?
>
> I've used the internal oscillator on an AVR and it usually worked
> (except when it didn't, of course); good enough if it was only to be
> used for debugging and turned off in the final product.

Here is the aforementioned document:
http://www.maxim-ic.com/appnotes.cfm/appnote_number/2141/

You are actually pretty close. I guess Intersil put in conservative
numbers. Under less than harsh settings you get 3.3% according to the
document.

-Isaac

Terran Melconian wrote:
> On 2006-10-05, Isaac Bosompem <x86asm@gmail.com> wrote:
> >
> > CBFalconer wrote:
> >
> >> A UART needs much better precision (and stability) than you can
> >> expect from any r/c oscillator.
> >
> > Yes, from what I've read you only got an error margin of 1 or 2%. Not
> > too big if you ask me.
>
> Assume a byte is 10 bits long (one start, one stop, no parity).  If we
> sample the bits in the middle of where we think they are, then by the
> end of the byte we can be off by just under half a bit and still read
> correctly.  This looks like about 5% to me.

That will work if the other end is timed perfectly, but in reality you
need to split the timing error budget between sender and receiver.  So
that gives you 2.5% in an otherwise perfect world.  So in the real
world 2% is a better figure.


> I wonder how exactly they arrive at 1% or 2%; do you know?
>
> I've used the internal oscillator on an AVR and it usually worked
> (except when it didn't, of course); good enough if it was only to be
> used for debugging and turned off in the final product.

Exactly.  I was under the impression that on the newer parts internal
oscillators were being trimmed and compensated to get under the 2%
figure over temperature and voltage.  But since I normally use
crystals, I have not followed this closely.

Terran Melconian wrote:
> On 2006-10-05, Isaac Bosompem <x86asm@gmail.com> wrote:
>> CBFalconer wrote:
>>
>>> A UART needs much better precision (and stability) than you can
>>> expect from any r/c oscillator.
>>
>> Yes, from what I've read you only got an error margin of 1 or 2%. Not
>> too big if you ask me.
> 
> Assume a byte is 10 bits long (one start, one stop, no parity).  If we
> sample the bits in the middle of where we think they are, then by the
> end of the byte we can be off by just under half a bit and still read
> correctly.  This looks like about 5% to me.
> 
> I wonder how exactly they arrive at 1% or 2%; do you know?

There are two ends.  If each is off by 2% the disagreement is 4%. 
You also haven't considered the end effects of locating that middle
of the bit sample.  For a 16x master clock that position can be off
by 6% all by itself, which is the equivalent of 0.6% at the 10th
position.  Then there is the quantizing error due again to the
period of the master clock.

Draw timing diagrams to see all this.

-- 
 Some informative links:
   <news:news.announce.newusers
   <http://www.geocities.com/nnqweb/>
   <http://www.catb.org/~esr/faqs/smart-questions.html>
   <http://www.caliburn.nl/topposting.html>
   <http://www.netmeister.org/news/learn2quote.html>
   <http://cfaj.freeshell.org/google/>

>>
>> And the R/C oscillator is only useful in a small percentage of
>> applications where you don't need any more timing precision than
>> what is required to run a UART, and just barely that!
>
> A UART needs much better precision (and stability) than you can
> expect from any r/c oscillator.
>

Not when you can calibrate the R/C oscillator against a known
source (like the incoming data on the serial port)

The LIN protocol for automotive application was designed
to allow the use controllers running from an R/C oscillator.

The protocol start with a "wakeup" byte followed by
a "calibration" byte and after that, the uC knows the bit time
in clocks regardless of its current frequency.


So if you have a choice of protocol, and choose a protocol that
requires a stable CPU clock, you just did not do your homework.

-- 
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB 

rickman wrote:
> Terran Melconian wrote:
>> On 2006-10-05, Isaac Bosompem <x86asm@gmail.com> wrote:
>>> CBFalconer wrote:
>>>
>>>> A UART needs much better precision (and stability) than you can
>>>> expect from any r/c oscillator.
>>> Yes, from what I've read you only got an error margin of 1 or 2%. Not
>>> too big if you ask me.
>> Assume a byte is 10 bits long (one start, one stop, no parity).  If we
>> sample the bits in the middle of where we think they are, then by the
>> end of the byte we can be off by just under half a bit and still read
>> correctly.  This looks like about 5% to me.
> 
> That will work if the other end is timed perfectly, but in reality you
> need to split the timing error budget between sender and receiver.  So
> that gives you 2.5% in an otherwise perfect world.  So in the real
> world 2% is a better figure.
> 

The theoretical limit (for 10-bit chars, including start and stop) is a 
5% match.  If each end is within 2.5%, you'll get a match - you don't 
need to chop off anything extra because of uneven splits.  In fact, you 
can often *add* significant margins because of uneven splits - if one 
end is a PC, or other equipment with known tight margins, you might be 
confident of a 1% margin at the PC end, giving you 4% to play with at 
the embedded end.

However, there are other things that eat away at your margins.  Assuming 
a balanced split, you need to aim for (0.5 / 10) / 2 = 2.5% for a 
half-bit error.  If you want to take advantage of the majority vote 
noise immunity feature of many uarts, you want to be maximally 7/16 bits 
out over a total of 9 + 9/16 bits (only half the stop bit is used), 
giving you 4.6%/2 = 2.3% margins.

Then you need to look at your drivers, terminations, cable load, etc., 
and how they affect your timings.  In particular, you are looking for 
the skew between the delays on a rising edge and the delays on a falling 
edge.  These delays are absolute timings, independent of the baud rate 
and the length of each character.

Thermal and voltage effects will also affect your timing reference, and 
can be considered as part of the same margin calculations.

> 
>> I wonder how exactly they arrive at 1% or 2%; do you know?

I'd say 2% for a simple RS-232 or RS-485 link that was not stretching 
speed or distance limits, and 1% when using optical isolation or cables 
with significant capacitance.  YMMV, of course.


>>
>> I've used the internal oscillator on an AVR and it usually worked
>> (except when it didn't, of course); good enough if it was only to be
>> used for debugging and turned off in the final product.
> 
> Exactly.  I was under the impression that on the newer parts internal
> oscillators were being trimmed and compensated to get under the 2%
> figure over temperature and voltage.  But since I normally use
> crystals, I have not followed this closely.
> 

If you have good control of the environment (temperature and voltage), 
and simple links, then 2% is good enough.  If one end of the 
communication link has a more precise reference, then 2% is more than 
sufficient.

Everett M. Greene wrote:
> "Ulf Samuelsson" <ulf@a-t-m-e-l.com> writes:
> [snip]
>>> I did also read the tutorial but I didn't read through all of it.
>>> Eclipse is damn terrible, consumes a large amount of memory (seriously,
>>> on my system it consumes almost as much physical memory as that FEAR
>>> game) and is very slow.
>> I attended an Eclipse Seminar, and 1GB RAM is minimum
>> and many need 2 GB to run properly.
> 
> Good gawd, Gertie!  What were the implementors using for
> brains (presuming they had any)?  The bloated size and
> user testimonial above indicates that the implementors
> have the intelligent level of a rock.

The implementors largely worked for large companies selling computer 
hardware. They did their job.

Pete

On Oct 3, 1:56 am, Joseph <joseph....@somewhere-in-arm.com> wrote:
> Ulf Samuelsson wrote:
>
> > LMI make Cortex chips which are incompatible with most of the others.
> > Apparently they are financed by ARM themselves.
> > I guess that is one reason why the uptake is not dramatic.Hi Ulf,
>
> You might have been seriously misinformed :-)
> LMI is not financed by ARM. We are two different companies, and LMI
> is a ARM partner.
Sure different companies but almost as sure ARM puts in a lot of money
into Luminary. How could they otherwise survive? Having devices that
use the lowest power ARM CPU  yet they are much higher current than
SAM7 or LPC2000.
THe marketing gimick of the 99 cent device which I yet have to see
available anywhere is a 20 MHz max 28-pin device. You get an LPC2101
for a $1.47 @ 10k that runs 3.5 times faster, uses a lot less current
at the same speed, offer more peripherals and a nice upgrade path that
does not multiply the price just because the next device runs a
whopping 25 MHz.
This company (Luminary) can not really make any money with the devices
that lack performance, are high power and can not keep up with the wide
range of available ARM7 devices, so they must be sponsored and who but
ARM would be interested to finance it?

Talking about ARM partner, the only thing that I see Luminary attacking
are other ARM partners (canibalism!?)

They should compare themselves to the PIC24, dsPIC, AVRs (sorry Ulf),
ST10, HC12, S12, MSP430..... you name them.

An Schwob

An Schwob in the USA wrote:
> On Oct 3, 1:56 am, Joseph <joseph....@somewhere-in-arm.com> wrote:
> > Ulf Samuelsson wrote:
> >
> > > LMI make Cortex chips which are incompatible with most of the others.
> > > Apparently they are financed by ARM themselves.
> > > I guess that is one reason why the uptake is not dramatic.Hi Ulf,
> >
> > You might have been seriously misinformed :-)
> > LMI is not financed by ARM. We are two different companies, and LMI
> > is a ARM partner.
> Sure different companies but almost as sure ARM puts in a lot of money
> into Luminary. How could they otherwise survive? Having devices that
> use the lowest power ARM CPU  yet they are much higher current than
> SAM7 or LPC2000.

You are assuming facts not in evidence.  If you read their web site you
will see that they just completed a second round of financing...

"Luminary Micro closed its first private funding of $5M in February
2005 with lead investor EXA Ventures. Luminary Micro also closed a
Series B of $14 million as announced on June 12, 2006. "

I am sure they are getting a ton of support from ARM and they may have
gotten their initial funding in an indirect way from ARM.  I have seen
startups get free office space, free use of facilities and even the
loan of personel from interested parties without showing it as
"financing".  But I have no doubt that at this point LM is self
sufficient and will be turning a profit in the next year or so.


> THe marketing gimick of the 99 cent device which I yet have to see
> available anywhere is a 20 MHz max 28-pin device. You get an LPC2101
> for a $1.47 @ 10k that runs 3.5 times faster, uses a lot less current
> at the same speed, offer more peripherals and a nice upgrade path that
> does not multiply the price just because the next device runs a
> whopping 25 MHz.

I don't agree that the $.99 LM3S101 is a "gimick".  At that price point
there are any number of sockets this device can steal from the 8 bit
world.  I seem to recall a PIC clone that ran at 50 MHz and emulated a
lot of peripherals in software.  Clearly there is a place for higher
horsepower at the low price end of the market.  These smallest parts
are clearly aimed at the automotive market.  If you don't think this
market is significant, ask TI (whose ARM parts were only for automotive
customers until a year or so ago) and Micronas who makes several ARM
parts that they target to the automotive world.  Neither TI nor
Micronas make low power devices since this is not the factor in this
segment that it is in other markets.


> This company (Luminary) can not really make any money with the devices
> that lack performance, are high power and can not keep up with the wide
> range of available ARM7 devices, so they must be sponsored and who but
> ARM would be interested to finance it?

Of course they can make money.  The claim of lacking performance is not
in any way justified.  Their core can run at 50 MHz from Flash with no
wait states regardless of the code being executed which no other ARM
part can do.  The Philips parts use a lookahead buffer, but when a jump
is executed you get a multi clock cycle delay while a new Flash access
is started.

The high power claim is a bit exaggerated.  LM parts use more power
than the Atmel or Philips parts, but they are in the same ballpark as
the ADI, ST and TI product lines.  Are you suggesting that none of
these four companies have a chance of competing in the ARM market
place?


> Talking about ARM partner, the only thing that I see Luminary attacking
> are other ARM partners (canibalism!?)

I'm not sure what that is supposed to mean.  All ARM vendors compete
against one another.


> They should compare themselves to the PIC24, dsPIC, AVRs (sorry Ulf),
> ST10, HC12, S12, MSP430..... you name them.

I guess you are referring to their marketing.  My guess is that
currently there is a lot of market focus on moving to the 32 bit world.
 There are any number of articles in the trade journals about how users
are skipping 16 bits and moving directly from 8 bit parts to the 32 bit
devices.  In that context the smart marketing is to use that momentum
as leverage and show your advantages over the other 32 bit devices.

I guess your requirements exclude the LM ARM devices.  But that does
not mean they are making inferior products.  Different customers have
different requirements.

"An Schwob in the USA" <schwobus@aol.com> wrote in message 
news:1160196565.981433.178410@i42g2000cwa.googlegroups.com...
>
> On Oct 3, 1:56 am, Joseph <joseph....@somewhere-in-arm.com> wrote:

>> LMI is not financed by ARM. We are two different companies, and LMI
>> is a ARM partner.
> Sure different companies but almost as sure ARM puts in a lot of money
> into Luminary. How could they otherwise survive?

ARM did invest a small amount, but only a tiny amount of what a startup
needs.

They can survive because they will make money once they get to volume
production. Even with a tiny profit per chip selling millions of them means
lots of money.

> Having devices that
> use the lowest power ARM CPU  yet they are much higher current than
> SAM7 or LPC2000.

The initial devices are on an older process than the Atmel and Philips
devices. Even so, since the M3 is a lot faster, it doesn't need to run at
the same frequency as other MCUs so it may actually use less power.

> THe marketing gimick of the 99 cent device which I yet have to see
> available anywhere is a 20 MHz max 28-pin device. You get an LPC2101
> for a $1.47 @ 10k that runs 3.5 times faster, uses a lot less current

You're falling into the MHz = performance trap. An M3 is about twice
as fast as ARM7 MCUs running Thumb code (it runs Thumb-2
code at the same efficiency of an ARM9 running ARM code).  That
means you don't need to run at a high frequency to get the same
performance, and you use less power due to the lower frequency.

A 20MHz Cortex-M3 is faster than just about all existing 8/16-bit CPUs,
including for example a 100MHz single cycle 8051. And the 50MHz
version outperforms current ARM7 MCUs by a huge margin.

> This company (Luminary) can not really make any money with the devices
> that lack performance, are high power and can not keep up with the wide
> range of available ARM7 devices, so they must be sponsored and who but
> ARM would be interested to finance it?

Maybe it's a conspiracy?

> Talking about ARM partner, the only thing that I see Luminary attacking
> are other ARM partners (canibalism!?)

On the contrary, Luminary is aiming their chips primarily to people who
upgrade from 8-bit and 16-bit chips when they run out of steam.
Other manufacturers can and do make cheap ARM MCUs, competition
is good. What evidence do you have Luminary is "attacking" ARM partners?

> They should compare themselves to the PIC24, dsPIC, AVRs (sorry Ulf),
> ST10, HC12, S12, MSP430..... you name them.

Existing ARMs outperform most of those already by a large margin. In cases
where they don't, the M3 does now - the M3 exists solely to beat the 
existing
8/16-bitters on every aspect. As it happens it does beat ARM7 as well, but
then again ARM7 is over 10 years old...

Wilco

Wilco Dijkstra wrote:
> "An Schwob in the USA" <schwobus@aol.com> wrote in message
> news:1160196565.981433.178410@i42g2000cwa.googlegroups.com...
> >
> > On Oct 3, 1:56 am, Joseph <joseph....@somewhere-in-arm.com> wrote:
>
> >> LMI is not financed by ARM. We are two different companies, and LMI
> >> is a ARM partner.
> > Sure different companies but almost as sure ARM puts in a lot of money
> > into Luminary. How could they otherwise survive?
>
> ARM did invest a small amount, but only a tiny amount of what a startup
> needs.
>
> They can survive because they will make money once they get to volume
> production. Even with a tiny profit per chip selling millions of them means
> lots of money.

But they have to get to the millions level pretty quickly to make that
work.  Meanwhile they have completed two rounds of financing.


> > Having devices that
> > use the lowest power ARM CPU  yet they are much higher current than
> > SAM7 or LPC2000.
>
> The initial devices are on an older process than the Atmel and Philips
> devices. Even so, since the M3 is a lot faster, it doesn't need to run at
> the same frequency as other MCUs so it may actually use less power.

That is not at all clear.  "May" is a word that has been used a lot
with these parts and I am still waiting for the evidence.  At a 2:1
power ratio for the max speed and with the other parts running at
higher clock rates, the LM parts need to do a lot of catching up.


> > THe marketing gimick of the 99 cent device which I yet have to see
> > available anywhere is a 20 MHz max 28-pin device. You get an LPC2101
> > for a $1.47 @ 10k that runs 3.5 times faster, uses a lot less current
>
> You're falling into the MHz = performance trap. An M3 is about twice
> as fast as ARM7 MCUs running Thumb code (it runs Thumb-2
> code at the same efficiency of an ARM9 running ARM code).  That
> means you don't need to run at a high frequency to get the same
> performance, and you use less power due to the lower frequency.

Again, where are the benchmarks to show this?  I'm not talking about
stuff from simulations of an instruction set, I mean comparisons of an
ARM7 chip and a Cortex chip.


> A 20MHz Cortex-M3 is faster than just about all existing 8/16-bit CPUs,
> including for example a 100MHz single cycle 8051. And the 50MHz
> version outperforms current ARM7 MCUs by a huge margin.

Are there benchmarks to show this?  I would think LM would be posting
these all over their web site and I don't see any.