Re: PIC vs AVR vs ARM
- From: John <bogus@xxxxxxxxx>
- Date: Tue, 03 Oct 2006 05:51:23 GMT
Hi Miem,
In article <1159777724.426016.42900@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
MiemChan@xxxxxxxxx says...
As an amateur embedded circuit player, I have used couple of AVR and
PIC microcontrollers in the past.
In these days it is not to hard to find small, ARM based ready to use
embedded boards under $100. They seems to have faster clock speed then
most of the AVR and PIC boards.
Can anybody shortly compare ARM with PIC ad AVR interms of (a)
performance (b) software support (c) price?
Unless the project requires it, I would say stick with an AVR (my first
choice).
I've finished one project using some AVRs and now I'm attempting to use
an NXP/Philips LPC2103. I went with the LPC2103 mainly because it has a
fast A/D and it's inexpensive. I've worked with 32-bit processors on
other projects, including ARMs.
Here's my lengthy comparason of AVR vs. ARM development...
For the AVR I use CodeVision and I find it to be a very good compiler,
from a user perspective. I found the peripheral wizard in CAVR is
*very* handy -- you can start using the peripheral very quickly and you
don't have to remember the sometimes complicated initalization sequence
or register settings. With CAVR, when you're done compiling, you get
useful information on RAM and Flash resource utilization. I use
UltraEdit32 for the code writing, so I didn't use CAVR's IDE that much,
but I found it a sufficient IDE.
I did debugging using the Atmel JTAG ICE mkII and AVR studio and
debugWire. I didn't think it would very well, but surprisingly I have
very few complaints. The debugging capabilities of the new AVRs (JTAG
or debugWire) is quite good, single-stepping was very fast (you hit a
key, it steps instantly), and overall AVR Studio worked well. You can
do all the standard things you want, look at registers, memory
locations, watch variables, etc. Since AVR Studio is written by Atmel,
you get views of peripheral registers which are named, with their port
bits broken down, and you can toggle the bits as you see fit. There are
some rough spots (enabling/disabling debugWire should be done
automatically if you goto into programming mode or debug mode, is my
major gripe). CAVR has some nice extentions like PORTC.3 = 1 means bit
3 of port C is set to 1. Those kinds of extentions, I found, are very
handy in embedded prorgamming.
Contrast this to my current setup with the LPC2103. I am using the
GNUARM toolchain set (thanks Rick/Pablo/everyone else who put it
together) which in itself works. I followed a tutorial written by "Jim
Lynch" which shows how to get GNUARM, the Eclipse IDE and the OpenOCD
GBD daemon all working together. I have an existing piece of JTAG
hardware that works with OpenOCD, so I didn't have any additional
hardware costs.
With the ARM development you'll have to make a choice between sticking
your code in FlashROM and executing from there (can be slower, but
usually more code space) or putting it in RAM (not much room). This is
a limitation of working with a CPU vs. a microcontroller. A big deal
for ARM7-TDMI devices is they only have two hardware break-points. So
if you want to single-step your code which is in Flash, that requires
both hardware breakpoints. If you're using any open source tools, you
can almost forget about single-stepping and setting meaningful
breakpoints. If you want software breakpoints, you'll need to stick
your code in the limited RAM. This a big tradeoff, for the LPC2103
there is 32 KBytes of Flash but only 8KBytes of RAM.
Getting the GNUARM+Eclipse+OpenOCD working is a time consuming setup in
my opinion. The compiler works, but you'll spend a decent amount of
time mucking with C run-time files (crt0.s), assembly initalization
code, linker scripts and other things. Thank fully the LPC2000 forum at
Yahoo has some pre-exiting examples you can use as a starting point.
Eclipse has (in my opinion) an overly complicated user interface that
can be quite slow and unresponsive at times. It seems like it's very
customizable, but if you start digging, you'll find you can't streamline
it too much. Using the Eclipse IDE for writing code works OK, but using
the "Zylin Embedded CDT Debugger" is not a pleasant experience (at least
with OpenOCD), I found it very unreliable. I have since switched to the
Insight debugger with my code executing from RAM.
Insight works OK, but single-stepping takes 4-5 seconds per step! The
AVR setup single-steps instantly (or so it feels). Insight of course
has no knowledge of the chip's peripherals, so if you want twiddle
enable bits or look at peripheral settings, you'll have to dump the
memory location and work backwards.
So, on paper using one of these ultra-cheap ARM "microcontrollers" looks
good, but I think you'll find there's a decent sized leap to get it
going. I had been thinking of using these ARM parts in some personal
projects, but for now I'm sticking with the AVRs.
Someone might be quick to point out a commercial compiler would work
better and that it is unfair to compare CAVR, a commercial compiler, to
the free GNU toolset. This might be true, but commercial ARM compilers
are usually more than a few hundred $$ and they usually only work with
their JTAG debug tools, so you're very quickly locked in. Many of the
commercial ARM toolchains (Keil, Rowley for example) are based on the
GNU toolchain, so all of those limitations come along for the ride.
My $0.02
John.
.
- Follow-Ups:
- Re: PIC vs AVR vs ARM
- From: Isaac Bosompem
- Re: PIC vs AVR vs ARM
- References:
- PIC vs AVR vs ARM
- From: Miem
- PIC vs AVR vs ARM
- Prev by Date: Re: PIC vs AVR vs ARM
- Next by Date: write characters on a HD44780 controlled LCD display
- Previous by thread: Re: PIC vs AVR vs ARM
- Next by thread: Re: PIC vs AVR vs ARM
- Index(es):
Relevant Pages
|
