Electronic – What are the things to watch out for when switching from AVRs to Cortex M3

May as well copy the best responses from a relevant AVRFreaks thread: http://goo.gl/Yv2aa

Q: (toalan)

I just got my ARM cortex M3 dev board. I was able to compile and debug a simple example program. I read through the datasheet a bit. Everything looks really good, almost too good. Are there any landmines that I should be aware of?

A: (toalan)

I tried using ARM GCC, but there are so many things to configure and the IDE for it was like a flashback from the early 90's.

Currently I use an evalutation copy of Keil, and I bought a Ulink debugger clone from ebay for $50. Ulink is the official Keil debugger. Ulink2 is out now, you can pickup a clone on ebay for $100. I read that Ulink1 can not debug cortex, but mine seems to work for cortex.

Also I find that the datasheet for Cortex is much better than the ARM7 datasheet. This is because typically for ARM there is 1 super huge datasheet that covers a large number of ARM7 devices and you have to figure out what sections apply to what ARM7 uC. There are not many Cortex devices on the market yet, so it is easier to figure which section applies to which Cortex uC.

I spent in total about 4 hours to install the software and debug my first program. It was a night a day difference from my frustration with ARM7.

I got this board from futurlec, http://www.futurlec.com/STM32_Development_Board.shtml

A: (leon_heller)

I built my own LPC2106 board when the chip first came out. I downloaded gcc for the ARM, got it working in a few minutes, and wrote a simple test program for my hardware.

I now use Rowley CrossWorks for LPC2000 ARM7 development. The compiler is gcc, with their own libraries, with their excellent IDE.

A: (Thomas Strand)

GCC always works right away. But I think OpenOCD (for flash writing and debugging) is a mess. Configuration files and scripts all over the place.

When it coms to IDE's, I think it's hard to beat Eclipse. Granted, it is a bit daunting at first, but I went through a setup tutorial and got comfortable with it.

Eclipse has some nice features I like:
- Macro expansion on mouseover
- Function implementation popup on mouseover
- Refactoring

A: (jesper)

clawson wrote:

but on ARM7 TDMI parallel I/O is slower

You mean on an Atmel SAM7 using an ARM7TDMI the I/O is slower? I/O is slower on all ARM7's because of the internal bus structure, pipeline breaks e.t.c. For instance, the code

while (1) {
PORTX = 1;
PORTX = 0;
}
on a 90 MHz ARM7 (Philips LPC series), creates a frequency of about 3.5 MHz on the I/O port. An AVR would create about fCLK/4.

It IS possible to get OCD to (sorta) work, however you'll have about as much hair as me when you get it work reasonably. Getting it to work reliably, is probably impossible.

A: (jesper)

clawson wrote:

Are you aware that the LPC also has "fast IO"? The following diagram (8-17) from the LPC 2101/2102/2103 User manual shows the difference between traditional slow IO and the fast IO. This is on a chip with the PLL running at 60MHz. It's true the 4.26MHz from a 60MHz clock is a bit sad. But the 15.4mHz ain't too shabby.

Aha, this is new since I used the LPC's. But it seems it's only the 2101/2102/2103 that has this special feature. I didn't read the DS about it, but if there's no special limitations in using it, it sure is very useful. However, the 15.4 MHz above is probably from four consecutive instructions, set/clear/set/clear or something like that. But it a loop the effect of a broken pipeline may make it may be slower. Can't remember exactly how much the penalty is.

The second link leads to a 26-page long dialogue concerning ARM. I'll read it later!