STM32 Nucleo, The Mbed-Enabled, Arduino-Compatable Board


The STM32 line of microcontrollers – usually seen in the form of an ST Discovery dev board – are amazingly powerful and very popular micros seen in projects with some very hefty processing and memory requirements. Now, ST has released a great way to try out the STM32 line with the Nucleo board.

There are two really great features about these new Nucleo boards. First, they’re mbed compatable, making them a great way to get started in the ARM development world. Secondly, they have Arduino pin headers right on the board, giving you access to all your shields right out of the box.

Right now, there are four varieties of the Nucleo board based on the STM32F030, -F103, -F152, and -F401 microcontrollers. The STM32F401 is the high-powered variant, An ARM Cortex-M4 microcontroller running at 84 MHz, 512kB of Flash, and enough I/O for just about any project.

If you’d like to get your hands on one of the STM32 Nucleo boards, you can order a voucher to pick one up at Embedded World in Germany next week. Otherwise, you’re stuck ordering from Mouser or Farnell. Bonus: the high-end F401-based board is only $10 USD.


  1. gagae says:

    32-bit microcontrollers are slower than 8-bit AVRs so they clock them with higher frequencies. I’ll stick with my good old Arduino.

    • Mike Lu says:

      Once you deal with quantities larger than 8 bits, the 16 and 32 bit processors have a huge edge. Granted, there are still lots of applications where that’s not the case and an 8 bit is more than appropriate.

    • fonz says:

      In what alternative reality is an ARM is slower than an 8-bit AVR when running at the same frequency?

      • cpldcpu says:

        It’s because he says so. Don’t you believe him?

      • Daniel Holth says:

        Imagine if you will a world where the Cortex bus connecting the STM32 core to its GPIOs has a 2 clock cycle delay. In this world, much like our own, AVR bit banging is twice as fast at the same clock frequency. Only the M0+ cores have a faster bus allowing single-cycle pin access.

        • fonz says:

          how fast you can toggle a pin is a very very narrow definition of faster, and since an STM32F4 uses abut 1/4 the power per MHz you could toggle that pin twice as fast as an AVR using the same power

        • tekkieneet says:

          You can sort of treat it as a pipeline as the pending I/O cycles are affected the same way, so you can start toggling other I/O before the changes get propagated to the actual pins.

          The AVR has an output delay of 1 cycle. Figure 14-4 It has up to 1 cycle of input delay. Fig 14-3. for ATmega 328.

          Don’t forget that the chips can be clocked very much higher frequency than the AVR and can do fancy bit masking on its GPIO . If you are not plain bitbanging, the peripherals are much more powerful and faster than the AVR and you can use DMA for peripherals and GPIO.

        • Take a reel of InGaAs amplifiers and you can ‘toggle a pin’ at maybe 50 to 100 GHz. Magnitude faster than any microcomputers to date!

      • gabriel says:

        in the arduino world, hue

      • tekkieneet says:

        Is that the same world people use the Arduino digitalRead()!?

        Until *everybody* in the world start accessing I/O directly and uses all kinds of tricks such as unrolling their bitbanging loops or recoding stuff in assembly (see V-USB), this is not something that is critical to the average users.

  2. Adam says:

    I’ve never used the ST’s STM32. Can anyone comment on the level of support in GCC for the processor?

    • sicksad says:

      Seem’s pretty good, i got up and running on an STM32F4 without much hassle using the gcc-arm-embedded toolchain (had good support for the floating point unit which was nice). libopencm3 is worth checking out as well, it’s a really nice firmware library for the STM32 range of micro-controllers.

      • Mike Szczys says:

        If you have already used ARM you’ll get up and running quickly. If not, you’ll be stuck in the datasheet for a bit (even getting gpio set up is more involved that the 8-bit micros I was used to).

        But either way the gnu toolchains work very well with this family of chips.

        • sicksad says:

          @Mike Szczys If you use the libopencm3 firmware libraries there’s some good quality example code available here:

          It was my first time doing ARM stuff and I managed to avoid digging through datasheets pretty much entirely just by playing with and re-purposing those examples. I also hear that ST’s firmware libraries leave a lot to be desired.

          • Ewout Boks says:

            ST Libraries are written cleanly, very useable and without errors. Best of all, they sare free. I use them in production code without any problem. Please indicate where you find that they leave a lot to be desired.

    • Ethan says:

      Support is great with gcc-arm-embedded toolchain. There is also a great eclipse plugin that integrates with OpenOCD, which works great with the cheap st-link programmer. The micros themselves do require a bit more boilerplate code / register setup before getting up and running (compared to an avr), but it’s definitely worth it for more complex projects!

    • Matthew says:

      There’s a reasonably good (I hope; I wrote it) introduction to using GCC and Eclipse to program STM32 parts here: An update for the F4 series of parts is here:

    • codeman says: Has lots of support for the ST parts and bet they will add support for these boards real quick they did for the 429 Disco board.

      • I give up on em:blocks, I was going to extend some features in it but forum reply to others requests put me off (and others…):

        Re: How to build Em::Blocks from source Postby EmBlocks Feb 14, 2014
        …That’s why the focus isn’t on building and that’s why you are on your own by building the tools. I can’t/wont support all those questions about building errors etc also…


        “All the open parts are available at the SVN and a “how to build” can be found at the codeblocks wiki. The pre-build SDK and plugin development “toolkit” should be available in the future. ” (I will not even go into the GPL violations here…)

        I understand that this is a ‘Windows’ only fork of Code:Blocks for bare-metal gcc-arm, but the single dev on the project is not interested in outside contribs and thus dealing with bugs/features/etc… will leave most embedded beginners lost.

        As others in this thread posted, go grab Eclipse and add the embedded plugins. Great community support, period. Most of the Arm licensors are using Eclipse plugins (Look at FreeScale’s great Process Expert as an example).

        That said, I am not a huge Eclipse fan, and do not use it for NON-embedded C/C++, but, again, the ARM based integrators, vendors and community make it very livable.

        If you are looking for another Windows only Code:Blocks fork and just happen to ONLY use Segger’s J-Link/J-Trace for your debugger, emIDE might just an a good option.

        • whyme says:

          I don’t think that this is a real issue. CooCox is, despite it’s name ‘open’ as closed as Fort Knox and is still the de facto free tool for ARM. EmIDE is only accepting Jlink because it’s from Segger and you can use code::blocks with a commercial embedded debugger plugin which you have to pay.

          The question is if something works right, I don’t know how good it is compared to others but what I do know is, that it is very active. I did several bug reports and a feature request, all very fast solved.

          It definitely works for me.

  3. ino says:

    Compatible, with an I not a A.

  4. Liam Jackson says:

    The freescale freedom is a particular favourite of mine for this purpose, mbed compatible, arduino compatible, built in accelerometer, buttons, rgb led, cap sense pad. 5v compatible i/o, comes without the headers soldered, has little sticky feet and is cheap as chips!

  5. It’s pretty misleading to call a board “Arduino Compatible” when there’s no software to support actually running Arduino sketches & libraries. Even if the 4 sockets that fit the form-factor of Arduino shields matter, this board lacks the 6 pin header that modern Arduino shields use to get the SPI signals, so it can’t work with popular shields like Ethernet.

    I’m sure it has lots of great features, and the $10 price is amazing (or a loss-leader promotion). I’d expect ST to the Arduino-like features, and indeed they carefully say “leveraging … Arduino ecosystems to accelerate software and hardware development”. I would hope Hack-a-Day’s editors would know better than to call a board without any Arduino software support “Arduino Compatible”.

  6. G says:

    This chip makes my dick rock hard.

  7. Daniel Holth says:

    Also check out

    The ST-provided firmware library is a bit tedious. On these chips you have to individually configure every single pin (by initializing a C struct and passing to the firmware library), and remember to enable the peripheral clocks, before they can be used. By comparison the simpler AVR requires much less setup code. However the STM32 line is powerful and well priced; I like that a lot of the parts have a built in DAC.

    • Mike Szczys says:

      Ha, I referenced the same pin config issues above. Glad I’m not the only one who found that process a bit of a trial!

    • Elia says:

      You can configure multiple pins at once but I agree it’s a little tedious.

      What’s really sad is that they don’t have a separate voltage reference pin below the 100 pin packages although the low pin count ones have a DAC and ADC.

    • Matthew says:

      You don’t have to use the firmware library at all. You can save yourself some time and code by manipulating the registers directly from your code. Every micro requires you to set each pin as an input, output, etc, so that’s no different than any other micro. What is different is the STM32 parts have more options (input/output/alternate function, pullup/pulldown/nopull, pushpull/open drain, skew rate) than many other micros.

  8. Ren says:

    I didn’t finish reading the article or the comments,
    I went to Mouser and ordered a couple.

  9. Max says:

    If you want to program STM32 Microcontrollers and are willing to get used to a special C++ style you should checkout the xpcc library:
    There are some examples for the stm32f3 and stm32f4 discoveryboard:

  10. armstrap says:

    I’m still a fan of ARMstrap boards (which is basically a BlackMagic probe coupled with a STM32F4 ARM chip). They work better on Mac, Linux and Windows and their licensing allows you to actually *use* and *sell* your final product.

  11. Torque says:

    Why isn’t there a 5V logic level ARM IC that’s both cheaper, more powerful and with better software support than a humble Atmega?

    They all seem to suffer from lack of at least one of those factors.

    • Sweeney says:

      Erm, how about because as IC process technology gets smaller logic levels have to be reduced. The latest chips are running 1.2V logic. 5V logic is archaic and even 3.3V is starting to fade. It’s the same reason that it’s getting progressively harder to source through hole mount ICs as surface mount is taking over.

      As for libraries, as even Arduino have decided that the ARM chip is the way forward (the current Due and forthcoming Tre are based on them) so much Arduino code will run on them already.

      • It Tre really based on an ARM chip? I mean for the Arduino programmable side which you actually program with the Arduino IDE, not the Linux part. The last info I saw on their website said it had a AVR 32u4 (same as Leonardo) for the Arduino side.

        Did they change that? Long-term, it’d be awesome if they made the transition to the same chip as Due.

        • Sweeney says:

          Hmm, looks like you are right about the microcontroller half, they are still using the 32u4 for inexplicable reasons (they could have least used an ATMEGA2560, instead making something with underpowered IO like the YUN)

          • six677 says:

            The yun does the same as the tre and offloads to an AtMega, sure you dont mean the Galileo?

          • Sweeney says:

            No, the YUN like the Tre uses the ATMEGA for pin/GPIO IO (I’m not talking about network IO). The 32u4 is lightweight in pins, RAM and ROM.

          • MarkS says:

            32u4 has a programmable amplifier on the ADC pins – which makes it more useful than the Uno variants. IMHO

      • tekkieneet says:

        Small geometries means they can make more chips per wafer (cheaper) or pack more transistors into same area, get more speed out of circuit and lower power (more powerful). The trade off for these advantages is that the voltages the transistors can handle is getting lower for smaller geometry. This had been going on for longer than some of the people here, so ditch your 5V stuff already.

        For the software support, that’s a marketing/support question…
        I wish we could hack Atmel Studio to work with other vendor’s ARM chips. :(

        • six677 says:

          Visual Studio wont do? It supports C projects with custom makefiles which could invoke one of the various arm toolchains if you wish.

        • tekkieneet says:

          I am using Atmel Studio for a new revision of my old design, but the hardware wasn’t as fast as my old non-AVR rev. so that I have to go back. Been spoiled by AS6 that Programmer’s Editor I used to be using before seems lacking now. So I added the custom makefile as a different “solution” to my AS project. It actually work very nicely. The lack of debugger/simulation isn’t an issue as I didn’t have that previously.

          What I am hoping is that all the hard work that Atmel put into making Visual Studio to work could be extended to other ARM chips to have the debugger working too. Legal issues aside, someone would need to hack in those XML files and back end etc.

    • Petr says:

      For 5V compatible ARM chip, you can check Freescale Kinetis MKE02 chips and associated FRDM-KE02Z board (

  12. Chris C. says:

    As expected from ST, a great board for the price. Shame about the Arduino-compatible form factor though. I have neither an allegiance to Arduino nor an aversion to jumper wires, so the form factor only means to me that the board is about twice as large as necessary.

  13. miceuz says:

    Can anyone tell me how this is different from discovery boards? I’m drooling over STM32 for a couple of weeks already and this nucleo business just throws me out – should I get a giscovery board or one of nucleos?

    • F says:

      If you are new and you want to get started right away, the Discovery boards have more software available and there are more tutorials, blogs, articles, etc. about them. The Nucleo boards will probably be as well supported someday, but not yet.

      • miceuz says:

        but both of them have the same selection of MCUs? As far as I can tell, Discoveries have more bells and whistles while Nucleo is just a micro on a board and a separable debugger.

  14. F says:

    It looks like you can snap off the debugger, but there doesn’t appear to be any way to program it after you’ve done this. There’s no power connector either.

    What’s unusual here is that ST has installed the LSE crystal for the Nucleo boards, which they do not do in the Discovery boards. Alas without a battery holder we won’t be able to take full advantage of it.

    These Nucleo boards appear to be just about completely devoid of external peripherals (unlike the Discovery boards) so their development environment would probably work well with other boards, too. is currently DOWN, now I remember why I prefer the compiler on my computer.

    • ;-) I had fun with mbed for a couple of days as it is a neat cloud concept… but also ran into ‘online availability’ issues with their site.

      Once was the connection I was on as it was bouncing on/off and caused their ‘ide’ to get confused, and than I had complete timeouts/hangs on their site two days in a row…Did an “Export” on my project for my ‘off-line’ toolchain and did not look back… :-(

  15. garym53 says:

    Dear HaD. I would like to inform you of a revolutionary new software product – it’s called a “spelling checker” – it is a fairly new technology – I would estimate no more than, say, 6 decades old…

    If you try it you might find it very “compatible” with your work process.

    • Nitish K.S. says:

      Just don’t trust that spelling checker too much. It’s unlikely to find anything wrong in sentences like “The dog did not jumped on it’s tail because its whey to short four that”. It’s safer to use your own brain.

      • garym53 says:

        LOL – Obviously using “their” brain didn’t work in this instance – also even the best brain occasionally makes a typo – BTW none of my errors are ever spelling mistakes – they are always “typos” ;-) Let’s just say the brain and a spelling checker are a pretty good combination if you are trying to publish professional looking articles.

        • Nitish K.S. says:

          I do agree that spelling checkers are useful. They ought to catch things like ‘awfull’, ‘aweful’ and ‘compatable’. These should not appear in an article, let alone a headline.
          Perhaps by analogy with passionate / compassionate, ‘compattable’ might be acceptable coinage. (-:

          • Ren says:

            My wife’s aunt is a proofreader for the executives of a major corporation…
            Let’s just say her skills are NEEDED with that group of people. B^)

  16. Matt Evans says:

    With all the talk of libraries/toolchains/IDEs above I’m surprised not to see more mention of mbed, which supports these boards. It’s great for rapidly knocking something together, with a load of cool libs. For those wanting a one-line “configure this pin and drive/wiggle/read/sample it”, mbed will scratch that itch.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s