Too Many ARMs!
While I’ve been working on my USB-to-ADB converter with a PIC32, I’ve received a steady barrage of feedback saying I ought to consider an ARM Cortex-M microcontroller instead. There are several reasons I haven’t done that, but one of the biggest reasons is that there are simply too many ARM options for me to keep them all straight! Everyone knows what an AVR is, or a PIC, but my mind is a gray blur when it comes to the various LPC, MSP, and XYZ microcontroller offerings based on ARM cores. While having so many ARM options is good from a price competition standpoint, I have to believe this fracturing of the ARM Cortex-M segment hurts it in its competition with AVRs and PICs. If there were only a single big player making and promoting ARM Cortex-M microcontrollers, I suspect they would have made bigger inroads against Atmel and Microchip.
To help clear the mental fog, I decided to make a list of all the ARM Cortex-M microcontroller families I could name off the top of my head, plus any that have been mentioned here recently by commenters. This isn’t meant to be an exhaustive list, but just the options that are mostly likely to be of interest to hobbyists. I did 10 minutes of research into each one, to find some basic info on distinguishing features and pricing. Maybe this will help you, as it helped me. Pricing is Digikey’s lowest listed price for a device with at least 128K of program Flash memory, in a hobbyist-friendly package (no BGA or QFN), and in single unit quantities.
SAMD (Atmel) – ATSAMD20E17A-AU $3.44, ATSAMD21E17A-AU $3.65. ARM Cortex-M0+. Speeds to 48 MHz. 16K RAM. SAMD20 supports USB Device. SAMD21 supports USB Device and Host. A larger version of the SAMD21 is used in the Arduino Zero.
STM32 (ST Microelectronics) – STM32F070CBT6 $2.66. ARM Cortex-M0. This chip runs at 48 MHz, while others in the STM32 family support speeds to 120 MHz. Supports USB Device. STM32L0 family is Cortex-M0+, STM32F1 and STM32F2 families are Cortex-M3. I did a review of an STM32F1 board a few years ago.
MSP (Texas Instruments) – It turns out this isn’t a 32-bit ARM Cortex-M, but a 16-bit microcontroller based on something called CPUXV2. I’m not sure how it got into the ARM part of my brain.
Launchpad (Texas Instruments) – This isn’t a microcontroller at all, but a series of development boards based on the various TI parts. More brain pollution.
Stellaris (Texas Instruments) – A family of higher-end ARM Cortex-M3 microcontrollers priced at $6.50 and up. This is probably not what I’m looking for, but it’s impressive how well TI’s marketing department has infected my brain with their brands. Does TI actually make a low-end ARM Cortex-M microcontroller? I couldn’t find one.
LPC (NXP) – LPC11E67JBD48E, $4.30. ARM Cortex-M0+. 50 MHz. 20K RAM. Other members of the LPC family are Cortex-M0 and Cortex-M3, with speeds up to 200 MHz.
Kinetis (Freescale) – MKL16Z256VLH4, $4.05. ARM Cortex-M0+. 48 MHz. This device actually has 256K Flash and 32K RAM. Smaller Kinetis devices with 128K Flash are available, but are only offered in QFN packages.
PSoC (Cypress Semiconductor) – CY8C5267AXI-LP051, $6.50. ARM Cortex-M3. PSoC 5 @ 67 MHz. 32K RAM. The PSoC 4 is a Cortex-M0 device and also worth considering, but the models with 128K+ program Flash memory are only offered in QFN packages. The interesting thing about the PSoC 4 and 5 families is that they include configurable logic blocks in addition to the standard CPU core and peripherals. It’s like having a tightly-integrated CPLD built into the microcontroller.
Wikipedia has a small reference table that describes some of the differences between the M0, M0+, and M3 cores.
Suggestion to semiconductor manufacturers: if you want to sell a line of microcontrollers that people will actually remember, give it a pronounceable name, instead of some random acronym. Only TI and Freescale did this.
Software and Tools
OK, maybe that list wasn’t too enlightening, other than to identify the major players. If I’m choosing a microcontroller family to invest time in learning, I’m probably less interested in a $0.60 price difference or 4K of extra RAM, and more interested in the quality of the vendor tools, documentation, peripheral libraries, and examples. I’ll also be interested in the availability of low-cost development boards, and the size of the developer community. How do the options listed above compare in those respects? Who’s got a nifty extra feature, like a built-in bootloader, or some cool hardware peripheral, or a software library that doesn’t suck? Leave a comment and tell me your experiences.
The “elephant in the room” when it comes to ARM Cortex-M development is setting up the toolchain. I described this in my old STM32 review, and it wasn’t a fun process, but that was four years ago. Maybe things have gotten better since then? I know some people are perfectly comfortable installing Eclipse along with a plugin from here, a compiler and linker from there, and a debugger from some other place. Personally I’d rather use an IDE that has as many pieces as possible bundled together, so I can skip the setup and spend more time working on my actual project. Since my earlier review, CooCox seems to have remained popular, and something new called Em:Blocks has also grown in popularity, but most people appear to still be rolling their own toolchain.
Read 15 comments and join the conversation15 Comments so far
Leave a reply. For customer support issues, please use the Customer Support link instead of writing comments.
For simple tasks I use Stellaris (now Tiva C) board. Simple to begin programming (free CSS Eclipse based IDE), good SDK (compared to ST crappy one) and quite powerful board (100+ MHz Cortex M4). I don’t know how availability of this parts look like (TM4C chips).
ST has many different types of easly available chips, but comes with no free preconfigured IDE and as I mentioned their standard library (and docs) sucks. Maybe libopencm3 is a way to go? (https://github.com/libopencm3/libopencm3)
To make things more confusing, Texas Instruments makes an “MSP432” MCU that is a 32-bit Cortex-M4 derivative.
The MSP430 is indeed a proprietary 16-bit chipset.
I tend to use ChibiStudio for things that need realtime (even if I’m just using HAL and not RT) and arduino for things that don’t (teensyduino or other hardware bsps that plug into arduino are now available)
To confuse things further, it seems that Freescale and NXP merged a few months ago. I’m not sure what that means for the LPC and Kinetis families.
I’ve been using LPC812 chips as my new “small, simple microcontroller” option in lots of recent projects. Its internal design is a little different than some of the “larger” chips in the LPC family, and it is available in SOIC packaging that I find a nice compromise between size and ease of quickly hand-soldering for prototypes. It has a switch matrix that allows almost complete freedom in mapping the many functions to the limited number of pins, so each project can use a different subset.
I don’t really use IDEs so I can’t really comment on that front, but I am using a pretty common arm-none-eabi toolchain (gcc-arm-embedded) along with a lightweight unofficial C library (really just a header with some constant pointers in it) and the open source lpc21isp tool to upload code to it via is bootloader.
I’m using STM32f for my projects. I just picked one line at random mostly because I saw lots of projects like this http://andybrown.me.uk/2015/10/31/stm32f042dev/ which made me think I could make it work 🙂
I use the em:blocks compiler install, (Well the latest version seems to be called embitz for some reason)and find it “just works” including on chip debugging and everything. Very painless experience.
I’ve not tried using vendor libraries for things like USB though. I expect they are painful like everything else 🙂
I haven’t looked at pricing or availability, but I was considering my own project with USB host a little while ago. I’d decided on a dedicated host controller such as http://www.cypress.com/products/sl811hs, and an AVR as the MCU. There a a number of controllers with 8 bit or SPI buses on the market – would allowing one of these to do the USB heavy lifting and sticking with a simple micro be an alternative? From what I can tell, you’re really only looking at ARM based on your frustration with the PIC
I’ve messed about a bit with the LPC chips from Philips/NXP (now merged with Motorola/Freescale). One of the things I like about the LPC ARM chips (at least the ones I’ve played with) is that they have 5V-tolerant inputs. This makes it easy to work with “legacy” 5V circuits. The chips also have a built-in bootloader that’s activated by a pin state just after RESET. The bootloader is in ROM in the chip, and uses the serial port. There’s an Open Source project for a programming tool:
https://github.com/capiman/lpc21isp
I have an LPC2119 board, and an LPC1114 chip in 28-pin DIP format. Photos of the LPC2119 here:
https://www.flickr.com/photos/anachrocomputer/albums/72157628745849693
It’s an ARM7TDMI-S CPU.
I’ve also used the STM32 Discovery boards, but like the LPC stuff, I’ve not got as far as making a repository for the code yet.
I\’ve heard a lot of people complain about the cypress/PSoC chips… not sure it is still relevant though (pins dying easily)
Also not sure why you\’d say MSP430 is any more proprietary than ARM… http://www.ti.com/tool/msp430-gcc-opensource
Also, keep in mind that code density is supposedly just as good on arm as AVR (in fact AVR wastes alot of space if you have larger than 8bit integers or floats) so going to 32bit doesn\’t mean you need very much more flash.
@toru173, I hadn’t considered a separate USB Host controller chip, so I took a look at the Cypress USB controller that you mentioned. The main advantage I see is that it separates the USB Host software stack from any dependency on a particular microcontroller or hardware USB peripheral. So the Cypress-provided USB host software should theoretically run on any mcu, and maybe (hopefully?) it’s of higher quality than the USB stack software provided by most mcu vendors. And of course this approach allows USB host even for mcus without a built-in USB function. The obvious disadvantage is that it require two chips instead of one. At least for my particular project, if I’m going to need two chips, it seems more natural to use one mcu for USB and one for ADB. But for other projects, I could see something like that Cypress USB controller being very helpful.
You could also just pay $5 for a Raspberry Pi Zero and do everything in software. In theory Linux supports ADB and USB for you already.
(Yes, I know actually finding a Pi-zero for sale at $5 is difficult, and you also have to factor in the cost of the SD-card, power supply, and some sort of hub if you want more than one USB port). But once you are looking at $4 ARM chips the jump to full-featured development boards running full operating systems isn’t that big anymore.
I’m not so sure a RPi would actually help. Just because it layers a whole Linux OS on top of things, I don’t see how it can solve the fundamental problem that interrupts will interfere with software-based ADB timing loops. If anything, it will make the problem worse, because on top of USB interrupts you’d also have timer interrupts for process switching, and probably lots of other interrupt sources. But even if that were solved somehow, it just feels like the wrong tool for the job. Imagine turning on your Mac Plus, but having to wait 10 seconds before you could move the mouse, while your input adapter booted its OS. 🙂
Well if you replaced /bin/init with your ADB->USB routine and ran nothing else you could probably get the boot time to be much faster than 10s.
I know Linux has existing support for ADB devices although I suspect it is not used much and might have bitrotted. If it worked you wouldn’t have to re-implement the ADB routines yourself. Though come to think of it that ADB support probably assumes Mac hardware and there might not be a bitbang driver.
When I tried looking to see if anyone uses Linux/ADB anymore the search only showed up unrelated stuff (people making USB/ADB converters using ATMega Teensy boards).
I’ve written code that bitbangs the PS/2 keyboard protocol over a GPIO pin from under Linux on a raspberry pi and it’s surprisingly usable, though not as robust as you’d probably like.
How about a two micro solution, like SpritesMods – a big one for USB Host, a small one for time critical ADB with a high speed UART and handshaking between. Easy to debug each end, too. The big one could easily be a Pi Zero.
Steve, I like STM32 and LPC chips myself. CMSIS libraries are generally all you need along with the generic ARM GCC toolchain from https://launchpad.net/gcc-arm-embedded
No need for any fancy IDE, KEIL or IAR compilers, or cruft.