PIC vs AVR vs ARM
in [Embedded]
|
From: John on 3 Oct 2006 18:17 Hi Issac, In article <1159892751.506769.114790(a)i3g2000cwc.googlegroups.com>, x86asm(a)gmail.com 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? > 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? 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. > 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. 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. John.
From: rickman on 3 Oct 2006 20:14 steve wrote: > 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(a)1.3 Mhz(typical) > Atmel Atmega164 .4mA(a)1.0 Mhz(typical) You are comparing one of the more power hungry ARM chips. Try comparing the SAM7 parts to the ATmega128 which is the comparison we did and found the SAM7 to use less power at a given frequency. You said it well that the AVR would use less power if everything were equal, but everything is not equal. The SAM7 and most of the other ARM parts are a much newer process with 1.8 volt cores. You can even power the cores directly from 1.8 volts while still using the IOs at 3.3 volts to be compatible with other logic. > At higher speeds the ARM's don't have as bad mA/ Mhz ratio > Luminary Micro LM3S101 35mA(a)20 Mhz (typical, running out of SRAM, no > active peripherals) > Analog Devices ARM 7021 33mA(a)41 Mhz(typical) Again, the Luminary parts are in the high power group. In fact, if you check the data sheets you will find there are roughly two groups of ARM7 MCUs when it comes to power. The SAM7 and LPC2xxx parts are about 100 mW at full speed and the rest are mostly over 200 mW full speed. How their power scales with frequency varies so you can't generalize from a single comparison. There are clearly ARM parts available that will beat the ATmega128 that we had been using when it comes to power. > 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? ATmega128 and SAM7S64 at 4 MHz. > > 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? No, the SAM7 chips scale very well with clock speed. > The AVR's also have much better power down and sleep mode currents, > which may or may not be important for your application. Yes, if you are going for a super low power device that spends a lot of time not even running, then the 8 bit micros may be a better choice. But for most applications the ARM chips do just as well if not better.
From: rickman on 3 Oct 2006 20:40 Mike Silva wrote: > rickman wrote: > > 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. > > What do you mean, "a much smaller crystal"? 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? ESR is also important if you are trying to use as small a part as possible. The higher ESR you need, the larger the crystal you will have to use. So when Atmel left the gaps in the table you have to guess which value applies. If you guess one way you will have to use a larger crystal, if you guess the other way your design may not work 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.
From: steve on 3 Oct 2006 20:54 rickman wrote: > > Which ARM and AVR did you compare? At what speed? > > ATmega128 and SAM7S64 at 4 MHz. > Hmm, the PLL on the SAM7 probably takes more current then the entire ATmega128, but I guess you can disable that and run at 4Mhz directly from the crystal, do you remember what is your total current was at 4Mhz on the SAM7 device? steve
From: Isaac Bosompem on 3 Oct 2006 21:01
John wrote: > Hi Issac, > > In article <1159892751.506769.114790(a)i3g2000cwc.googlegroups.com>, > x86asm(a)gmail.com 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 |