From: Ulf Samuelsson on
"rickman" <gnuarm(a)gmail.com> skrev i meddelandet
news:1159903397.463883.11040(a)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.

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)

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

> The ARM we chose for this project was the AT91SAM7S64 due to its
> combination of low cost and low power. The Philips parts seem to run a
> close second and may even beat the Atmel SAM7 parts depending on
> exactly the combination of features you need. If you don't need the
> lowest power then the other brands of ARM chips could be considered, ST
> Micro STR7, TI TMS470 and Analog Devices ADuc7 among others.
>
> Did you check out the feature comparison chart at www.gnuarm.com?
> Click to the Resources page and scroll down to the ARM chips section
> where you will find three different links for the comparison chart.
>
>
>



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



From: Ulf Samuelsson on
>
> I guess I should add my $0.02 as well. I did not find the transition
> from PIC/8051 MCUs I was working with before to ARM chips to be very
> difficult at all. Yes I had to write my initialization code and the
> linker scripts but they are quite easy to learn. At first I was scared
> by linker scrips because everytime I opened one up I'd be like "what
> the hell is this?" but after learning the syntax its not so bad.
>
> I am working with the AT91SAM7S256, which is a pretty pleasant chip to
> work with.

Hear, Hear :-)

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

> Since I am working on a VERY limited budget, I use Crimson Editor to
> edit and compile my code and then use Insight to debug it. For me, its
> simple, simply press Ctrl+2 to do a make clean and Ctrl+1 to build the
> source to both an ELF and binary. I'd say to learn it because there
> might be a time in which you will need a 32-bit MCU and you don't want
> the additional burden of learning at that time.
>
> Also if you are now working with the 8-bit AVR, why not try the MSP430
> as well? I have a cheap board on it that is powered with a watch
> battery and it keeps going (of course the CPU is running off the
> internal DCO, which is only around 800kHz).
>

Or try the new AVR PicoPower chips.
Draws even less current...


> -Isaac



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



From: Ulf Samuelsson on
> Just that, physically smaller. The crystal used with the ATmega128 is
> 8 MHz max which can not be found in the really small packages. We were
> running at under 4 MHz and the crystal was huge at 11 x 7 mm, IIRC.
> The part we are using on our new ARM designs is 3.2 x 2.5 mm at 18.432
> MHz. While I was qualifying the crystal I found that they did not have
> enough info in the data sheet to select a crystal. To select a crystal
> that you can be sure will work reliably you need to know the required
> ESR and shunt capacitance. Atmel did not spec this at all in the April
> '06 data sheet. They have updated the data sheet to show this data now,
> but in a very funny way. They give you the ESR values to use at
> specific frequencies without telling you which value to use between
> those frequencies. I tried to get them to correct the table, but they
> did not seem to feel this was a problem. Do you think this is a
> cultural thing?
>

> reliably. Considering that the SAM7 parts come in as small as 7 mm
> square packages, I would think the size of the crystal would be
> significant in a number of designs.
>

Internal R/C is of course 0 mm^2
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.
Some low cost mobile phone accessories use this method when they
communicate over the UART with the phone.

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


From: Ulf Samuelsson on
>> Do you execute your code from RAM or Flash? The '256 has ample of both,
>> so I suspect the tradeoffs in going from a uC to a uP weren't as great
>> for you. Do you plan on using a '256 in production / final product, or
>> is that your development platform?
>
> Yes the chip has ample flash and RAM, I am running out of Flash though
> in ARM mode. I do not yet want to mess with the Thumb stuff. I am using
> the '256 as a simple dev platform to get a feel for the chip (and ARM
> chips in general).

You will get a performance boost by running in Thumb mode on the SAM7.

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


From: linnix on
>
> 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.