Chapter 1: Beginnings
Chapter 2: Further Beginnings
Chapter 3: Hello World
Chapter 4: More On GPIO
Chapter 5: Interrupts
Chapter 6: More On Interrupts
Chapter 7: Timers
Chapter 8: Adding Some Real-World Hardware
Chapter 9: More Timers and Displays
Chapter 10: Buttons and Bouncing
Chapter 11: Button Matrix & Auto Repeating
Chapter 12: Driving WS2812 RGB LEDs
There are 59 messages in this thread.
You are currently looking at messages 11 to 20.
So far in April, you have voted 0 times ou of a total of 0 votes by the community.
Please help us clean the archives from unuseful discussion threads by using the voting system! Details here.
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 >
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 u...@a-t-m-e-l.com This message is intended to be my own personal view and it may or may not be shared by my employer Atmel Nordic AB
Hi Miem, In article <1...@b28g2000cwb.googlegroups.com>, M...@gmail.com 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.
Buddy Smith wrote: > steve <b...@yahoo.com> 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 u...@a-t-m-e-l.com 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 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
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
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.
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 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.
Take a look at: http://www.netburner.com/products/core_modules/mod5213.html For $99.00 a 32 bit dev kit. Faster and more capable than most of the small ARMs. Paul