1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

PIC vs AVR vs ARM

Discussion in 'Embedded' started by Miem, Oct 2, 2006.

  1. Miem

    Miem Guest

    Hi All,

    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?

    Regards,

    Miem
    Miem, Oct 2, 2006
    #1
    1. Advertising

  2. Miem

    Tim Wescott Guest

    Miem wrote:

    > Hi All,
    >
    > 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?
    >
    > Regards,
    >
    > Miem
    >

    (a) Significantly better. You can't beat it with an 8-bit processor.
    (b) At least as good, particularly if you don't mind gnu tools.
    (c) It'll be harder to really shave the pennies off in a high-
    volume application, and a bare-minimum ARM board will be bigger,
    more power hungry and have a higher BOM cost than a bare-
    minimum AVR or PIC board.

    --

    Tim Wescott
    Wescott Design Services
    http://www.wescottdesign.com

    Posting from Google? See http://cfaj.freeshell.org/google/

    "Applied Control Theory for Embedded Systems" came out in April.
    See details at http://www.wescottdesign.com/actfes/actfes.html
    Tim Wescott, Oct 2, 2006
    #2
    1. Advertising

  3. Miem

    linnix Guest

    > ...
    > (c) It'll be harder to really shave the pennies off in a high-
    > volume application, and a bare-minimum ARM board will be bigger,
    > more power hungry and have a higher BOM cost than a bare-
    > minimum AVR or PIC board.


    AVR has wider operating voltage range than ARM, which is useful for
    dealing with different logic devices.
    linnix, Oct 2, 2006
    #3
  4. Miem

    PeteS Guest

    linnix wrote:
    > > ...
    > > (c) It'll be harder to really shave the pennies off in a high-
    > > volume application, and a bare-minimum ARM board will be bigger,
    > > more power hungry and have a higher BOM cost than a bare-
    > > minimum AVR or PIC board.

    >
    > AVR has wider operating voltage range than ARM, which is useful for
    > dealing with different logic devices.


    The only technical downsides to ARM are the minimum system complexity
    and power, as Tim already mentioned. As always in engineering, it comes
    down to 'it depends' and the dependency is, in this case, what you need
    (or want) to achieve with the system.

    If you need an ultra low current system monitor, it's hard to beat the
    AVR or PIC (I prefer the AVR for a number of reasons). So which is
    'better' is a much harder question.

    Cheers

    PeteS
    PeteS, Oct 2, 2006
    #4
  5. PeteS wrote:
    > linnix wrote:
    >>> ...
    >>> (c) It'll be harder to really shave the pennies off in a high-
    >>> volume application, and a bare-minimum ARM board will be
    >>> bigger, more power hungry and have a higher BOM cost than a
    >>> bare- minimum AVR or PIC board.

    >>
    >> AVR has wider operating voltage range than ARM, which is useful for
    >> dealing with different logic devices.

    >
    > The only technical downsides to ARM are the minimum system complexity
    > and power, as Tim already mentioned. As always in engineering, it
    > comes down to 'it depends' and the dependency is, in this case, what
    > you need (or want) to achieve with the system.
    >
    > If you need an ultra low current system monitor, it's hard to beat the
    > AVR or PIC (I prefer the AVR for a number of reasons). So which is
    > 'better' is a much harder question.
    >


    Some more things that come to mind...

    Size of package could be an issue as well.
    Not a lot of ARM options below 48 pins.
    Almost all ARM have JTAG so if you need OCD
    you lose multiple pins.

    Determinism when toggling I/O ports could be an issue.
    The ARM has to pass through a number of interfaces
    before the I/O pin is reached, and this can
    take some clock cycles and add jitter.

    This of course allows an AVR to run at lower clock frequqncy at
    the same toggle rate.

    Putting the I/O on the 32 bit ASB/AHB bus will help
    but the drawback is higher capacitance on the ASB/AHB
    bus which should increase power consumption.

    ARM parts typically lack byte addressable EEPROM.

    It is easy to prototype using DIL packages.
    Normally not available for ARM.

    The AVR has more (but narrower) registers
    allowing global variables to be stored there.

    Bit instructions.

    Generally AVR code is smaller than ARM code.


    > Cheers
    >
    > PeteS


    --
    Best Regards,
    Ulf Samuelsson

    This message is intended to be my own personal view and it
    may or may not be shared by my employer Atmel Nordic AB
    Ulf Samuelsson, Oct 2, 2006
    #5
  6. Miem

    linnix Guest


    > Almost all ARM have JTAG so if you need OCD you lose multiple pins.


    That is the positive side of ARM. Jtag is always there, and reliable.
    AVR Jtag, on the other hand, could be disabled, and thus un-reliable by
    definition.
    linnix, Oct 2, 2006
    #6
  7. On 2 Oct 2006 15:16:16 -0700, "linnix" <-for.us> wrote:

    >> Almost all ARM have JTAG so if you need OCD you lose multiple pins.

    >
    >That is the positive side of ARM. Jtag is always there, and reliable.
    >AVR Jtag, on the other hand, could be disabled, and thus un-reliable by
    >definition.


    Last I looked, some years ago, ARM JTAG is also documented --
    including the debug interface.

    Jon
    Jonathan Kirwan, Oct 2, 2006
    #7
  8. Miem

    steve Guest

    Miem wrote:
    > Hi All,
    >
    > 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?
    >
    > Regards,
    >
    > Miem


    AVR and PIC aren't really comparable with ARM, the first two are very
    low cost/power 8 bit machines, the ARM is a higher power, higher cost
    32 bit machine. If you need to make a device that needs to run on a
    coin cell for 2 years, you can't pick an ARM processor, if you need a
    CPU that can do real time FFT, a PIC won't do it.
    steve, Oct 2, 2006
    #8
  9. Miem

    Buddy Smith Guest

    steve <> wrote:

    > AVR and PIC aren't really comparable with ARM, the first two are very
    > low cost/power 8 bit machines, the ARM is a higher power, higher cost
    > 32 bit machine. If you need to make a device that needs to run on a
    > coin cell for 2 years, you can't pick an ARM processor, if you need a
    > CPU that can do real time FFT, a PIC won't do it.


    I thought so too, but the products from luminary micro
    (luminarymicro.com), discussed in this newsgroup recently and in Circuit
    Cellar, have changed my mind.

    They make ARM CPUs with very little RAM and flash, on the cheap.... they
    say less than one dollar in 10k quantities (from an advertising spiel)

    ttyl,

    --buddy
    Buddy Smith, Oct 3, 2006
    #9
  10. Miem

    steve Guest

    Buddy Smith wrote:

    > I thought so too, but the products from luminary micro
    > (luminarymicro.com), discussed in this newsgroup recently and in Circuit
    > Cellar, have changed my mind.
    >
    > They make ARM CPUs with very little RAM and flash, on the cheap.... they
    > say less than one dollar in 10k quantities (from an advertising spiel)
    >
    > ttyl,
    >
    > --buddy


    yes but they are very high power, I think 10x the power of the AVR at
    1Mhz, if I remember correctly
    steve, Oct 3, 2006
    #10
  11. Miem

    Jason Guest

    To add to this question, I've been doing mostly AVR work and I'd like to
    branch into ARM. I had planned on just picking up some of Atmel's ARM
    gear, but would anyone suggest any other first leap friendly ARM procs?
    The Luminary has already been mentioned and seems interesting.


    Jason
    The place where you made your stand never mattered,
    only that you were there... and still on your feet


    Miem wrote:
    > Hi All,
    >
    > 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?
    >
    > Regards,
    >
    > Miem
    >
    Jason, Oct 3, 2006
    #11
  12. linnix wrote:
    >> Almost all ARM have JTAG so if you need OCD you lose multiple pins.

    >
    > That is the positive side of ARM. Jtag is always there, and reliable.
    > AVR Jtag, on the other hand, could be disabled, and thus un-reliable
    > by definition.


    JTAG can be disabled in AT91SAM7 circuits as well.
    It is *MANDATORY* if you want any type of code protection...
    (The Boundary Scan will still work of course)

    --
    Best Regards,
    Ulf Samuelsson

    This message is intended to be my own personal view and it
    may or may not be shared by my employer Atmel Nordic AB
    Ulf Samuelsson, Oct 3, 2006
    #12
  13. Buddy Smith wrote:
    > steve <> wrote:
    >
    >> AVR and PIC aren't really comparable with ARM, the first two are very
    >> low cost/power 8 bit machines, the ARM is a higher power, higher cost
    >> 32 bit machine. If you need to make a device that needs to run on a
    >> coin cell for 2 years, you can't pick an ARM processor, if you need a
    >> CPU that can do real time FFT, a PIC won't do it.

    >
    > I thought so too, but the products from luminary micro
    > (luminarymicro.com), discussed in this newsgroup recently and in
    > Circuit Cellar, have changed my mind.
    >
    > They make ARM CPUs with very little RAM and flash, on the cheap....
    > they say less than one dollar in 10k quantities (from an advertising
    > spiel)


    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.

    > ttyl,
    >
    > --buddy


    --
    Best Regards,
    Ulf Samuelsson

    This message is intended to be my own personal view and it
    may or may not be shared by my employer Atmel Nordic AB
    Ulf Samuelsson, Oct 3, 2006
    #13
  14. Miem

    John Guest

    Hi Miem,

    In article <>,
    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.
    John, Oct 3, 2006
    #14
  15. Miem

    Joseph Guest

    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.

    The definition of incompatible is a bit unclear.
    Same as any Cortex-M3 chips, the LuminaryMicro Cortex-M3 chips are not
    binary compatible with traditional ARM processors. The Thumb
    instructions is the same (except BLX and SETEND instructions). But
    startup code, interrupt handlers and system control codes (e.g. mode
    switching) will have to be rewritten.

    However, application codes developed for LuminaryMicro parts will work
    on any other Cortex-M3 parts (of course some code might need to be
    changed if the peripherals / memory map are different).

    regards,
    Joseph
    Joseph, Oct 3, 2006
    #15
  16. John wrote:
    > Hi Miem,
    > *snip *


    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.

    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.

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

    -Isaac
    Isaac Bosompem, Oct 3, 2006
    #16
  17. Miem

    rickman Guest

    steve wrote:
    > Buddy Smith wrote:
    >
    > > I thought so too, but the products from luminary micro
    > > (luminarymicro.com), discussed in this newsgroup recently and in Circuit
    > > Cellar, have changed my mind.
    > >
    > > They make ARM CPUs with very little RAM and flash, on the cheap.... they
    > > say less than one dollar in 10k quantities (from an advertising spiel)
    > >
    > > ttyl,
    > >
    > > --buddy

    >
    > yes but they are very high power, I think 10x the power of the AVR at
    > 1Mhz, if I remember correctly


    I think you are mistaken. If you compare the ARM MCUs at the same
    frequency that the AVR runs, you will see that the power for the ARM
    can be lower than for the AVR. That is one of the big reasons that we
    recently used an ARM in a new design in place of the AVR which we have
    typically used in the past.

    It may be that in the smaller configurations an AVR can run at much
    lower power, but if you are comparing apples and not oranges, I think
    the ARM chips can keep up with most 8 bit parts in terms of power.
    rickman, Oct 3, 2006
    #17
  18. Miem

    rickman Guest

    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.

    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.



    Jason wrote:
    > To add to this question, I've been doing mostly AVR work and I'd like to
    > branch into ARM. I had planned on just picking up some of Atmel's ARM
    > gear, but would anyone suggest any other first leap friendly ARM procs?
    > The Luminary has already been mentioned and seems interesting.
    >
    >
    > Jason
    > The place where you made your stand never mattered,
    > only that you were there... and still on your feet
    >
    >
    > Miem wrote:
    > > Hi All,
    > >
    > > 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?
    > >
    > > Regards,
    > >
    > > Miem
    > >
    rickman, Oct 3, 2006
    #18
  19. Miem

    steve Guest

    rickman wrote:

    > I think you are mistaken. If you compare the ARM MCUs at the same
    > frequency that the AVR runs, you will see that the power for the ARM
    > can be lower than for the AVR.


    Depends alot on how fast you run them, but the ARM's always use more
    power per frequency, the AVR is an 8 bit device that can operate down
    to 1.8 Volts the ARM is a 32 bit device that requires 3.3 Volts, so it
    obvious who is going to use less power (assuming all else being equal,
    process, I/O, RAM, FLASH etc). looking up a couple datasheets

    Analog Devices ARM 7021 7.2mA@1.3 Mhz(typical)
    Atmel Atmega164 .4mA@1.0 Mhz(typical)

    At higher speeds the ARM's don't have as bad mA/ Mhz ratio
    Luminary Micro LM3S101 35mA@20 Mhz (typical, running out of SRAM, no
    active peripherals)
    Analog Devices ARM 7021 33mA@41 Mhz(typical)


    That is one of the big reasons that we
    > recently used an ARM in a new design in place of the AVR which we have
    > typically used in the past.
    >

    Which ARM and AVR did you compare? At what speed?

    > It may be that in the smaller configurations an AVR can run at much
    > lower power, but if you are comparing apples and not oranges, I think
    > the ARM chips can keep up with most 8 bit parts in terms of power.


    you can make the argument for math intensive applications the ARM can
    execute it much faster, thus only needs to be on for a much smaller
    period so less total power that way, was that how you did the analysis?

    The AVR's also have much better power down and sleep mode currents,
    which may or may not be important for your application.
    steve, Oct 3, 2006
    #19
  20. Miem

    Guest

    , Oct 3, 2006
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Brett
    Replies:
    0
    Views:
    465
    Brett
    Jul 13, 2003
  2. RP Henry
    Replies:
    0
    Views:
    322
    RP Henry
    Jul 14, 2003
  3. Michael
    Replies:
    3
    Views:
    584
  4. Pang Fu
    Replies:
    20
    Views:
    771
    K Mussatt
    Sep 5, 2003
  5. Ilgaz Ocal
    Replies:
    0
    Views:
    1,342
    Ilgaz Ocal
    Jun 5, 2005
Loading...

Share This Page