Hackaday.io User Reviews Six STM32 IDEs

One of the issues with getting started with any Arm-based project is picking a toolset. Some of us here just use the command line with our favorite editor, but we know that doesn’t suit many people–they want a modern IDE. But which one to choose? User [Wassim] faced this problem, evaluated six different options for STM32 and was kind enough to document his findings over on Hackaday.io.

Many of the tools are Windows-only and at least two of them are not totally free, but it is still a good list with some great observations. Of course, the choice of an IDE is a highly personal thing, but just having a good list is a great start.

[Wassim’s] interest in STM32 was spurred by the Blue Pill board–the $2 STM32 board and his desire to debug it. He found you often have to make tweaks to the IDEs to get them to work. In fact, his final choice did require quite a bit of work, which he shares.

One thing he mentioned that we’ve also noticed: Most of the IDEs rely on an ST-provided code generator called CubeMX to start projects. That’s handy because it lets you select I/O devices and builds a lot of the setup code for clocks, interrupts, I/O setup, etc. However, there’s at least one bug in the generator that crops up if you try to use the PLL as the main clock. The fix is simple, but you have to apply it every time you regenerate the code. Speaking of clocks, if you are using the STM32 parts at this level, you’ll appreciate this discussion of clock options and caveats.

We love to see Hackaday readers share their research with the rest of us, and if you are not browsing Hackaday.io, you are missing out on at least half of the Hackaday experience. Meanwhile, I’m still an Emacs holdout (see video, below). It even handles debugging, too.

