Almost every design that leaves my desk has a microcontroller in it, and basically everything I’ve worked on over the last two years has used ARM microcontrollers. These can be quite overwhelming to get started with, so I wanted to write a blog post about what ARM microcontrollers are (and aren’t), and what’s out there in terms of development boards and tools. There are lots of tutorials covering specific ARM microcontrollers, but I wanted to operate more broadly, and explain what exactly is out there, and what you need to get started.
Unless you’ve been sleeping under a rock for the last half-decade, you’ve probably heard of the mass migration to ARM microcontrollers. Why? Before we get into too many details, let’s start by comparing the ATMega328 (of Arduino fame) to two arbitrarily-selected entry-level ARM microcontrollers — the Freescale KL05MK32, and the Nuvoton NUC123:
|Feature||Atmel ATMega328||Freescale KL05||Nuvoton NUC123|
|Speed||20 MHz||48 MHz||72 MHz|
|Program Memory||32 kB||32 kB||68 kB|
|RAM||2 kB||4 kB||20 kB|
|ADC resolution||10 bit||12 bit||10 bit|
|Timers||two 8-bit||eight 16-bit||four 32-bit|
|PWM channels||6 (8-bit)||6 (16-bit)||4 (16-bit)|
As you can see, the Freescale KL05 has a similar feature set (with expanded analog capabilities), while being much faster (and cheaper!) than the ATMega328. The Nuvoton NUC123 operates much faster than either the KL05 or the ATmega, and contains more connectivity, including USB and I2S (for interfacing with audio codecs), and costs only a bit more than the ATMega328.
This is a general trend that’s been happening for several years now. At the end of the day, ARM microcontrollers are generally cheaper and faster than their 8-bit counterparts, while offering some other key advantages we’ll see.
What is ARM?
ARM is a British semiconductor (and software) design company that designs and licenses ARM processor cores to semiconductor manufacturers. Unlike a company like Texas Instruments, which designs the core processor (the MSP430), and manufacturers it into a microcontroller (MSP430F2268 as an example), ARM does not actually sell chips — heck, they don’t even sell microcontroller designs; they just sell the ARM core. Other manufacturers license the core from them, and then design microcontrollers around that core by adding in peripherals and memory to suit their design goals.
There are different cores for different applications. For general microcontroller development, you’ll probably be using a Cortex-M0/M0+, Cortex-M3, or Cortex-M4. Yes, they get better as the number gets bigger. The M4, for example, has a floating-point unit and can operate at over 150 MHz.
How are ARM microcontrollers different from 8-bit microcontrollers?
The ARM core itself is quite a bit different from many 8-bit cores — but I won’t get into the specifics of the CPU in this post4. The main thing that I noticed, as a developer, is how different the development process it.
I got into microcontroller development before the Arduino wave happened and consequently built a lot of projects around the Microchip PIC MCUs, using Microchip’s MPLAB as an IDE, their compiler, and their PicKit as a programmer/debugger. The Microchip ecosystem is entirely proprietary — you buy their microcontrollers, which use their cores, and you develop using their IDE, their compilers, and their debuggers.5
In general, this is a really nice way of doing things. You know everything will work together, since it’s all made by the same company.
Developing for ARM is totally different in that you have a ton of options for how to proceed. You need to be conscious of how embedded designs are developed. To do any development, you’ll need:
- A target — this is the board that contains the microcontroller you’re going to program. This may be a development board and/or a custom-designed board that contains the peripherals you need. It may also just be a simple solderless breadboard.
- A toolchain — this is the software you use to write and debug your code. Most developers use an IDE — integrated development environment — which contains a text editor, plus functionality for compiling and downloading your programs to the target. Having said that, some developers still prefer to run commands manually — they write code in a text editor, compile it manually, and then download it to the target using another command or program.
- A debugger — this is the device that connects the computer to the microcontroller to download code to it, as well as set breakpoints, inspect memory, transmit/receive trace information, etc. Many development boards come with an on-board debugger.
First, let’s look at some off-the-shelf development boards that you can buy. For the purpose of this post, I’m going to look at low-cost ready-to-roll boards that have on-board USB debuggers. These boards make getting started super simple.
STMicroelectronics makes some nice higher-end Cortex processors (I’ve found that their lower-end Cortex-M0 processors aren’t very competitively priced); their STM32F4 processors have been especially popular in the development community because of the shear capabilities of the device. While not inexpensive, the STM32F4 can basically do anything you’d ever do with a microcontroller, so once you learn how to program it, you can do anything from audio DSP work to TFT LCD graphical development, to hard core signal processing / control work.
The STM32F-series Discovery boards are small development boards with built-in STLink debuggers that let you get started really quickly. These boards are pretty bare-bones. The lower-end boards don’t have anything other than a few LEDs and pushbutton switches; the higher-end boards have more peripherals soldered on.
One thing I love about these boards is how easy it is to hook the on-board debugger up to an external target. All you have to do is remove the two ST-Link jumpers, and wire a cable from the 6-pin header to your custom board, and you’re set.
One interesting feature of the STM32F microcontrollers themselves (regardless of what board they’re soldered onto) is that they also have built-in, permanently-burned-in bootloaders. The STM32F4’s bootloader operates on the USB or USART0 connection, while the other boards’ bootloaders operate on the USART0 connection. This means that you can update your target’s firmware in the field without having to mess with writing your own bootloader — just short the “LDD” pin to ground and restart the processor. It will automatically instantiate itself as a USB device and accept new firmware using ST’s DFU software.
Here’s a table of all the boards in the family:
|Board||Processor||Core||Approx. Price / DigiKey Link|
ST, like many manufacturers, makes the low-cost development kit for these processors at a loss6.
Freescale FRDM boards
While ST has been widely successful with their higher-end Cortex-M3 and -M4 processors, Freescale’s ARM Cortex portfolio really concentrates on entry-level 8-bit replacements. Their parts are extremely cost-sensitive (most costing about half of what a typical Atmel microcontroller costs). Their FRDM boards are a line of bare-bones development boards with built-in debuggers. These are very similar to the STM32 Discovery boards, and cost about the same (though the Discovery boards are slightly cheaper).
The onboard debugger is quite strange. From the factory, it comes with firmware on it that instantiates as a USB Mass Storage Device (MSD) — think USB flash drive. Any binary program you drag onto the flash drive will get uploaded to the processor. It’s kind of interesting, but not particularly useful (since you can’t debug using it). Luckily, the OpenSDA debugger, itself, has a USB MSC bootloader (I know, it’s convoluted). When you plug in the device to your computer while holding down the reset button on the board, it will trigger the OpenSDA debugger to go into firmware update mode — you then copy alternative “debugger” firmware onto “drive”, unplug it, and plug it back in. This time, it will instantiate as an OpenSDA debugger, which you can then connect to.
Just like the Discovery boards, you can use the on-board OpenSDA debugger to connect to a custom target board, however, some of the revisions of some of the boards have bugs on them that force you to hack the board apart a bit to get off-board debugging working.7
|Board||Processor||Core||Approx. Price / DigiKey Link|
Texas Instruments LaunchPad
TI has two boards from their LaunchPad line that break out the pins on their Cortex-M4 microcontrollers. Their processors — the older Stellaris brand, and the new Tiva name — are built to be DSP killers; they’ve got tons of timers/PWM channels, good-quality 1 MSPS 12-bit ADCs, and plenty of flash memory.
|Board||Processor||Core||Approx. Price / DigiKey Link|
Note that the DigiKey price for the Tiva LaunchPad is outrageous. It can be purchased from the TI eStore for $12.99.
Atmel doesn’t have any super-low-cost development boards for their ARM portfolio. The cheapest thing out there is the ATSAM4S-XPLD, which is more than $30 at DigiKey. It’s sort of a strange board — it has a capacitive-touch strip, a single button and two user LEDs. It also has external SRAM and flash memory. Only a few pins are broken out for auxiliary use. One major feature this board has is a J-Link-compatible debugger built-in.
NXP has several low-cost development boards with on-board USB debuggers as part of their LPCXpresso line. These boards typically have few, if any peripherals — they’re mostly made to breadboard with, I believe. They’re also all about twice as expensive as the ST/Freescale boards. One nifty thing about these boards is that they’re designed to support separating the LPC-Link debugger from the target. The link between the two is a single row of 0.1″ spaced headers, so, once separated, the LPC-Link can plug directly into a breadboard. There’s also a 2×10 header that you can use to connect a cable between the LPC-Link and a custom board.
|Board||Processor||Core||Approx. Price / DigiKey Link|
Debuggers have traditionally been extremely expensive pieces of hardware (sometimes costing thousands of dollars). With the proliferation of high-speed USB, it became easier to implement debugging in software using low-cost microcontrollers. As we’ve seen, many development boards have debuggers built-in — and with a little bit of fiddling around, you can usually use these debuggers on custom targets. But these debuggers usually only support the manufacturer’s chips (and may not even support chips from different families — even if they’re made by the same manufacturer). Third party debuggers are popular because they “just work” — with any MCU — and they’re extremely fast. The most popular one is Segger’s J-Link. The commercial version is almost $320, but there’s a non-commercial educational version available for about $60. I’ve found the J-link to be several times faster than other debugging adapters when it comes to flash download, stepping through code, setting break-points, etc. It’s also universally supported by basically every IDE out there — either natively, or through their GDB server. It should also be mentioned that most of the “embedded” debuggers on the development boards I’ve mentioned come in (much more expensive) stand-alone versions, which may have more functionality than the embedded versions.
Choosing a Toolchain
Now, let’s look at the IDE/Compiler choices. There are basically three options to go to for toolchains/IDEs: vendor, third-party, and rolling your own. Almost all toolchains are Windows-only, so if you’re trying to get started with embedded design, you should probably think about getting Windows installed on a partition — your options for OS X or Linux/FreeBSD/et cetera are very limited.
This is probably the easiest way to start out — and it will be most familiar to those who have worked with 8-bit proprietary microcontrollers before. It’s simple: you pick an ARM microcontroller built by a company that has an in-house IDE/toolchain, like Texas Instruments, Freescale, NXP or Atmel, and then you use their software. These toolchains/IDEs tend to be rather expensive, but they almost always have a free code-size-limited version available.
Atmel Studio is the only vendor toolchain that is completely free, without restriction. It’s built around a Visual Studio interface that’s been highly customized for embedded development. They have an online code repository containing a runtime HAL API for all their processors, as well as many reusable software components. They have tons of examples to get started with.
Texas Instruments Code Composer Studio
TI’s in-house toolchain is Code Composer Studio. It’s an Eclipse-based IDE with TI’s proprietary ARM compiler they acquired from Luminary Micro (along with their Stellaris portfolio). TI licenses the software slightly differently from other companies — you can install a 30-day evaluation license, which allows you to target any processor with any debugger — or, you can activate the free license. Unlike other manufacturers that put code-size limits on the free tier, TI puts debugger restrictions: the free license can only be used with an embedded XDS100 emulator (like what’s on their Launchpad boards), and there’s no code-size limit.
TI has a ton of examples and app notes, but Code Composer Studio is pretty bare-bones; there’s no online software repository or GUI configurators built-in.8
Freescale makes an Eclipse-based IDE named CodeWarrior. CodeWarrior’s claim to fame is its Processor Expert feature, and it’s totally awesome. The most time-consuming part of embedded programming is getting hardware peripherals and software blocks initialized and working. Once that’s working, many projects’ main() function is simply some glue code to respond to hardware interrupts, do some simple data processing, and other babysitting duties. Processor Expert dramatically speeds up development by automating all the tedious hardware initializing. Using the Processor Expert GUI, you select the sorts of peripherals you need, add them to your project, and configure them using a properties pane interface.
Once you’re done, Processor Expert will generate optimized C code for you, based on your peripheral configuration. This has some major advantages when compared to a runtime HAL (something like Arduino) in that you can operate at whatever level you want to. Let’s say you want to add PWM functionality to a project. In Processor Expert, you add a PWM module to your project, and then configure it with the period and duty cycle you’d like (you can specify these values in real-world units like microseconds or kHz — PE will figure out all the timer configurations based on your clock settings). Most of the default values will be suitable for most designs, but if you want to get in there and muck around with selecting certain timers, or changing the output polarity or things like that, you have the ability to do that using the properties pane. And, if you *really* want to get hardcore, there’s a register view as well that lets you modify the actual peripheral registers, in case you’re doing something exotic.
NXP bought Code Red
a few years ago in May9, and they release a special code-size-limited version of Red Suite for their LPC processors for free. They’ve renamed this version LPCXpresso. This version supports up to 128 kB10 download limit after free registration (this is quite generous — most ARM projects I work on fit inside a 32 kB MCU).
In addition to vendor toolchains, there are several third-party development tools, including Keil UVision11, IAR Embedded Workbench for ARM, TASKING VX-Toolset (made by Altium), TrueSTUDIO from Atollic, Code Red’s Red Suite, and Rowley’s CrossWorks for ARM. These are all fairly expensive software packages, but, just like the vendor tools, may have free code-limited versions. All of these tools are designed to work with ARM microcontrollers from a wide variety of vendors. That’s the real advantage these programs have over the vendor tools: once you learn how to use one of these IDEs, you can develop for any ARM microcontroller out there — no matter who makes it.
Of these packages, Keil UVision is probably the best. It uses the MDK-ARM compiler (directly from ARM), and generates, by far, the best-performing code. It’s insanely expensive (like, $5000), but they also have huge educational discounts (our lab’s license only cost us $500). Keil UVision is kind of clunky as an IDE, but Keil also ships the product with an Eclipse plug-in that works quite nicely.
One thing to note about CrossWorks by Rowley — it’s the only out-of-the-box toolchain I could find that supports OS X and Linux. I’ve used it before, and it’s alright — but there are no free code-size-limited versions available (only a 30-day evaluation). Personal, non-commercial licenses are $150. Educational licenses are $300, and Commercial licenses are $1500. If you’re on OS X or Linux and you want to buy something ready-to-roll, this is your only option.
There’s really only one completely free third-party toolchain: CoIDE. CoIDE, made by CooCox, is a stripped-down version of Eclipse that has been heavily-modified for embedded development. It has a software repository built-in, which provides runtime peripheral drivers for several different processors. It’s not nearly as nice as CodeWarrior or Atmel Studio, and some of the peripheral driver packages are better than others (hey, it’s open source — what do you expect?), but considering it’s completely free, and supports the most popular ARM development boards, it’s hard to complain about it.
As you can see, there’s a lot of stuff out there, so there are a ton of different ways you can get started developing on ARM. I have experience with most of the tools and products I’ve mentioned in this blog post, and people always ask me what I think they should learn. It really depends on who you are and what you’re trying to do. Here are some recommendations:
- If you’ve done a lot of embedded programming, you’re comfortable with the internals of a microcontroller, and you just want to get the job done, I’d recommend looking at CodeWarrior plus one of the FRDM boards. Freescale’s microcontroller portfolio is priced insanely cheap (and the prices drop off pretty quickly, too), so professional embedded developers (or just cheap-skate hobbyists) will find their portfolio enticing. The environment is a little funky to set up, but Processor Expert dramatically reduces the amount of time you spend configuring peripherals. And, let’s face it, the more advanced you get, the more you’re using peripherals, DMA, and custom oscillator/clocking functionality (and the less likely it’ll be that you can find a cute runtime HAL that does what you need it to do). CodeWarrior will get your project moving quickly, while still allowing advanced control you can take advantage of later down the road.
- If you need to do some high-end work (especially with UIs), you should check out the STM32F4Discovery. It’s really designed to sit in that gray area between microcontrollers and embedded Linux-powered microprocessors. CooCox’s CoIDE has excellent support for the STM32F4Discovery if you’re looking for a free toolchain; otherwise, choose one of the other third-party toolchains. You’ll spend a bit more time getting things set-up and running, and you’ll develop a love/hate relationship for the CMSIS peripheral API, but all-in-all, it’s going to be your best bet for high-performance stuff. You can also put .NET Micro Framework on the board and develop in C#. There’s a lot of options.
- If you want a good starter platform, especially for educational purposes, I’d actually recommend the NXP LPCXpresso boards over the FRDM or STM Discovery boards. On the hardware side, the LPCXpresso boards are the most breadboard-friendly of anything out there. Once you score and cut the board, you’ll have a lovely little debugger that you can easily plug directly into a breadboard. NXP is the only company I know of that makes DIP-package ARM chips. This is extremely useful for engineering education, where we avoid giving the students big, complicated PCB-based development kits (the abstraction of the PCB gets in the way of understanding concepts).
If you want a more concrete introduction to developing for ARM, check out this LPCXpresso tutorial I wrote. I think it does a decent job of walking the reader through a project, while explaining why things need to be done the way they’re done. I hope you learned some stuff! Let me know if you have any questions in the comments!
This is a relatively good brief overview of the ARM architecture — though it is a bit dated: http://web.eecs.umich.edu/~prabal/teaching/eecs373-f10/readings/ARM_Architecture_Overview.pdf ↩
Obviously, there are third-party tools available, like the CCS compiler, the SDCC compiler, and various programmers, but these are not widely used. ↩
As an example, the STM32F407 that’s populated on the STM32F4Discovery costs almost $10 in single quantities, yet the entire board is less than $15 ↩
This entire blog is extremely helpful for working with the FRDM boards, but this post specifically is useful to getting it working with off-board targets: http://mcuoneclipse.com/2013/04/27/debug-external-processors-with-usbdm-and-freedom-board/ ↩
TI’s excellent GRACE tool only supports their MSP430 line of processors ↩
Thanks for the tip, Erich! He’s got more info here: http://mcuoneclipse.com/2013/04/20/red-suite-5-eclipse-juno-processor-expert-and-unlimited-frdm-kl25z/ ↩
Or maybe 256 kB? That’s what my version says after I activate it, although official documentation says 128 kB ↩
Keil is actually owned and operated by ARM now ↩