Computing stuff tied to the physical world

The ARM ecosystem

In Hardware, Software on Sep 13, 2012 at 00:01

Yesterday’s post presented an example of a simple yet quite powerful platform for “The Internet Of Things” (let’s just call it simple and practical interfacing, ok?). Lots of uses for that in and around the house, especially in the low-cost end of ATmega’s, basic Ethernet, and basic wireless communication.

What I wanted to point out with yesterday’s example, is that there is quite a bit of missed potential when we stay in the 8-bit AVR / Arduino world. There are ARM chips which are a least as powerful, at least as energy-efficient, and at least as low-cost as the ATmega328. Which is not surprising when you consider that ARM is a design, licensed to numerous vendors, who all differentiate their products in numerous interesting ways.

In theory, the beauty of this is that they all speak the same machine language, and that code is therefore extremely portable between different chips and vendors (apart from the inevitable hardware/driver differences). You only need one compiler to generate code for any of these ARM processor families:

arm2 arm250 arm3 arm6 arm60 arm600 arm610 arm620 arm7 arm7m arm7d arm7dm arm7di arm7dmi arm70 arm700 arm700i arm710 arm710c arm7100 arm720 arm7500 arm7500fe arm7tdmi arm7tdmi-s arm710t arm720t arm740t strongarm strongarm110 strongarm1100 strongarm1110 arm8 arm810 arm9 arm9e arm920 arm920t arm922t arm946e-s arm966e-s arm968e-s arm926ej-s arm940t arm9tdmi arm10tdmi arm1020t arm1026ej-s arm10e arm1020e arm1022e arm1136j-s arm1136jf-s mpcore mpcorenovfp arm1156t2-s arm1156t2f-s arm1176jz-s arm1176jzf-s cortex-a5 cortex-a7 cortex-a8 cortex-a9 cortex-a15 cortex-r4 cortex-r4f cortex-r5 cortex-m4 cortex-m3 cortex-m1 cortex-m0 cortex-m0plus xscale iwmmxt iwmmxt2 ep9312 fa526 fa626 fa606te fa626te fmp626 fa726te

In practice, things are a bit trickier, if we insist on a compiler “toolchain” which is open source, with stable releases for Windows, Mac, and Linux. Note that a toolchain is a lot more than a C/C++ compiler + linker. It’s also a calling convention, a run-time library choice, a mechanism to upload code, and a mechanism to debug that code (even if that means merely seeing printf output).

In the MBED world, the toolchain is in the cloud. It’s not open source, and neither is the run-time library. Practical, yes – introspectable, not all the way. Got a problem with the compiler (or more likely the runtime)? You’re hosed. But even if it works perfectly – ya can’t peek under the hood and learn everything, which in my view is at least as important in a tinkering / hacking / repurposing world.

Outside the MBED world, I have found my brief exploration a grim one: commercial compiler toolchains with “limited free” options, and proprietary run-time libraries everywhere. Not my cup of tea – and besides, in my view gcc/g++ is really the only game in town nowadays. It’s mature, it’s well supported, it’s progressing, and it runs everywhere. Want a cross compiler which runs on platform A to generate code for platform B? Can do, for just about any A and B – though building such a beast is not necessarily easy!

As an experiment, I wanted to try out a much lower-cost yet pin-compatible alternative for the MBED, called the LCPXpresso (who comes up with names like that?):


Same cost as an Arduino, but… 512 KB flash, 64 KB RAM, USB, Ethernet, and tons of digital + analog I/O features.

Except: half of that board is dedicated to acting as an upload/debug interface, and it’s all proprietary. You have to use their IDE, with “lock-in” written on every page. Amazing, considering that the ARM chip can do serial uploading via built-in ROM! (i.e. it doesn’t even have to be pre-flashed with a boot loader)

As an experiment, I decided to break free from that straight-jacket:

DSC 3832

Yes, that’s right: you can basically throw away half the board, and then add a few wires and buttons to create a standard FTDI interface, ready to use with a BUB or other 3.3V serial interface.

(there’s also a small regulator mod, because the on-board 3.3V regulator seems to have died on me)

The result is a board which is pin-compatible with the MBED, and will run more or less the same code (it has only 1 user-controllable LED instead of 4, but that’s about it, I think). Oh, and serial upload, not USB anymore.

Does this make sense? Not really, if that means having to manually patch such boards each time you need one. But again, keep in mind that the boards cost the same as an Arduino Uno, yet offers far more than even the Arduino Mega in features and performance.

The other thing about this is that you’re completely on your own w.r.t. compiling and debugging code. Well, not quite: there’s a gcc4mbed by Adam Green, with pre-built x86 binaries for Windows, Mac, and Linux. But out of the box, I haven’t found anything like the Arduino IDE, with GUI buttons to push, lots of code examples, a reference website, and a community to connect with.