52 thoughts on “Hackaday.io User Reviews Six STM32 IDEs

  1. It should also include the Arduino IDE!

    Certainly not the best in the world and without debug facility, but the easiest to handle for a novice in software development, and probably he most documented one in the forums, so the best choice for a total beginner!

    1. I think if you keep using Arduino you will never stop being a beginner, If you really want to improve yourself the way is first learn digital systems (logic gates, flip flops, binary math, etc). After this learn Assembly programming so you really understand what you are doing, after that you can go with C and then C++. Get to Arduino is like you going fast with a electric scooter, not with your legs so you will never run.

  2. Thanks for highlighting this, it’s a bit “Everything you wanted to know about STM32, but were afraid to ask” for me. I’ve been using (and abusing) Arduino’s for years, and was never sure how (or why) to step up to the adult table. I shall be reading this with interest.

    I would love to see more of this type of long-form content, I thoroughly enjoyed Brian’s “Make a PCB in everything” series.

    1. You are better off trying the Arduino M0, which uses a SAMD21 ARM processor, if you want to avoid IDE frustration.
      Compared to the STM that is is lower power (good luck making all the battery powered things you normally make with a ‘mega328 on the blue pill).
      When you had enough with arduino, you can move to the free & unlimited & pro IDE, Atmel studio.

      Too bad the cloned boards are still expensive at the moment (~ $14), but they should drop in price, the processor on them costs the same as a ‘mega328 on the classical Arduino.

      A lot of the “big guys” (in the hobby field) are switching to the SAMD21 and not to STM. My best thought for this: the cheap STMs are not low power (breaking a lot of low power applications currently done with regular arduino) and the low power ones are not cheap. Plus, the legacy and support of Atmel regarding arduino.

      1. I doubt the datasheet for the STM32 lies. While the m328 is slightly lower power (~1 vs 2uA) than the stm32F103 running off an external 32khz crystal, the m328 boards (official Arduino, pro mini, etc) just come with a full speed crystal, which limits you to ~4uA for low power apps. The blue pill boards come with both a high speed (8Mhz) crystal and a 32k low power crystal. It also has a decent built-in RTC, so you can implement a decent timer on them without having to use an external RTC like is commonly done with Arduino projects.

        1. That is only from the battery pin and in Standby mode, which means the RAM contents are lost and you need to restart from scratch every time you wake up. Plus, your wake sources are limited to a single pin and RTC. In Stop mode (=== the sleep mode of the ‘328) when RAM is saved and program continues from where it left off and there are more wake up sources, you are looking at up to a few hundreds of uA. Whether you can go around it or not, it depends.

          Regarding the datasheet… it should be correct, but regarding the comments around here…that’s probably not the real chip you are getting in the blue pill. Not saying it does or does not meet specifications, I have not checked.

        1. And don’t forget, if you have an application that is a bit more demanding, ST has you covered with the STM32L1 and even the L4 family. Nobody that specifically targets low power applications would use the F-Series if you basically have a complete sub-family of special low power controllers based on a better silicon process and with more power control functions.

  3. Oo, good timing.
    I’m currently trying to port a legacy STM32 project from “Ride” in to something more modern and, while I’d been able to get working builds using make, I’ve been having issues getting OpenOCD working as the debug route – so far I’ve got Keil’s uV working (although the 32k limit is a bit frustrating as the project occupies up to 34k) but if there’s a way to get everyone else on Emacs then I’m definitely going to be trying that! :-)

  4. +100

    Thanks [Wassim] for putting so much effort into this and making things much easier for so many other people.

    I just downloaded System Workbench as it sounds like it will suite me.

    Choosing an EDA IDE ISE is always such a tedious task so you have saved me so much time, thank again!

  5. Thanks for the work that was put into this!
    I’ve been using a Keil IDE for most of my engineering career (starting back on the good old 80C51 series in ASM). For me it was pretty simple and logical step to just hop into the Keil ARM toolchain once we started to use STM32 controllers. But it’s always nice to see what the other IDEs around are up to and get an idea of what we might be missing out on by using the same old toolchain provider for decades…

    1. Keil works great out of the box, but a lot of people don’t like the fact that it isn’t “free”. They provide free code limited versions of their ARM compiler (32k), but also an unlimited compiler for STM32L0/F0 parts, which I use quite a bit. I recommend it to anyone looking to make the jump from Arduino/Embed, since it generally bypasses the frustration of getting even some of the “complete” IDE’s going for a project.

      1. I agree. We had some Renesas M16C controllers in a product for some time, so we used Tasking first, then had to switch to IAR because Tasking was not supporting the newer M16C controllers (NextGen) anymore when we had to upgrade out products. For me it was really a painful experience. That may have had something to do with the Renesas controllers in general (no JTAG, debug over UART and with ROM monitor code), but the IDEs definately did not help to get projects going either. (I had the pleasure to write a manual and guideline on how to port code from Tasking to IAR for our other coders at work, and that was really an odd experience i would rather not repeat again…)

  6. The GNU ARM Eclipse project seemed very promising to start with it is by far the best explained installation process of all of the eclipse based IDEs but is in desperate need of updating to use the Cube HAL libraries rather than the out-of-date standard libraries, it also does not integrate well with CubeMX from ST.

    I have to say that getting started with STM32 is not easy whatever IDE you choose. I don’t know about the expensive IDEs as they were not in my range, but I tried some of the free ones and free versions of the low cost IDEs when trying to get started and none of them really got you going right out of the box so to speak. All of them had some quirk that meant extra work is required to get started.

    The first problem is that there is no preferred IDE provided by ST. Some may argue that choice is a good thing but in reality it makes life more difficult when starting out. You first have to try and figure out what makes one IDE better suited to your needs than another. Then the documentation that ST provides often gives examples using any one of several random IDEs making it more difficult to follow.

    Next is the constant moving goal posts, ST seemingly keep changing their standard libraries, not just updating them but starting over. So when attempting to follow various blog posts etc a significant amount of it is completely out-of-date because ST have thrown out that way of doing things.

    The last is the documentation is not very friendly. In part it is due to the complexity of having such a powerful processor and lots of built-in peripherals. However information is scattered among dozens of documents, and not necessarily in a logical place.

    I’m not a particular fan of the Arduino but having started using the STM32 recently I can see why so many people cling on to the Arduino system as making the jump to STM32 is a steep learning curve.

    1. I agree with you. I have used professionally (nothing very complicated) quite a few families of micros with the expensive IDEs and things are generally rather smooth.

      I have also given ST a try quite a few times at home with the free tools, it works, but it is slow and annoying. Not to mention going through the whole 157 steps all over again when you want things setup on a different machine. Support is also mostly other people. I totally get that ST does not have any interest into supporting the free tools, they probably have some pressure from the big guys, because they were there at the beginning of their ecosystem (unlike atmel).

      Would say that for hobby level people should stick to what has good support, and lot look at saving every 0.2 if they are not building high quantities.

      The blue pill is an illusion – the price of the chip from serious distributors is 2-3x more than the board in single quantities and even a full reel does not get it to the price of the full board…something is suspicious.

        1. There got to be a way of telling GD32 apart from STM32.

          But then again, a person I know told me that the F4 micros normally costing 50 PLN or so can be had for 12 PLN in ~100k quantity. Extrapolating to the lower end and applying Chinese correction (big vendors have lower prices in China) the price could be at least in the order of magnitude for the Blue Pill to be viable.

    2. I recommend using an LPC chip from NXP when making the switch from 8-bit PIC/AVR to 32-bit ARM. The documentation is far better than anything I’ve ever seen from ST, and the free LPCXpresso IDE is quite good (this is on Linux, and since it’s Eclipse-based I assume the quality is the same on Windows).

    3. I see we have the same conclusions, I also think the GNU ARM Eclipse is the most promising and I seamlessly managed to import the cubeMX with the importer I mentioned.
      I think that the IDEs are not ST’s core business for which they have partners, they nevertheless cooperated with the ac6 (apparently) for that free variant as System Workbench which I find fair from ST, but that cannot compete with commercial IDEs. Also ST provided the tools required by IDEs such as the ST-LINK_CLI for command line interfacing and the st-util that even gives a standard gdb debugger interface. As an IDE Eclipse does the trick so any ideal solution for me would simply plug in there with as less black magic as possible.

  7. Get Eclipse, make your own makefile, linker script, startup code (code provided by ST is complete and utter POS). Use GNU ARM Embedded Toolchain, program with OpenOCD and you don’t need anything else. It costs $0 and is not restricted in any way.

    1. I second the opinion on ST. The Cube-generated code is bug-ridden and inefficient to the point that it’s almost useless, the HAL code is a mess, and calling the documentation quality “subpar” would be an understatement. The chips themselves are really nice, and very cheap for the power you get, but that only goes so far when the amount of developer effort required to make them actually *do things* is easily twice that of other chip brands.

  8. IDE,, bah, (auto/q/c)make script is all you need ;)
    But good tools to use is:

    0. Text editor of choice, emacs/vim/sublime/nano etc

    1. OpenOCD, its awesome, you can use your Pi or BBB to flash your device.

    2. Black Magic Probe (you can reflash your “blue pill” or st-link clone with it. it runs a gdb server on the “flasher” and also have UART pass-through.

    3. Use GDBs python api to set/manage (object oriented) breakpoints, good for integration tests ;)

    4. If you do not want to bother with low-level stuff then you can check out

    5. You can use QEMU to run some cortex m3 emulation if you fancy that.

    1. Sounds like a good combination, that is a nice custom “DE”. I would only argue for the graphical debugging, I’m curious if some, do really debug critical bugs such as let’s say two weeks debugging sessions just in command line and do feel more efficient ?

      1. Well, keep in mind that a) you can use the -tui flag to get a little better display. There is also a -gui flag (aka Insight) that is rarely built in but if you build from source and can keep the TCL versions straight, works well. In addition, emacs does a really nice job of creating a quasi-GUI for gdb under X or text mode. Finally, there are gdb front ends like ddd, cgdb, kdgb, etc. The trick is finding one that will let you set the gdb executable (or else you have to fake it out via path, symlinks, etc.). Lots of the IDEs and editors like Kdevelop, Codelight, QtCreator, etc. can run gdb as part of their thing (like Eclipse or NetBeans, too).

        So despite playing with SystemWorkbench I am way more likely to just regress back to emacs ;-)

    2. Here is my Makefile for an STM32L476. I have placed the STM32-Cube stuff in a specific location as well as gcc-arm-none-eabi. It can build in parallel mode (-j4, -j8 etc) and packs the HAL stuff into a static library on first compile. It does not (yet) create debuggable objects. Currently running this on a Mac and editing in Atom with very few plugins. This is one of my first Makefiles that I actually wrote line by line rather than copying someone else’s in the interest of seeing a blinking LED. I wanted a single Makefile without recursive make.

      I also use System Workbench in order to collaborate with other people who need to use it, but find the resulting projects to be extremely bulky, and Eclipse is really slow. I find Platform.io to be too board-specific so I just use plain Atom. Not that Atom is light on resources either, but it’s fast on decent hardware. I think that a well-crafted Emacs setup has the potential to be a long-term solution.

  9. Commercial IDEs like Keil and IAR are more complete, user friendly and supported, but very expensivel.
    Installing and using Eclipse with ARM toolchains was not so easy, but now there is “System Workbench for STM32” which is a very good free product and has STM32CubeMX perfectly integrated.
    The only issue I found is that STLink with OpenOCD is a little crappy and hangs frequently, but maybe it’s an issue of my old PC with Windows XP.

  10. I started using the STM32 line years ago. I quickly became frustrated by the lack of a free IDE that just installed and ran with no hassle. And with the cobbled-together IDE that I ended up with, there was no wizard for generating the boiler-plate code for a new project.

    So I ended up switching to Microchip’s PIC32. You install their free IDE, their free compiler (some optimizations are disabled, but there’s no code size limit), it’s supported by the manufacturer, and it has a wizard that generates the project and configures the peripherals you want.

    There’s nothing like having a manufacturer-supported IDE. At the time, I posted that ST really should assemble a toolchain. They’ve moved a little bit towards that goal with CubeMX, but they’re still way behind Microchip in terms of supporting firmware development.

    1. the reason that I and many others dislike and avoid the PIC32s is because, of how Microchip took a GNU GCC compiler for the MIPS M4k architecture which is open source and free, added some minor things to it and then charge 1000+ for it. The free version cripples basic optimizations that were already available in the original open source toolchain for free. They then lie to the consumer and say ‘oh we added these optimizations to the toolchain’ when they didn’t….thosr optimizations were for the most part at least already there. This is unethical in my mind and is the main reason why I wouldn’t use the PIC32/dsPIC/PIC24 families.

      I also simply refuse to use the PIC10/12/16/18 families because of how inefficient, unsophisticated, outdated and uninteresting their CPU architecture is.

      1. The GPL doesn’t prohibit charging for software; it just requires that the source code be made available. And I’m under the impression that it is.

        But I’ll come back to my original point: having a no-cost, prepackaged toolchain that’s supported by the manufacturer and includes rapid development tools like code-generating wizards and has no code size limitations is REALLY, REALLY nice. Add to that the fact that several PIC32s are available in DIP packages and you’ve got a company that’s very friendly to hobbyists. Show me something comparable in the ARM world, and I’ll think about leaving Microchip.

        As for the architecture of the 8-bit PICs: that used to bother me too. (Back in the early 1980s, I refused to buy a Z-80 or 6502 computer because of their architectures; I bought a SWTPc 6809 computer instead.) But it doesn’t bother me anymore. If I can live with the crappy x86 architecture in my PC, I can live with the crappy PIC architecture in my toys.

  11. One of the things that really gives Eclipse the edge is the fact you can use it for everything. I’ve got it setup to do ARM, Atmel, and ESP8266 coding, and at work I use it for C and Java. It can be a bit harder to initially setup the first time (or not if you can write a Makefile), but you get to leverage your knowledge over and over.

  12. I’ll just drop this here for all those GNU/GCC lovers. Best experience I’ve had in an IDE. Veryyy fancy text editor (doxygen plugins, code completetion etc), and very snappy UI and snappy debugging.


    Why try to connect 4 independent tools when you can get them compiled together already?

    1. @Tyler
      Agreed 100%.
      Emblock (aka Embittz) is the best I’ve found. Compile, flash, line debug & registry access a STM32Fx chip at lightning fast pace with a $2 ST-link V2 dongle. Use Emblock at least once to see how Cocox, Eclipse etc bloatwares (don’t even talk about Arduino) etc are the worst of cr.ps.

    1. I really appreciated you doing all the leg work! I have used SystemWorkbench before and the generic Eclipse stuff, but I usually don’t look at the Windows solutions, so your list and observations were really interesting and I knew a lot of people would benefit from it/enjoy it. Thanks again for sharing!

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.