The Coming Age Of ARM Chips For The Hobbyist

The days of the 8 bit Arduino may be quickly coming to a close. Sure, there will always be a place for AVRs in blinking LEDs and turning on relays, but for doing anything cool – playing MP3s, driving LCD displays, or running a CNC machine – you need the power of a 32 bit chip. [Brian Carrigan] put up a great tutorial on getting started with these bigger, more powerful micros and moving beyond what is possible with an 8 bit PIC or AVR.

These new 32 bit chips are much more powerful, but aren’t exactly hobbyist friendly. Most of the ARM chips we’ve found are stuffed into very fine pitch QFN or QFP packages that require a reflow oven to solder to a board. In fact, we can only find one through-hole Cortex M0 chip that is suited for breadboard development. This doesn’t make it easy to whip up a circuit in a few hours, so builders needing a very powerful microcontroller will be more dependent on dev boards.

Already there are a good number of ARM-based 32 bit dev boards available including the offerings from Leaf Labs, the extremely inexpensive STM Discovery boardKinetis KL25Z Freedom Board, the outrageously powerful BeagleBone, and the perpetually delayed Arduino (over) Due.

None of these boards are particularly new developments; they’ve all been around the block once or twice. However, there are many more options for 32 bit development than the current 8 bit PIC and AVR holy war. We’re going to turn the comments over to Hackaday readers with the following questions: what supersized dev board are you rolling with? What’s good for a beginner, and what should they watch out for?

