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!
The ARM info center refers to bit-banding in their Cortex-M3 and -M4 documentation, compiler docs, and a few other places, like Home > Programmers Model > Bit-banding. From Home > Developing software for Cortex-M3 > Bit-banding:
Bit-banding maps a complete word of memory onto a single bit in the
bit-band region. For example, writing to one of the alias words will
set or clear the corresponding bit in the bitband region.
It appears to be a way to get single bit atomic operation.
When writing to the alias regions bit 0 of the 32 bit word is used to
set the value at the bit-banding region. Reading from the alias
address will return the value from the bit-band region in bit 0 and
the other bits will be cleared.
Best Answer
The linker controlled by a link script (not the compiler), places variables and code at specific memory locations. Normally, the linker script does not attempt to place variables or code, within the Bit-band regions.
So, unless you write a liner script to explicitly place something into the bit-band regions' address ranges, the linker will not normally place anything there.
However, those regions are just 'overlays'; bit-banding only provides an alternative address range to access the RAM or peripherals which are already accessible with their own 'real' addresses. The Bit-band regions do not provide any extra storage, just a different access mechanism, so IMHO it is a bit misleading to ask "Or it will stay unused?".
Put another way, the compiler+linker can use all available RAM, irrespective of using Bit-band addresses to access it. Bit-band addressing is only extra addressing hardware.
Bit-band addressing is used to access peripheral registers or RAM as individual bits. This can be very useful to implement atomic bit-access, or faster access to individual bits, for example to control pins connected to ports.
Each Bit-band address contains a 1-bit value. So they are useful for boolean values, but little else.
The easy way to take advantage of bit-band functionality to test or update bits within RAM or peripherals is via C/C++. ARM documentation, and the books by J.Yiu, explain how to exploit bit band addressing; set the value of unsigned int (32 bit) pointer to an address within the bit-band range, e.g.
volatile uint32_t GPIOA_BASE = (uint32_t*) 0x40010800;
(not correct bit-band address)Then any access to memory or peripheral registers via a correctly initialised pointer variable will actually read or write a single bit within the real RAM or peripheral register:
*GPIOA_BASE = 1; // set bit to true