PIC vs AVR vs ARM

>
> Internal R/C is of course 0 mm^2

Almost all new AVRs come with 16MHz, so crystal size should not be an
issue any more.  Low freq. crystals (32KHz) are small as well (4mm x
1mm).

> With a good calibration source you can live with the imprecision.
> Without a good calibrate you can sometimes scan the frequency range
> and lock when you have the right frequency.

And adjust it with voltage and temperature.

> Some low cost mobile phone accessories use this method when they
> communicate over the UART with the phone.

That's how we do our data logger, which is connected to the PC once in
a while.   When connected, it charges the NiMH batteries and
synchronize the clock.  The clock is constantly recalibrated based on
battery voltage and temperature (themoresister).  Both parameters are
needed for charging the batteries anyway.

Disclaimer:  I don't work for Atmel or Arm, just unbiased opinions.

Ulf Samuelsson wrote:
> >
> * 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.

1GB minimum?! haha, not even my games( circa late 2005 games too!) need
that much RAM! Well that is the amount of RAM I have in my system.

-Isaac

> Disclaimer:  I don't work for Atmel or Arm, just unbiased opinions.
>

<Troll>
Disclaimer, I work for Atmel and have unbiased opinions :-)
</Troll>

-- 
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 

Ulf Samuelsson wrote:
> "rickman" <gnuarm@gmail.com> skrev i meddelandet
> news:1159903397.463883.11040@k70g2000cwa.googlegroups.com...
> > We have used AVR MCUs in many of our products and were very happy with
> > them.  On a new project I decided to take a look at the ARM MCUs to see
> > if we could branch out from some of the limitations of the AVR.  We did
> > a very exhaustive comparison between the various ARM processors and the
> > ATmega128 and found that the ARM chips were generally lower power,
> > lower cost and fit in a smaller footprint on the board.  We also were
> > able to use a much smaller crystal.
>
> When power is an issue, you typically have to spend as much
> time as possible in sleep mode, and the Picopower AVR
> will be at least an order of magnitude better than the AT91SAM7 here.

And whether this is significant depends on the application.  The AVR
could be ten orders of magnatude better than the ARM in sleep mode, but
if the active mode power is 90% of your power budget, the sleep mode
will not have much of an impact on total power.

As I said, depending on your application this may be important.  If you
are designing a data logger where it is asleep for two weeks and then
is triggered to record something for a few seconds, sleep mode power
may be important.  But this is a very small percentage of applications.


> Also, when running from an R/C oscillator you can turn on/off almost
> instantly,
> while the AT91SAM7 probably have to start the PLL which will take ~16 ms.
> One drawback of Picopower is that the startup time from sleep
> is increased from a few clock cycles to about 70 us.
> This is the time it takes to activate the brownout detector which is
> disabled in deep sleep.
> (Don't worry, the part is protected from Brown-Out by the Power On Reset in
> deep sleep)

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!


> I think the PicoPower AVR is therefore hard to beat when you really need low
> power.

Yep, in the small percentage of apps where you need the unique features
of an 8 bit MCU tailored to low power when it is not running, then it
can do a good job.  But most MCU apps run the MCU a fair percentage of
the time if not 100%.  In those apps the power is dominated by the
active current and the ARM can beat the AVR there.

rickman wrote:


> 
> As I said, depending on your application this may be important.
> 

My experience is that it does not really matter which core to select. 
All brands offer approximately same performance for the similar price. 
What does matter when selecting the MCU is if it has the peripherals 
needed by the application.

ARMs are mainly the CPUs rather then the MCUs.
AVR peripherals are only fair.
PIC peripherals are great, albeit the PIC core is disgusting.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

http://www.abvolt.com

"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.

rickman wrote:
> 
... snip ...
> 
> 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.

-- 
 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/>

CBFalconer wrote:
> rickman wrote:
> >
> ... snip ...
> >
> > 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.
>
> --
>  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/>

Yes, from what I've read you only got an error margin of 1 or 2%. Not
too big if you ask me.
(I got this from the Intersil 82C52 datasheet). 
-Isaac

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.

On 2006-10-05, Terran Melconian <te_rem_ra_ove_an_forspam@consistent.org> 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.
>
> I wonder how exactly they arrive at 1% or 2%; do you know?

Search for Dallas/Maxim's app note 2141, "Determining Clock Accuracy
Requirements for UART Communications"

-- 
John W. Temples, III