For me, personally, that’s not a show stopper (“real programmers prefer the command line”, as they say). But getting a LED to blink from scratch was quite a steep entry point into this ARM world. Did I miss something?

Two more notes:

  • Yes, I know there’s the Maple IDE by LeafLabs, but I couldn’t get it to upload on my MacBook Air notebook, nor get a response to questions about this on the forum.

  • No, I’m not “abandoning” the Atmel ATmega/ATtiny world. For many projects, simple ways to get wireless and battery-operated nodes going, I still vastly prefer the JeeNode over any other option out there (in fact, I’m currently re-working the JeeNode Micro, to add a bit more functionality to it).

But its good to stray outside the familiar path once in a while, so I’ll continue to sniff around in that big ARM Cortex world out there. Even if the software exploration side is acting surprisingly hostile to me right now.

  1. Hi, I’m also looking into the ARM Cortex world for embedded projects. Like you I’ve found the development software tools to be less ready to go than in the AVR world. However, you may want to check out the CooCox ( suite of free tools for ARM development. They support many ARM processors and have a set of useful tools to ease the pain of getting going, and a supporting community. Cheers Richard

  2. I think we’re just at the beginning of the shift to ARM in hobby electronics. I think it’ll get better. Hackaday just posted two ARM boards. Galago comes with libraries (, and another was posted that features drag-and-drop programming. For me the toolchain is important but I’d like to have a simplified API. Galago looks like a good option, meanwhile I use an mbed while my LPCXpresso sits in a box somewhere).

  3. If you’re cool with using the mbed compiler, you can still generate images from it and load them to raw LPC1768 or LPC1769 boards, same for their newer LPC11U24-based board. has a really good writeup on this. I’ve done it and it works well. If you want to flash it from linux, the lpc21isp program does that well from command-line.

    But I agree, a more open development path would be better. Check out the CMSIS library that most vendors supply with their chips.

    You’ll like this tutorial too: about using the new DIP package of NXP’s LPC1114. Looks as easy to hook up as a raw Atmega328.

  4. Texas is also adding an ARM board to its collection … introductory price $5,–, see

  5. Speaking of ATtiny, have you noticed the (recently funded) “Digispark” project on Kickstarter?

  6. I’m interested to hear about the JeeNode Micro rework. Might it use the RFM12B clock? If not I’m still interested.

  7. Nice to see a post about the ARM ecosystem. Just recently, i bought a “maple compatible” olimexino board with tons of interfaces (2xspi,4xuart,usb…)and even an build in bootloader and RTC – Nice to play with !

    @jcw: i also run the maple ide on osx. it is not as comfortable as on arduino (bootloader seems so have bugs interfacing usb), but it works. I had some Problems with the USBSerial device. I can onl y upload from one usb port, don´t know if it is a bug in the IDE or a configuration thing.

    Leaflabs try to be compatible to arduino language, but this does not unleash the possibilities of the stm32 (yet). Basic things work 1:1, so i think it is a good alternative.

    maybe you want to have a look at a (partly) RFM12 port for stm32:

  8. @jcw see for LPC ARM code and reference designs.

  9. STM32F4DISCOVERY seems to be cheap, 1MB of flash + 192KB RAM, it’s large however.

  10. Yep – lots of interesting developments. Let’s wait and see how the software side of it all goes…

  11. There’s also an interesting board called SimpleCortex ( It has the same processor as the mbed and Ethernet and Arduino headers on board, as well as a debugger that can be used with CooCox. They have already quite a few libraries and tutorials, and are very responsive in their online forum. I haven’t received mine yet, but I will try them out. For the Mac users, there is also a new project out there to use XCode as the IDE ( Have not tried it, but might be worth looking at JC.

    • Yep, got one of those as well (quite a collection piling up here as I explore the different units, or rather: plan to…). As with the Arduino, it’s really all based on one or two chips doing everything, with the tools and workflow around it making all the difference.

      It seems kind of odd to me that each µC platform forks off the Arduino IDE, and then adds its own compiler in. Doesn’t that mean that all the effort poured into the IDE and general workflow stops being shared and collaborated on?

  12. I see you have received lots of good ideas, but I would say you can’t go wrong with NXP’s LPC line of arm chips. You do have to wade thru lots of Keil stuff but if you dig, you will find plenty of GNU-based stuff.

    Here is a pretty handy collection:

    Also this guy is always worth checking out:

    For Linux, I suggest BeagleBone or Raspberry Pi

  13. @jcw, about “each uC platform forking Arduino and (…) all the effort (…) stops being shared”, you could be interested in previous discussions in the wiring forum.

    Most of the Arduino SW is actually directly derived from Wiring, and that platform claims to be nearly CPU-independent, but after one year Martin Bolivar still didn’t manage to get Maple (STM32) ported on it.

Comments are closed.