98 thoughts on “The Coming Age Of ARM Chips For The Hobbyist

  1. I mainly use STM32 chips, and the F4 range is great when you need a lot of power, with chips starting at 5 usd… (168mhz, easily overclockable to 250 mhz, with builtin fpu).

    The STM32F4 discovery board is nice with GCC and GDB if you follow some tutorials, but not really beginner proof.

    We are developing a open hardware dev board based on stm32f4 chips with pymite (python on a chip) and a bootloader for python code (supporting gdb), making it easy for beginners to start rolling out their code using simple python code, at a blasing fast speed… So yeah, I think the era for easy arm dev is coming :)

    1. Where do you get STM32F4 at 5 USD? All chips I could find were ~15 USD in single numbers and 10 USD for 50+.

      I love my STM32F4 discovery board, but for my next project I was thinking of a LPC2000, simply for cost reasons.

    1. Eh? You can decode a mp3 stream on a 8-bit microcontroller? I suppose that the bitrate of the mp3 would be like 1kbps then? I’m quite certain that you can’t decode any normal bitrate mp3 with any 8-bit uC. You need much more “oomph” to do that – or have a decoder-chip like a VS1001ca a co-processor.

    2. You missed the part where those 8-bit mcus have a HARDWARE MP3 DECODER. Its true. But even an ARM7TDMI at 50MHz (or even more?) can barely decode a low quality mp3. A ‘stupid’ 8-bit avr or 8051, etc at sub 20MHz doesn’t have a chance without hardware assist. The only thing those mcus are then used for is pushing bytes around and showing menus.

    3. What on earth are you talking about? Maybe I’ve been out of this market for long enough and they’ve gone backwards, but the last time I checked almost everyone in the DAP market used ARMs, sometimes with hardware acceleration and sometimes without. SigmaTel chipsets were ARM9(?) (Rio Carbon / iRiver era, maybe four years ago), and a cursory look at the current AMS SoC used by Sandisk is yet another ARM.

      Out of curiosity I checked out the (almost) first DAP, the Rio PMP300. That chip does follow the design pattern you suggest–an 8-bit NEC processor and an Actel FPGA (or CPLD) presumably to do the MP3 decoding. However, I haven’t seen this design pattern in a very long time, and if you check Rockbox you’ll find that virtually all reasonably modern MP3 players are designed with software MP3 decoders. Don’t let VSLI or the STMicro MP3 decoder chip fool you–these are mostly used for low volume or hobby applications, and AFAIK most commercial MP3 players have opted for using a single 32-bit chip or 32-bit ARM-based SoC.

    4. Oh, and decode /does/ take a lot of power. Encoding just takes /more/. Have you ever attempted to implement a MP3 decoder on an 8-bit micro? I worked out some estimates a few years ago, and it’s basically not possible for any reasonably high quality files to be decoded with less than mid-high 10s of MHz on an ARM7 (plus a good deal of RAM). On a side note, MP3 does better than many “true” (I don’t include silly things u-law) compressed audio formats — OGG uses a surprising amount of RAM, for example.

      1. You can make ‘a cnc machine’ with an arduino but the sort of motion control used for driving high performance servos is in a different league on a “proper” professional CNC machine tool. It’s more than an an 8-bit, 16Mhz Atmega can really handle.

  2. PIC32 is still very strong – they are cheap and incredibly flexible. A lot of times they have peripherals included that are vastly superior to the other guys, though I will agree that from a sheer processing standpoint they sometimes can’t stack up.

    Still, for a couple bucks you can’t beat ’em!

    1. From a sheer processing standpoint the PIC32 has actually a faster processor than the ARM chips. the MIPS M4K core has a Dhrystone rating of 1.56DMIPS/MHZ whereas the cortex-m3/m4 is 1.25DMIPS/MHZ. Ofcourse chips like the STM32F4 offer more performance than the PIC32 because they can run at faster clock speeds (168MHz as opposed to 80MHz) and some have an FPU which is not on the PIC32. I also find that the STM32 Peripherals are more sophisticated and complicated compared to the decent (not as sophisticated) and simple to use peripherals on the PIC32.

    2. Thumbs up on the PIC32. I thought it was a bit of a feeble toy attempt on the part of MIPS/Microchip to take some ARM market share, but I used it to cook up a quick and dirty webserver app with an Uno32, and it’s actually quite respectable. I’ve been doing some cost estimates for a cost sensitive audio related application, and it turns out that they’ve also got a pretty appealing price point.

  3. I’m rather a noob here but I thought the Raspberry Pi was an ARM CPU? I know it’s an older ARM and some Linux distros have moved past that chipset but I’ve started playing w/ mine recently. And by playing with I mean, it sits on my desk, turned off and calling me names (mostly names my parents used to call me when I was growing up like: Lazy, Bum, Good-for-nothing.)

    Wow…guess I need to keep going to therapy after all.

    1. You are correct- the RasPi is an ARM processor. The article above though is specifically talking about Cortex M processors, which are meant to compete with 8 bit microprocessors (low cost, low power). The RasPi uses a system on a chip that includes an ARM11 core and its own GPU. If you are making 10 boards that are made to turn an LED grid on and off, it would be easier and more cost effective to use a $3 microcontroller which sips 10mW of energy then even the $25 RasPi which is running an operating system to do only one task. Likewise, asking a Cortex M to display video over HDMI would be difficult if not impossible.

  4. TQFP or QFN does not require an oven, if you only want to solder a few it’s 3 minutes for a 64pin device and a bit longer for 100 and 144 pin.

    It is very handy if you use a device with boundary scan to automatically search for bridges (unconnected pins almost never happen)

  5. I’m still waiting for my Kinetis boards :(

    My issue with ARM development at the moment is the difficulties involved with getting a development environment set up on linux, and the lack of up to date tutorials. I spent a few days trying to get an ARM GCC toolchain with hardfp support for the STM32F4 before eventually giving up and going with softfp (which was admittedly straightforward to set up, but it’s really annoying not being able to natively use the built in floating point stuff without dropping to assembly). After that ordeal, I am yet to begin trying to figure out remote gdb, the various ways of writing the chip, and tackling the datasheets.

    On the other hand, beaglebone is really easy to work with because you can just access the pins as files and you have access to all the standard tools/environment for debugging. You can use whatever language you want to/are familiar with, which is pretty cool.

      1. Cool, your tutorial looks very useful :) Will have another go at getting hardfp working soon based on that.

        Probably a large part of my ARM pains/tutorial issues were self-inflicted because I don’t really want to use eclipse, I prefer to just work at the command line with vim/gcc.

    1. We gave a talk at DEFCON about our 6LowPAN mesh project, and a major part of that is doing something serious to the Linux ARM development toolchain to make it suck less. There’s no reason at all that building something for an ARM chip should be any harder than doing so for an AVR, but since every manufacturer has put together their own toolchain complete with IDE, on Windows, there’s no consistency in the Linux world. We’re hoping to get people together and fix that. We’ve set up forums at to start figuring out how to do that.

    2. I’ve been running a fantastic ARM development environment on UBUNTU 12.04 LTS for a few years now (been upgrading my linux around it since 9.xx so its nicely robust) , its cheap (for hobbyists) and it really works well… Look into Crossworks by Rowley Associates. It installes easily.. the only slight finagling you have to do is to make sure the USB JTAG or SWD tool you choose is supported and correctly configured on Linux… easy if you have ANY linux experience, and well described on their site…

      This and the Eagle distribution for linux and I’m set for pretty much all my micocontroller hacking.


  6. I’m pretty surprised you didn’t mention the mbed, which is ARM’s own dev board. It has a online IDE so you can compile and build your program on their servers to download and put on the board. I’ve been using it for a while and it’s as easy as using an arduino.

      1. As far as I know ARM doesn’t even have any actual chips of their own. They license their core design to companies like NXP, STM and TI which then use their core and add their own peripheries.

        Since hobbiists are hardly the target demographic of ARM I doubt they have development boards. I would guess that you need to be a relytively large company to get access to their eval boards.

      2. The founder of mbed was and still is an employee of ARM and he works on mbed full time, for ARM. Infact from the mbed website:

        “The mbed project was initiated by two ARM employees, and later became an official research project within ARM. It is now run and maintained by ARM to help MCU Partners provide their customers with the best way to prototype designs using their microcontrollers.”

  7. has some really awesome QFN/QFP breakouts which allow you to prototype with these ARM chips pretty readily. They have something like a thickened solder resist so the chip kind of locks in place. Then you just solder it all on.

  8. Thanks for emphasizing my thoughts that 8-bit is legacy and 32-bit-MCUs just the right stuff for hobbyists.

    Being a professional electronics developer I abolished 8-bit-MCUs in 2007 and was a little surprised that Arduino and other great platforms forgot to switch to modern MCUs for years.

    One great Cortex-M3 platform I’d like to recommend is EFM32 from Energy Micro. Getting 30 MHz of ARM-Power out of just 4 mA at less than 2 volts should convince everybody! They also hav an application note showing how to set up a cost-free development environment using Eclipse/CDT which is one of the best source code editors on this planet.

    Hackers out there: Go for 32 bits!

    1. I love 32 bits and use it more and more. But i guess one major part holding me back is the SMD factor.

      Don’t get me wrong I love SMD and I have no problem soldering TQFP and 0603 by hand, but it is difficult to reuse the microcontrollers, if you update your project to a newer version. I don’t like the idea of creating a new revision of aproduct and then have a couple of old boards laying around with perfectly good µc on them, that I can’t reuse.

      Of course I could use dev boards until I’m absolutely sure that I won’t need to revise the project. But I’ve had prototypes laying around / working for month and I don’t want to tie up my boards for this long.

    2. that’s great for you!

      but…why should the arduino have moved on?
      8 bit processors aren’t all that bad, really depends on what you’re doing?

      for 99% of hobby uC projects, (I’m talking flashing lights, moving motors, 3d gantry control, robots, cat flap/chicken house door openers, pet feeders etc,)
      8 bit micro’s are more than enough for most!

      I cracked open an old 3com managed switch the last year and was a little surprised to see that was running a motorola 68HC12 inside it, (that’s only an 8bit chip), the switch was fairly old, 10/100 24 port managed switch, but that 8 bit micro was good enough to run the switches operating system, provide a terminal to connect to the switch, do limited packet inspection/vlan tagging etc…

      I get that 32 bit is the future, but again I kinda feel like I want to know (even though it’s none of my business) was your choice all that well informed, was 32bit actually what you NEEDED, or just what you wanted. -given that the ECU on the Porsche Carerra 2 is only a 16bit micro, I’m wondering what on earth you’re actually doing that absolutely needs 32bit?
      (and yeah, the reason I want to know is because you’ve stated that you’re a professional, and you’ve left 8bit uC’s behind. -I’m hinting here that I’m wondering what sort of professional entirely sidelines feasible products in favour of more expensive lines)

      The first time I see a 32bit chip being used only to flash an LED, I’m going to cry a little inside!

  9. I’ve been using the original mbed board. You might think you’re “locked” into it’s online Development Environment, but there are people making things happen with Linux and the ARM GCC toolchain. They have a pretty good community forum too.

    But [tzar] is correct about it being a pain to use Linux with it. I’ve never had any luck setting it up.

  10. Thanks for the great discussion all!

    The article above is the first of a series I will be making about switching to 32 bits for hobbyists called “24 More”. There is a lot of discussion going on about toolchains here which is what my next article will be focusing on, so check back in the next few weeks if you are interested in making this adventure.

    As far as my setup- I am using a Segger JLink EDU paired up with the freeware Keil ARM (I have yet to need a program over 32kb). This setup costs a total of $60 and provides the most flexibility from development to deployment on a custom board. Once I begin making projects that require more than this I think that it is worth checking out Rowley Crossworks – I have tried the demo and fell in love with the silky interface and polished look. I mainly work with the LPC11 or LPC11U chips… I love the ROM USB libraries and easy to use peripherals.

  11. I’m surprised at the lack of mention of the Raspberry Pi! It is indeed a 32-bit machine and running at 700MHz, overclockable to 800MHz, add a heatsink. But no worries, I believe the arduino folks will be on the wagon real fast with their own ARM-based products to rival it and the Bone. By no means do I think the RPi is an arduino-killer. The arduino folks have a LOT of board design savvy and years of production experience, I have confidence in them, I doubt they will disappoint. But the RPi is very very definitely a fav of mine at this point given the power-to-cost ratio.

    1. Apples and oranges comparison really. They’re not really targeting the same space, although there is obvious overlap. Getting an arduino to do meaningfull computer vision is virtually impossible, getting a pi (assuming linux) to run some code guaranteed 50 microseconds after some external event (important for things like control loops) is virtually impossible.

      You have to understand the problem you’re trying to solve. The Pi is not a superset of an arduino, it’s different.

  12. Too bad ARM and it’s license holders DRM the chips and hide functionality like crypto hardware and trust zone..

    If you RE and make a lib or use a 3rd party lib you get massivly sued..

  13. A problem (for me) is that the datasheets for these things are very short and barely scratch the surface. They tell you what peripherals are available but not how to access them, and even among the other docs there is not detailed info how to do so. On the other hand the datasheet of a PIC is exhaustive and goes in detail over each feature, each register one by one and explains precisely how they are used.

    1. Hey vic-
      You might have more luck searching for “User Manuals” instead of datasheets. The datasheets are often for engineers just looking at using the chip in an application, where as the user manuals are what contains register definitions and specifics as to how peripherals work.

    2. I feel your pain! Working with my STM discovery board felt like being lost in a labyrinth without a map sometimes.

      I can see that these chips often have way more peripherals than the smaller 8 bit µcs, but I would be way happier with one 5000 page PDF describing all the control registers, than I am now – seraching the web, looking through tons of different PDFs, tutorials, examples and finally just looking through the source code for the included library to figure out how different calls to the libraries interact with each other.

      1. I agree that the STM32 libraries are cumbersome and difficult to use (probably because they use the same library for the entire STM32F1 series which has a ton of variation), but I found it is a good starting point for code. When I need to write code for a peripheral, I first consult the giant user’s manual, and then if I run into trouble I will check how STMicro did something in their peripheral library.
        Like I said in the article above, the selling point of switching to Cortex Ms isn’t their ease of use, but their potential.

  14. I’ve been hacking with a Raspberry Pi recently, but I’m about to permanently commit it to a project so have a TL-WR703N on order to play with next. I don’t know of any lower cost entry to 32-bit hacking, save fabricating a board from scratch.

  15. “but aren’t exactly hobbyist friendly” — WHAT? Hello… NetduinoGo and FEZ Cerberus make these 32-bit ARM chips ridiculously easy to use. No Assembly, no C++. Heck you can even use BASIC!

  16. I have the Discovery M0 board, anybody have any tutorials for a noob to get started? I can’t seem to wrap my head around the windows dev environments, but I am pretty used to CCS for the launchpad…

    1. not entirely true – jtag-based avrs can be debugged by avarice and gdb. You just need to build a simple avr-based jtag to serial adapter with firmware being easily downloadable. I debugged avrs in eclipse too. But with their extremely simple nature, it was very uncomfortable – there’s no good mmapped io viewer I know of.

      But AFAIK debugwire avrs can’t be debugged by open source means and none can be debugged by a truly open adapter. Or am I wrong? Please if anyone knows of a solution, I’m all ears.

      1. true that.. I just found out that the cortex line has standardized single pin serial debug protocol to drop pin count and it already has massive open source support, including openocd. One of the reasons I love arm.

  17. I have to put a strong vote into NXP’s LPC line. The LPCXpresso can be pretty cheap (in fact NXP GAVE ME a Cortex-M0 board) and it comes with a full jtag. What I like most, though, is the IDE coupled with examples. The IDE is eclipse based making it way better than any of the 8bit processor IDEs. You can even use eclipse plugins in the thing, like the SVN plugin. The LPC1XXX chips aren’t bad either. The LPC1343 has a built in USB bootloader. How cool is that? (All the other LPCs have a built in serial bootloader, which is handy, but USB bootloader is cool)

    1. Not only does the LPC1343 have a USB Bootloader, but it has USB HID and USB MSC drivers built into it. What’s even better is that I remember seeing that the new LPC11U2/3X have even more drivers built into ROM. I will hopefully be posting the details on the LPC1343 based USB Business Card I made shortly.

    1. I already post a video like that! But the code for blinking LED were done in Python and control messages were sent by Wifi :-) — on a Linux board that costs $25, Olinuxino/IMX233.

    2. My blinky code for ARM7TDMI (AT91SAM7S256) :)

      GNU assembler ARM test for AT91SAM7S256

      LED connected to PA11


      @ Pin mask
      .equ PA11, (1<<0)

      @ Peripheral ID:
      .equ ID_PIOA, 2

      @ Power Management Controller:
      .equ PMC_BASE, 0xFFFFFC00
      .equ PMC_PCER, 0x0010

      @ Parallel IO Controller
      .equ PIOA_BASE, 0xFFFFF400
      .equ PIO_PER, 0x0000 @ PIO enable on pin
      .equ PIO_PUDR, 0x0060 @ Pull up disable
      .equ PIO_OER, 0x0010 @ Output enable
      .equ PIO_SODR, 0x0030 @ Output high
      .equ PIO_CODR, 0x0034 @ Output low

      .equ WDT_MR, 0xFFFFFD44 @ Watchdog mode register

      .equ delay, 2250

      .section .text

      .global main
      ldr r0, =WDT_MR
      ldr r1, =0x30008000
      str r1, [r0] @ Disable watchdog

      ldr r0, =PMC_BASE
      ldr r1, =PIOA_BASE

      mov r2, #ID_PIOA
      str r2, [r0, #PMC_PCER] @ Enable PIOA clock

      mov r2, #PA11
      str r2, [r1, #PIO_PER] @ Turn the pin over to PIO control
      str r2, [r1, #PIO_PUDR] @ Disable pull-up
      str r2, [r1, #PIO_OER] @ Enable output
      str r2, [r1, #PIO_CODR] @ Set output to 0

      ldr r4, =delay
      mov r3, r4
      subs r3, r3, #1 @ 1 TC
      bne loop @ 3 TC
      str r2, [r1, #PIO_SODR] @ Set output to 1
      mov r3, r4
      subs r3, r3, #1
      bne loop2

      str r2, [r1, #PIO_CODR] @ Set output to 0

      @ Blink LED
      b loop_start

      b . @ Infinite loop

  18. I use an NXP LPCXpresso board. They have various versions of this one with different chips (cortex M0 to M3). The board is compatible with mbed and has most of the IO ports on standard 0.1″ headers, which makes it rather easy to use for prototyping.

    One problem with this board is the locked down JTAG adapter that comes with it only allows you to use the matching toolchain which is only a demo version.

    The workaround is to use the serial bootloader embedded in the LPC ROM. This makes it possible to program the chip with only an uart connexion, and you can go without any other hardware at all, which is quite nice.

    I still have to make something really useful out of it however. There is some code to write to get your app running, setting up clocks and interrupt vectors, that wasn’t neede on AVR8. And as there are so many different ARM devices around, there is no real standard for that yet…

  19. Wow that pdip cortex-m0 is awesome ! It can even run directly from 2 AAA batteries and is debuggable by openocd without ugly kludges. Once it sells on ebay or anywhere with cheap intl shipping, I’m definitely there ! The only shame is it doesn’t have a usb device interface (but you could make a software-based usb low speed device with tons of time to spare). Thanks a lot, hack a day !

  20. If you want a line of 32-bit MCUs in DIP, try Microchip.

    There is no demand for these in consumer products. They’re making them just for us, the hobbyists. They’ve made their toolchain totally free, uncrippled, open-source, and cross-platform for us too.

    Microchip has changed a lot over the last few years. No other 32-bit MCU or manufacturer is as hobbyist-friendly, with the sole exception of the Parallax Propeller. I switched to Microchip some time ago, after a horrid experience with ARM, and have never regretted it.

    1. I don’t know what you don’t like about ARMs. They’re practical, powerful, easy, almost entirely open and industry standard. I switched to them after a horrible experience with PIC16 series (really? bank switching?) and a reasonable (but not open enough) experience with avrs.

      1. My bad experience was with a LPC2148.

        Two days trying to get the Windows toolchain working, with no progress.

        Two more days getting Ubuntu up in a VM and the Linux toolchain working.

        Ten more days getting the USB CDC code working, because of an intermittent bug in the compiler that unbalanced the stack upon return from an ISR; which was particularly harrowing for a beginner.

        In all, two weeks wasted before I could write any productive code.

        I have absolutely no complaint about the ARMs themselves. In fact, they’re very nice. It’s the lack of DIP packages, and problems with toolchains (which apparently are still common enough) that bug me. Your experience, requirements, etc. may differ.

        But I wouldn’t judge Microchip based on the now very antiquated PIC16 series. They’re still made, but only for legacy products.

      2. There are no problems with toolchains if you just learn to compile/use the standard GCC for ARM and skip all the vendor assist crap. Just take their linkerscripts (clean out the crap), write your own headers, etc. and you’re good to go. I do this now after a horrible experience with atmel C ‘utility’ library for AT91SAM and I couldn’t be happier.

        The rising popularity of the cortex arms should help this too – I understand they have many things standardized, including vectored interrupt unit and debugging capabilities. There isn’t anything like that in arm7tdmi that I use now. That should make for some nicely portable code.

        AFAIK the 32-bit microchip mcus don’t even have gcc support.

      3. The amount of time I have to work with MCUs, beside many other hobbies, is limited.

        Sure, I could “just learn” how to modify and compile GCC. But like most hobbyists, I have zero interest in doing so, and will not invest my limited time in it unless there is a darn good reason to do so.

        So I use MCUs for which a guaranteed working toolchain is already. Whether it’s GCC or not is completely irrelevant, though the PIC32 compiler is in fact GCC based.

      4. I guess you make a good point, for ignorants, pic32 seems indeed like a good platform.

        Did you read what I said? Default arm gcc, no modifications needed. If you find it somewhere precompiled, it’s your business. And if you don’t have time for this, then you probably would be better off skipping embedded development altogether and just using arduino.

        If the pic32 compiler were any good, it would be official part of gcc already. This forking gcc business smells pretty foul.

  21. I did a pretty complex university project with a LeafLabs Maple (STM32F103 – Cortex M3)
    It cost around 50 euros I think, so not awfully cheap, but all the peripherals have DMA support which means you can get amazing data throughput – The two ADCs can be used to sample at up to 2 MHz!

    They have a good guide to getting the build environment running on linux (gcc/g++), though starting your own project is not so easy due to the makefile-fu they use.

    Also comes with a version of the Arduino IDE and supporting libraries which lets you program it using Wiring (or whatever the language is called)
    I never used that, but I think it might not use the chip’s full potential

  22. There are many ARM Cortex Boards out there. The best (non-arduino clones) in my opinion are the LPCXpresso boards/IDE. The boards cost $20-$30USD, come in many variations, LPC1114(M0)/LPC11U14(M0)/LPC1227(M0)/LPC1343(M3)/LPC1769(M3( with a hardware debugger and a LPCXPresso Developer environment limited to 128KB program size but thats a lot of programming…infact thats more memory than the program memory available on most of the micros on the LPCXpresso boards. The fact that a 28-pin DIP version of the LPC1114 (32KB Flash) micro is available is also nice though I’d like to see a DIP version with more flash memory…at least 64KB.

    The next up are the STM32XXDiscovery boards. They range in price from $15 to $8 and come with a hardware debugger.They include cortex-m3/m0/m4 parts but no development environment like the LPCXPresso. But the free Coocox IDE supports some of the boards….especifically the VL and F4 variants. You could also use the FreeGCC tools and openOCD if you feel courageous.

    I personally find the STM32F4 to be overkill. If I need a 168MHz+ microcontroller for an application, I would probably end up using a Raspberry Pi or beaglebone. But if you like microcontrollers on steroids take a look at the 204MHz dual core cortex-m4/m0 chips from NXP LPC43xx and the RX chips from Renesas.

    The other two boards that have been announced but not produced are the Cortex-m0+ Freedom board from freescale and cortex-m4 Stellaris launchpad. The Cortex-m0+ Freedom board is $13. You get a Dev board (arduino compatible) with debugger. Hopefully they will be compatible with Freescale’s Evaluation version of CodeWarrior which is limited to 128KB. Again this should mean practically free development cost for the board since the on-board micro has 128KB of memory on it. The last one that (looking real good!) is the $5 Stellaris Launchpad (M4). The board will probably have an on-board debugger and some development tools support via TI’s code composer studio.

    One final micro worth mentioning is the PIC32MX1/MX2 chip from Microchip. They come in 28-pin DIP packages (or easy to solder 44TQFP (0.8mm pitch) packages), have upto 128KB flash/32KB RAM, USB and a host of other peripherals. The MPLABX IDE is free and the XC32 compiler is also free but with optimization disabled. Versions of the IDE and toolchain exist for all OS’s (Linux, Windows and Mac) and the PicKit 3 Programmer/Debugger costs around $35 USD

  23. At the moment i’m designing an arduino pin-compatible board based around the TI LM3S817 (Cortex-M3 with 64kB rom and 2kB RAM), which i might also adapt to bigger Stellaris MCU’s

  24. I don’t know, after reading this whole disscusion I’m not to sure as a hobbyist, that I want to even look into many of these ARM chips. I’ve used parallax propeller(32 bit 8 cores) and never had any troubles or difficultys like mentioned here and it’s easily the next step up after an arduino if more power or flexibility is needed.
    What are you guys using the ARM chips for that the arduino or propeller can’t do/handle? Don’t the lower power chips still have a place in the hobby arena?

  25. The questions I ask when designing are:
    1. What does it take as input data?
    2. How much power (processing, milliamps) will it need?
    3. What format is the output data? Examples: LCD, audio, video, USB or Ethernet.
    4. Do I need intermediate storage (RAM)? If so, how much?

    Only THEN do I consider: What chip should I use?

    For truly powerful platforms, best bet is combination of microcontroller… and an FPGA. Choice of microcontroller is personal preference, BUT it MUST support High Speed (480Mbps) USB! Ethernet is nice, but USB is essential.

    If you only need Full Speed (12Mbps), you may as well stay with 8 bit designs. A 32-bit chip with FS PHY is overkill.

  26. If you want to go 32 bit without ARM look at the pic32 line of chips, some of them are DIP packages. Pic32 are not based off earlier pic chips but are based on the mips processors.

    For ARM I really do not like ST. The libraries are more difficult to use than some of the other offerings, for price though they can’t be beat.

    If I wanted to get a start with ARM I would go with nxp. The chips are well supported, there are free easy to use compilers and sdk, like coocoox and the price isn’t bad either.

  27. 16-bit PICs never get any love…

    I will admit that I love to play with higher powered chips, but I can’t say that any of the projects I have ever done needed more processing ability and memory than what is available on a 18F887. I have done projects where I needed more interrupt channels and specific types of I/O though.

    My personal favorite 32bit controller is the Maple. But all of my embedded projects have used 8 and 16-bit PICs. My temporarily embedded projects largely use Arduino-ites.

    All of the world’s problems would be solved with GCC++ for PIC18.

  28. anyone knows where one can buy the DIP ARM chip LPC1114FN28 ? Only place that has it in stock I found is avnet express and they won’t ship internationally without some ridiculous export documents and credit approval.

  29. 32-bit is certainly all we wanted, and not necessarily what we needed. However, what’s changed now is that 32-bit is all we ever wanted at almost the same price point as 8-bit. The reason for that, from what I can tell, is that the 32-bit guys want to take the 8-bit market, and they’re taking the more advanced fabs from the high performance CPU market with them into the 8-bit market. Did you know that some of Microchip’s processes are still on the hundreds of nanometer scale? A lot of the new Cortex-M0s cost <$2 each, most likely because most of them were manufactured on 130nm or even more advanced fab lines, even in small quantities. So what is there to stop you from switching to 32-bit? Why should you bother?

    I'm writing this comment because I happen to be in the position of working on several projects across many microcontroller lines that have been mentioned in this post – ultra-low-end 8-bit PIC12/16Fs, 32-bit PIC32s, and 32-bit ARMs (mostly Cortex-M0).

    Now I know my recent experience with PIC12/16s isn't particularly representative of most hobby 8-bit applications, as PIC16s are pretty crappy architectures in the 8-bit hobby world, which has AVRs (probably one of the highest performance but also most expensive 8-bit chips out there) taking a pretty big market share.

    By far the best reason I can give you for switching to 32-bit is simply that they have so many features and perform so fast that they're just easier to work with. The 8-bit project I've been working on is a fairly extensive but also price constrained project with a custom low level infrared protocol decoder, several PWM outputs, and a software instruction decoder. As you can imagine, coding this to work was a b****. However, at the sub $1 price point necessary per chip, there wasn't much of an alternative (I hadn't heard of Cortex-M0s / they hadn't come out when we originally spec'd the hardware for the project).

    Now I absolutely wished we'd been able to use an ARM. At 48MHz, roughly 1-2 clocks per instructions, 13(!!!!!) PWM outputs, ADCs, 40+ GPIOs, an LPC11xx series does just about everything you wanted with very little work, and virtually no need to worry about not having enough clock cycles. I needed an infrared translator board (still needed processing–implemented a custom serial protocol and the same custom infrared protocol, with some automatic command timing specific to the application) and managed to finish the code literally in two days' worth of free time, compared to about 3-4 weeks for the 8-bit part of the application. No need to be concerned about how I implement passing variables (used good ol' reusable queue structs rather than static queues), using greater than 8-bit variables, etc–I could focus my time on getting my project to work rather than dealing with 8-bit nonsense (16-bit timers on 8-bit micros is a PAIN when buffering isn't available on your chip!)

    You can find dev boards at the <$10 range. Of course, those features are not exclusive to NXP–another project I used a different Cortex-M0 manufacturer, this time from a much less known Chinese manufacturer (Nuvoton). The documentation was better quality than I've seen from most Chinese manufacturers, but was definitely lacking. The chip had a few extra quirks and crazy features that I'll let you look up on your own, but they were particularly useful for the application. More importantly, the code I wrote was pretty easily portable, and experience with one ARM architecture passes over to another without too much difficulty.

    Then there's PIC32–I've obviously got a bit of a soft spot for Microchip, mostly because I started out in digital electronics with a PIC16F88, but I'd say they're pretty respectable too, and certainly on par with ARM. My impression is that they sort of really shine in the Cortex-M3 range of products. I did a project with a Uno32 board to make a quick and dirty network-based application, and it turned out pretty well, if you exclude the nonsense with the Microchip Encryption Libraries (can't blame them, turns out ITAR/whatever isn't happy with exporting encryption technology in hardware, which applies to microcontroller manufacturers but not software guys).

    Anyway, to end this, I'm going to link to elm-chan (crazy dude who made his own analog feedback loop to drive a high performance laser projector) and his article on switching from 8-bit to 32-bit Cortex-M0s. It's in Japanese, so you'll have to do a translation, but it's well worth the read as it really matched up pretty well with my experiences and I think many hobbyists' experiences with switching to 32-bit.

    1. Hey, so far i haven’t heard people talking about MSP430.

      I dumped all PICs , Mbed , etc in favor to MSP430 .

      Those little things are awesome and I can develop 100% under Linux.

      So far I My personal choices are : MSP 430 for uC and beagle bone as a cheap Arm Big processor.

      No I don’t work for TI , but they seem to have a nice documentation , good application notes , and once again full compatibility with linux toolchain / Jtag / etc.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.