PIC vs AVR vs ARM

What do you mean, "a much smaller crystal"?

Reply to
Mike Silva
Loading thread data ...

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.

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?

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.

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.

Reply to
John

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.

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.

ATmega128 and SAM7S64 at 4 MHz.

No, the SAM7 chips scale very well with clock speed.

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.

Reply to
rickman

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.

Reply to
rickman

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

Reply to
steve

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

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

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.

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.

-Isaac

Reply to
Isaac Bosompem

"rickman" skrev i meddelandet news: snipped-for-privacy@k70g2000cwa.googlegroups.com...

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.

--
Best Regards,
Ulf Samuelsson
 Click to see the full signature
Reply to
Ulf Samuelsson

Hear, Hear :-)

I attended an Eclipse Seminar, and 1GB RAM is minimum and many need 2 GB to run properly.

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

--
Best Regards,
Ulf Samuelsson
 Click to see the full signature
Reply to
Ulf Samuelsson

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
 Click to see the full signature
Reply to
Ulf Samuelsson

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

--
Best Regards,
Ulf Samuelsson
 Click to see the full signature
Reply to
Ulf Samuelsson

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

And adjust it with voltage and temperature.

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.

Reply to
linnix

1GB minimum?! haha, not even my games( circa late 2005 games too!) need that much RAM! Well that is the amount of RAM I have in my system.

-Isaac

Reply to
Isaac Bosompem

Disclaimer, I work for Atmel and have unbiased opinions :-)

--
Best Regards,
Ulf Samuelsson
 Click to see the full signature
Reply to
Ulf Samuelsson

And whether this is significant depends on the application. The AVR could be ten orders of magnatude better than the ARM in sleep mode, but if the active mode power is 90% of your power budget, the sleep mode will not have much of an impact on total power.

As I said, depending on your application this may be important. If you are designing a data logger where it is asleep for two weeks and then is triggered to record something for a few seconds, sleep mode power may be important. But this is a very small percentage of applications.

And the R/C oscillator is only useful in a small percentage of applications where you don't need any more timing precision than what is required to run a UART, and just barely that!

Yep, in the small percentage of apps where you need the unique features of an 8 bit MCU tailored to low power when it is not running, then it can do a good job. But most MCU apps run the MCU a fair percentage of the time if not 100%. In those apps the power is dominated by the active current and the ARM can beat the AVR there.

Reply to
rickman

My experience is that it does not really matter which core to select. All brands offer approximately same performance for the similar price. What does matter when selecting the MCU is if it has the peripherals needed by the application.

ARMs are mainly the CPUs rather then the MCUs. AVR peripherals are only fair. PIC peripherals are great, albeit the PIC core is disgusting.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

formatting link

Reply to
Vladimir Vassilevsky

"Ulf Samuelsson" writes: [snip]

Good gawd, Gertie! What were the implementors using for brains (presuming they had any)? The bloated size and user testimonial above indicates that the implementors have the intelligent level of a rock.

Reply to
Everett M. Greene

... snip ...

A UART needs much better precision (and stability) than you can expect from any r/c oscillator.

--
 Some informative links:
Reply to
CBFalconer

Yes, from what I've read you only got an error margin of 1 or 2%. Not too big if you ask me. (I got this from the Intersil 82C52 datasheet).

-Isaac

Reply to
Isaac Bosompem

Assume a byte is 10 bits long (one start, one stop, no parity). If we sample the bits in the middle of where we think they are, then by the end of the byte we can be off by just under half a bit and still read correctly. This looks like about 5% to me.

I wonder how exactly they arrive at 1% or 2%; do you know?

I've used the internal oscillator on an AVR and it usually worked (except when it didn't, of course); good enough if it was only to be used for debugging and turned off in the final product.

Reply to
Terran Melconian

Search for Dallas/Maxim's app note 2141, "Determining Clock Accuracy Requirements for UART Communications"

--
John W. Temples, III
Reply to
John Temples

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.