Unlike AVRs, ARMs (Advanced RISC Machine) are produced by a variety of manufacturers and come with different pin counts, I/O options and internal or external memories, but they all share one commonality: They all have a 32-bit ARM processor core (licensed from ARM) which has one standardized ARM instruction set.

Actually, these processors understand two instruction sets: The classic 32-bit ARM instruction set and the more space-efficient 16-bit Thumb instructions. And luckily, since the GNU compiler GCC has support for both these instruction sets, there's a free and high quality compiler available for the ARM architecture!

A lot of people use GNU tools to develop programs for ARMs and while it's not hard to get a copy of windows binaries of the GNU tool chain, it's not so easy find linux binaries. Unfortunately, I don't remember from where I got mine from and it's of course also possible to compile the tools from their respective sources. (The next time I do this, I'll post a description here. Promised!)

In contrast to AVRs, there is no standardized startup code for ARMs (yet). The main reason is that the early initialization is very hardware-specific and therefore different for various processors applying an ARM core. Furthermore, you need custom linter scripts conforming to the product's memory layout. So, it's not as easy as with AVRs although the main steps are the same: After compiling and linking the source code, you get an ELF binary. Using arm-elf-objdump, the binary flash content is extrancted and uploaded onto the program flash (which can either be integrated into the microcontroller or external). Uploading itself can be accomplished via the microcontroller's JTAG interface, a suitable JTAG cable (e.g. my USB-AtmelPrg cable) and host computer support, e.g. OpenOCD.

This is how to get started: A complete example including a hello-world progam and all that is required to get it running on a highly-integrated AT91SAM7 is presented on the AT91SAM7 introduction page.

Most modern ARM processors and microcontrollers come with a JTAG port and include an on-chip debugger (OCD). This OCD allows to halt execution, examine memory and register contents, set breakpoints and so on, all that on the real microcontroller in its real-life environment. There's no need for in-circuit emulators any more! Sounds pretty cool and involves several things to work together:

1. Debugging is done with the GNU debugger (GDB). Maybe you want to work with a graphical interface like Eclipse but this will still use GDB in the background.
2. For all target operations, the GNU debugger talks to a special daemon program which translates debugger commands (like memory access, etc.) into JTAG waveforms. Therefore, you can use OpenOCD which usually listens to the TCP port 3333 for GDB connections.
3. The ARM processor has a JTAG port, so you need special JTAG hardware (like e.g. my self-built USB-AtmelPrg cable) to connect the ARM to your host computer (e.g. via a USB port). OpenOCD translates the debugger commands into JTAG waveforms and supports a variety of JTAG cables. An OpenOCD-patch for support of my USB-AtmelPrg cable is available here.

• AT91SAM7 Introduction: This is how to get started, including a hello-world program.
• STM32 Introduction: STM32 (F2, F4) development under linux from scratch!