They come with a free license for code_red's customized version of Eclipse with support for firmware up to 128KB. It's apparently also possible to cobble together an fully-OSS toolchain, but I haven't tried yet.
Recipe for an open source, GCC-based ARM toolchain:
-GCC
-Newlib (an implementation of the C standard library aimed at embedded systems)
-Binutils
-GDB (optional; great if you pick up a jtag debugger and openOCD)
I pushed out a cross-compiler via this recipe that survived an entire semester of usage in labs along with an ARM Cortex-M3 board.
No limitations on RAM usage, full optimizations available. As far as I've seen, GCC does a nice job using the ARM thumb2 instruction set when you enable optimizations.
I felt compelled to put together my own linker script; one of the more painful parts. I'm not sure if the default linker script will work or not.
I've been meaning to put this toolchain recipe online somewhere, along with a tool I put together for flashing the GCC-produced executables to the Cortex-M3 via USB DFU.
- CMSIS for your part should already come with a binutils compatible linker scripts. The three I use (ST, NXP, Energy Micro) all come with them already. Obviously you'll need to modify the script if you're rolling your own bootloader or similar, but it should work otherwise.
- I like defaulting to the CodeSourcery G++-Lite toolchain. Its also ARM, Thumb, Thumb2 multilib capable for non CM3 parts (like ARM7/ARM9).
- USB DFU is not universal. NXP has cool idea (mass storage device, though buggy when used with Linux without mtools). ST's version kinda sucks (try cribbing from the Maple code maybe). No idea on Atmel.
I mostly just wanted to roll my own cross compiler, plus it was easier (for me) to distribute to the network machines that way.
USB DFU is a device class specified by the USB standard. I like the idea of following a standard more than getting locked in to a company because I have only implemented their bootloader protocol.
I've been using the STM32 series Cortex-M3's, and unfortunately ST puts it's own little layer ("DFUSE") on top of DFU.
It would be nice if these companies would just go ahead and conform to some bootloader protocol (USB DFU!) so developers can stop wasting time there trying to talk to boards.
I agree on the bootloader front. I wish they would just settle on a single implementation. NXP's version is however useful, since it requires no tools to operate (delete file from "disk", copy new file to "disk").
http://ics.nxp.com/lpcxpresso/ http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&...
They come with a free license for code_red's customized version of Eclipse with support for firmware up to 128KB. It's apparently also possible to cobble together an fully-OSS toolchain, but I haven't tried yet.