8/14/2019 msg00163

1/3

8/14/2019 msg00163

2/3

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 mymajor 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 ARM7TDMI devices is they only have two hardware breakpoints. So

if you want to singlestep your code which is in Flash, that requires

both hardware breakpoints. If you're using any open source tools, you

can almost forget about singlestepping 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 runtime files (crt0.s), assembly initalization

code, linker scripts and other things. Thank fully the LPC2000 forum at

Yahoo has some preexiting 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 usingthe "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 singlestepping takes 45 seconds per step! The

AVR setup singlesteps 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.

Re: PIC vs AVR vs ARM

Re: PIC vs AVR vs ARM 2

8/14/2019 msg00163

3/3

So, on paper using one of these ultracheap 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, tothe 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.

.

Re: PIC vs AVR vs ARM

Re: PIC vs AVR vs ARM 3