Re: PIC vs AVR vs ARM


John wrote:
Hi Issac,

In article <1159892751.506769.114790@xxxxxxxxxxxxxxxxxxxxxxxxxxx>,
x86asm@xxxxxxxxx says...

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.

You're right, learning all that isn't too horrible, but when you're
getting up to speed on an entirely new part, that's one less thing you
want to worry about.

I am working with the AT91SAM7S256, which is a pretty pleasant chip to
work with.

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). The tradeoffs werent too great I guess. I really did
like working with the 8051, it was quite simple to use and its hardware
and architecture were very well documented. But I figured I would learn
about the ARM since many of you are enthusiastic about it. I'm not a
professional, so I am not involved in any professional work. But let's
just say I am an apprentice ;).

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.

When you re-compile your code, do you have to quit Insight? Are you
using OpenOCD as well?

Yup, I must or else the linker stage of my make file will complain. I
am using the OCDRemote from Macriagor (sp?) and a "Wiggler" compatible
JTAG cable. It is horrendously slow sometimes. I have to close the
local variable view to speed it up. Sometimes that doesnt even work :(.


I find for some reason, arm-elf-gdb opens the main.out (.bin, or
whatever) in a locked read-only mode, so I can't re-compile until I kill
Insight (or whatever is the front-end for gdb). I find that a real
PITA. AVR studio was nice and would pop-up a message saying it noticed
the executable changed and if I wanted to reload the AVR.

I'll admit I havent played with AVR. But it seems like the people doing
their design projects at my school are in love with it (and the PIC,
not surprisingly though since one of our alumni grads works at
Microchip...). They also love the Freescale 56000 series DSPs, they
seem to have simulators for that DSP on the computers.

I did do a brief foray with the AVR Studio some time ago and really
liked the IDE. The simulator was very powerful too. I guess that's why
my peers like it so much.
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).

Well, I tried the MSP430 on a project once and I wasn't blown away by
it. I think the MSP430 niche is "low-power" and all the various
clocking modes it offers. But from a performance perspective, many
instructions are not single-cycle, so the AVR typically runs neck and
neck with it or faster.
Yes it is a more "heavy" RISC chip. Its instruction set somewhat leans
more towards traditional CISC processors. But a plus side I found with
the MSP430 is that the MSPGCC is very simple to use. No startup
initialization is necessary (compiler has startup object files for each
variation of the 430) and all you need to do is plus a special
attribute flag on a function and it will be declared as an ISR and the
vector table will automatically be patched for you. No mess, no
worries.

I like the idea of working with a 16-bit uC, I think that's the perfect
compromise. Since a lot of data one uses in the real world (with A/Ds,
D/As, etc) is more than 8-bits wide it typically fits nicely in 16-bits.
But, I just didn't find the MSP430 to offer too much more than the AVRs.

I will add, I don't think TI has an equivalent to AVR Studio, which
means if you want to do debugging, etc that means something like Rowley
CrossWorks.
My first 8-bit MCU was the PIC, so the MSP430 is a refreshing change. I
found the PIC's to be pretty good for power consumption. The MSP430 has
a better architecture and a free GNU compiler that I can readily use,
it was a no brainer to switch over and use it in my low power projects.


John.

-Isaac

.

Relevant Pages

  • Re: LPC2101-2-3, still preliminary?
    ... Smallest ARM I've seen is TQFP32, there are lots of 8 bit uC in the ... then you may have to live with the 8 bit MCUs. ... saying there is anything wrong with 8 bit chips. ... less and less reason to use them. ...
    (comp.sys.arm)
  • Re: inexpensive way to get into ARM?
    ... > One more question - it seems that the Philips chips are the most ... > primary embedded programming experience is with Atmel AVR ... Is this not the case with ARM devices? ... The Philips ARMs run at nearly 60 MIPS from flash, ...
    (comp.arch.embedded)
  • Re: inexpensive way to get into ARM?
    ... > One more question - it seems that the Philips chips are the most ... > primary embedded programming experience is with Atmel AVR ... Is this not the case with ARM devices? ...
    (comp.arch.embedded)
  • Re: PIC vs AVR vs ARM
    ... In these days it is not to hard to find small, ARM based ready to use ... Can anybody shortly compare ARM with PIC ad AVR interms of ... For the AVR I use CodeVision and I find it to be a very good compiler, ... can almost forget about single-stepping and setting meaningful ...
    (comp.arch.embedded)
  • Re: Hi
    ... Read what I wrote again - I did not say I expect all chips to have ... Some of the ARM Microcontrollers are great parts, ... is that you can use chips with their cores, or you can even use their ... also look at 32 bit FPGA CPUs that also fit better into FPGAs ...
    (comp.sys.arm)