I've been working on the process of adding ARM processors to my MCU arsenal. For years, Microchip 8-bit PIC16F and PIC18F processors nave been my processor of choice. I still like them and I'll still keep using them, but I just need more horsepower on enough occasions that it makes sense to look beyond 8-bits. This has led me to explore 32-bit MCUs, and I have settled on the Cortex M0.
There are a fair number of words written on this site regarding the switch from 8 bit to 32 bit. Didier Juges recently covered some of his experiences transitioning from the venerable 8051 to an ARM Cortex-M3.
I myself have looked at a few ARM processors this last year: The NXP LPC1347, on an IAR development board; the Ti Stellaris LM4F120H, on one of their LaunchPad development boards; an NXP LPC1114, on an LPCXpresso development board; and, finally, a Cortex M0, LPC1114FN28/102 in raw chip form. That last one is what really sold me.
Many of the ARM chips are pretty high pin-count devices. That's fine for many applications and not at all a problem when using a development board, but I design a lot of my own hardware. I typically use 20 or 28 pin PIC processors, and have used packages as small as eight pins. My largest pin-count to date was a 44 pin, 8mm x 8mm QFN package which ended up with 10 unused pins. I needed the space that the small QFN afforded though.
The NXP LPC11XX series has 20-pin, 28-pin, 33-pin, and 48-pin varieties of a number of M0 parts, including a DIP28 package that can be easily hand-breadboarded. Once I get more familiar with the chip family, I'll just make PCBs instead of solderless breadboards, but while I'm learning the hardware, that DIP package is saving me a lot of time and money. When I really need to get small, they have a 2mm x 2mm 16 bump BGA variant as well.
Along with the hardware, the CMSIS (Cortex Microcontroller Software Interface Standard) looks to be a pretty big benefit too. In theory, it will ease the transition up and down the Cortex line and even between manufacturers if need be. I'll look closer at that next week.
The JTAG programming system had previously given me a lot of concern, but a few months, ago, in my blog Dealing With JTAG & Internal Clocks, I managed to get an IAR J-Link JTAG interface working. I was still put off by the size of the 20 pin 0.1" connector. That's a lot of board real estate. The LPCXpresso board has a physically smaller JTAG interface, but requires some modifications to the board and a 0.05" pitch 10-pin connector.
That solved my real estate concerns, but it necessitated finding and buying an adapter to hook up to my solderless breadboard. I won't need an adapter once I get to my own PCBs, because I'll use the smaller pin header in my designs, but in the meantime I do need one. CodeRed, the LPCXpresso software vendor, sells one for a reasonable price:
Prior to using the LPCXpresso as a stand-alone JTAG programmer, it needs to be separated from the MCU portion of the board. Fortunately, doing so doesn't ruin the LPCXpresso. It's a three-step process and requires a 20-pin 0.1" header strip and 10 jumpers. After it's done, you place the jumpers on to program the LPCXpresso and remove them to use the JTAG for something else.
First, use a knife to carefully cut along the white line that divides the programmer from the MCU:
Step two involves soldering the 20-pin header strip to cover the row of jumper holes just cut:
And finally, place the 10 jumpers to program the on-board MCU or remove them to program something off-board.
This is my final programming setup, just waiting for the mini-USB cable. I didn't need to make any changes within the CodeRed software IDE. It just recognizes the chip as though it were on the LPCXpresso board. The only changes required to my code were to alter the chip device setting to match this chip and the clock setting to account for the fact that I'm using the internal oscillator.
JTAG still takes up a lot of pins, even with the smaller connector. On this chip, it needs pins 2, 3, 12, and 23. I read someplace that NXP (and maybe ARM in general) has an alternative 2-wire programming and debugging interface, but I don't know anything about it other than the rumor of its possible existence. Have you use the 2-wire programming/debugging interface for an ARM chip? If so, let me know.