PlatformIO And Visual Studio Take Over The World

In a recent post, I talked about using the “Blue Pill” STM32 module with the Arduino IDE. I’m not a big fan of the Arduino IDE, but I will admit it is simple to use which makes it good for simple things.

I’m not a big fan of integrated development environments (IDE), in general. I’ve used plenty of them, especially when they are tightly tied to the tool I’m trying to use at the time. But when I’m not doing anything special, I tend to just write my code in emacs. Thinking about it, I suppose I really don’t mind an IDE if it has tools that actually help me. But if it is just a text editor and launches a few commands, I can do that from emacs or another editor of my choice. The chances that your favorite IDE is going to have as much editing capability and customization as emacs are close to zero. Even if you don’t like emacs, why learn another editor if there isn’t a clear benefit in doing so?

There are ways, of course, to use other tools with the Arduino and other frameworks and I decided to start looking at them. After all, how hard can it be to build Arduino code? If you want to jump straight to the punch line, you can check out the video, below.

Turns Out…

It turns out, the Arduino IDE does a lot more than providing a bare-bones editor and launching a few command line tools. It also manages a very convoluted build process. The build process joins a lot of your files together, adds headers based on what it thinks you are doing, and generally compiles one big file, unless you’ve expressly included .cpp or .c files in your build.

That means just copying your normal Arduino code (I hate to say sketch) doesn’t give you anything you can build with a normal compiler. While there are plenty of makefile-based solutions, there’s also a tool called PlatformIO that purports to be a general-purpose solution for building on lots of embedded platforms, including Arduino.

About PlatformIO

Although PlatformIO claims to be an IDE, it really is a plugin for the open source Atom editor. However, it also has plugins for a lot of other IDEs. Interestingly enough, it even supports emacs. I know not everyone appreciates emacs, so I decided to investigate some of the other options. I’m not talking about VIM, either.

I wound up experimenting with two IDEs: Atom and Microsoft Visual Studio Code. Since PlatformIO has their 2.0 version in preview, I decided to try it. You might be surprised that I’m using Microsoft’s Code tool. Surprisingly, it runs on Linux and supports many things through plugins, including an Arduino module and, of course, PlatformIO. It is even available as source under an MIT license. The two editors actually look a lot alike, as you can see.

PlatformIO supports a staggering number of boards ranging from Arduino to ESP82666 to mBed boards to Raspberry Pi. It also supports different frameworks and IDEs. If you are like me and just like to be at the command line, you can use PlatformIO Core which is command line-driven.

In fact, that’s one of the things you first notice about PlatformIO is that it can’t decide if it is a GUI tool or a command line tool. I suspect some of that is in the IDE choice, too. For example, with Code, you have to run the projection initialization tool in a shell prompt. Granted, you can open a shell inside Code, but it is still a command line. Even on the PlatformIO IDE (actually, Atom), changing the Blue Pill framework from Arduino to mBed requires opening an INI file and changing it. Setting the upload path for an FRDM-KL46 required the same sort of change.

Is it Easy?

Don’t get me wrong. I personally don’t mind editing a file or issuing a command from a prompt. However, it seems like this kind of tool will mostly appeal to someone who does. I like that the command line tools exist. But it does make it seem odd when some changes are done in a GUI and some are done from the command line.

That’s fixable, of course. However, I do have another complaint that I feel bad for voicing because I don’t have a better solution. PlatformIO does too much. In theory, that’s the strength of it. I can write my code and not care how the mBed libraries are written or the Arduino tools munge my source code. I don’t even have to set up a tool chain because PlatformIO downloads everything I need the first time I use it.

When that works it is really great. The problem is when it doesn’t. For example, on the older version of PlatformIO, I had trouble getting the mBed libraries to build for a different target. I dug around and found the issue but it wasn’t easy. Had I built the toolchain and been in control of the process, I would have known better how to troubleshoot.

In the end, too, you will have to troubleshoot. PlatformIO aims at moving targets. Every time the Arduino IDE or the mBed frameworks or anything else changes, there is a good chance it will break something. When it does, you are going to have to work to fix it until the developers fix it for you. If you can do that, it is a cost in time. But I suspect the people who will be most interested in PlatformIO will be least able to fix it when it breaks.

Bottom Line

If you want to experiment with a different way of building programs — and more importantly, a single way to create and build — you should give PlatformIO a spin. When it works, it works well. Here are a few links to get you started:

Bottom line, when it works, it works great. When it doesn’t it is painful. Should you use it? It is handy, there’s no doubt about that. The integration with Code is pretty minimal. The Atom integration — while not perfect — is much more seamless. However, if you learn to use the command line tools, it almost doesn’t matter. Use whatever editor you like, and I do like that. If you do use it, just hope it doesn’t break and maybe have a backup plan if it does.

40 thoughts on “PlatformIO And Visual Studio Take Over The World

  1. As a champion of using make plus your favorite editor for STM development, I realize that I am leaving out an important issue. Namely libraries. I have done mostly bare metal development, which is a lot of fun and floats my boat. But what about somebody who doesn’t want to write all of their own drivers? So I start thinking about ways to leverage libraries that may be included with the STM specific development tools (call them IDE’s if you will). Something worth talking about.

    1. At least as far as Arduino is concerned, it would be nice to have a toolchain (Makefile, bash scripts, whatever) that can build and upload your code to the microcontroller from the command line, with whatever choice of editor floats your boat.

      As far as libraries are concerned, I would hope it’s simply a matter of providing that build tool with a path to the directory in which your libraries are kept.

    2. I’ve been using libopencm3 for around a year now on and off, and for the last month professionally. It has its limitations (mostly when using less-supported chips, like the STM32L0) but has proven to be quite efficient and capable. Have you given it a shot?

      1. Yes sir, it is easy enough to supply a path to the libraries. But you gotta have some libraries!

        Thanks for the tip on libopencm3, that is just the sort of thing I am looking for! I mean I like writing device drivers more than almost anything, but I am trying to get a friend to start fiddling with STM32 devices and don’t want to start him off doing full bare metal. That aside, even I get lazy sometimes and consider using somebody elses driver.

        1. One thing I did not like about libopencm3 (and this may be my ignorance) is the documentation for some things (like serial) didn’t show up in the right place. So you have to go find the doc in whatever processor that you aren’t using that supplies it. The code seems good, though, I just didn’t like the docs.

          I know it is controversial, but I’m not too unhappy with the STM32CubeMX libraries. There is a little bloat, but not so bad and everything is consistent with polling, interrupts, or DMA. The code generator fits into Eclipse and does a nice job of configuring everything (except where it makes bugs). I should probably do a post on that at some point in the near future.

          1. mBed is easier to use than STM32Cube/HAL. The mBed API is also very flexible and much better put together in my mind than the arduino API. But it is the most bloated API that I’ve ever used (50KB binary size for a blinky that sends a message to serial every second), especially when using mbed OS 5 and a newly supported board. In many ways mBed’s weakness is similar to that of platformio. It tries to support too many boards and tries to hide much of the intricacies of each microcontroller peripherals and build setup from the user. So a lot of troubleshooting will be required when faced with a bug/glitch

          2. @halherta… Well, I actually really like mBed for some things. But the export to an IDE almost never works right for me. I always wind up with some massive headache getting it out of the online IDE. One thing I liked about PlatformIO is that it will successfully set up an offline mBed project for me, so +1 for that. However, I had trouble when I needed an older version of the mbed library. Ivan’s comment (below) may be an answer for that, so maybe I’ll try that again.

          3. @Al Williams I guess what I wanted to say is that while mBed is primarily an API and platformio is a build system, they both try to support many targets and this can be very challenging. I very much like platformio and use it regularly. When a bug is reported in platformio it is usually fixed very quickly. This is one of the man reasons that it is successful.

            Unfortunately this is not the case for mBed however. Bugs and lack of peripheral support can plague certain targets for years. The mbed RPC library does not support many targets and is buggy…eats up all of the heap memory very quickly. The mBed USB library also doesn’t support many targets and is only now (years after these targets were advertised as mBed supported) is some effort being put into porting the USB Device libraries to the STM32F0/F1/F3 devices.

            Because it’s the responsibility of the vendors to port mBed to their microcontrollers, they usually (especially the ST guys) only support the base mBed library and still rush it….. introducing even more bugs. Not to mention that there’s little documentation about which which target has support for advanced peripherals like ethernet, USB, Bluetooth e.t.c.

            Now add the code bloat that comes from using an RTOS by default in mbedOS5 (mbedOS2 was already bloated as it is) and mBed unfortunately becomes a hot mess. They also keep introducing new RTOS’s and stacks without addressing these core problems introducing even more bloat.

            mBed is a great API library, I really like it but it is from my experience plagued with many problems that arise from having many targets that are not supported properly. I hope that they fix these problems. If not I’ll be migrating back to Arduino/teensy for my fast prototyping needs.

            BTW there was an effort to switch the current mBed online IDE with one that’s cloud9 IDE based. not sure how that is coming along now.

            For the past year, I’ve been using primarily coding with MBed (Nucleo-F411RE) offline via PlatformIO plugin with the Atom code editor despite its (Atom’s) shortfalls. I will probably change my preferred fast prototyping platform to the teensy 3.2 still via platformio and perhaps VIM as an IDE.

  2. As a tolerable bare minimum, if I can’t easily write, compile and upload Arduino code in vim I’d at least like to be able to invert the color in the Arduino IDE for a black background with less eye strain.

  3. Hi Al,

    Firstly, thanks a lot for this review! It’s the first blog record about PlatformIO on Hackaday.

    > But it does make it seem odd when some changes are done in a GUI and some are done from the command line.

    I want to note that PlatformIO has begun a story as CLI tool. PlatformIO IDE is a wrapper around PlatformIO Core (CLI) with own extra instruments and features. Currently, we are working on PlatformIO IDE 2.0 where the main aim is to create easily for use instrument but with a rich set of professional features (debugging, data processing, etc.).

    > When it does, you are going to have to work to fix it until the developers fix it for you.

    No need to do that. You can fix your project to a specific version of a development platform. What is more, you can have multiple build environments that are based on different versions of development platforms. For example (platformio.ini),

    platform = foo@~1.2.3
    board = …

    platform = foo
    board = …

    platform = foo@<1.0.0
    board = …

    See documentation for details:


    Please note that we have not been released PlatformIO IDE yet. We implemented only 20% of the unpcoming features in the PIO IDE 2.0.0-beta.3. Some of the features are announced already, like a "1-click" debugging" and others we keep in secret :)

    Stay tuned!

    Ivan Kravets @ PlatformIO

    1. Hi Ivan,

      I hope you didn’t take any of my comments as too harsh. I personally like the CLI. I just know I’m in the minority and it is always funny to me when I see a mix which seems like it would satisfy no one since most people polarize one way or another. I will say, though, at least your files are in the clear. SystemWorkbench annoys me by making me change a hidden text file to fix the OpenOCD reset every time I create a new project! That’s bad no matter what you do ;-)

      As for the fixing of version numbers, I’ll have to look harder at that. I know the mbed libraries, in particular, are terrible for massive changes that break low-level stuff (like adapting it to the F103). So maybe that is an answer is to freeze at one level. I didn’t realize you could that.

      I still prefer the CLI and use emacs as my GUI, but then again I could say that about almost everything.

      1. > I hope you didn’t take any of my comments as too harsh

        Your comments are 100% truth. I like a honest point of view, it forces me to be better and better. The same here, we see which parts we should improve as soon as possible!

        We don’t have an aim to clone existing IDEs (Eclipse, Visual Studio Desktop, etc). IoT Community requires simplified and easy for use instruments where people can focus on own ideas and save time on learning new IDEs, instruments, etc. A single ecosystem for hundreds boards/MCUs, libraries, easy switching between them, etc.

        Thank you!

    2. I began using over a year ago, as I heavily rely on SublimeText as my everything editor.
      The DevIoT plugin, despite being buggy at times offers a great way to ease you into the platform and after a while you really better start editing configuration files yourself and here and there use the command line ;)

      I really enjoy a lot, especially how easy it is to use local libraries and create target environments.
      I mostly develop on AVR, and I like that I can specify the Arduino framework or just work without it (especially when it comes to ISR vectors used in the Arduino framework).

      It’s a great project and I’ve helped a couple of my most curious students get into it :)
      Documentation, though, seems seems to still have some non-updated entries, so often I prefer to just launch commands with the -h flag and go from there.

      I’m a happy evangelist ;)

  4. I like this article because these tools are introducing new concepts
    1) Arduino concept, wider and more open
    If some people find the Arduino cool, well the Arduino concept is even better. The mBed is to me an Arduino like concept (closed source, ready board support, either runs easily or forget about adapting it), which is good to do 99% for those who do not need to modify any software, but just take ready projects and flash them. So applying that concept to open source Frameworks brings the power of two worlds, out of the box projects compilation, and with the option to refactor the source and use it in other projects for those who wants to.
    2) Package Management:
    Nodejs, wouldn’t have had its success without npp, same as pip for python, and now microcontrolelrs programming do have their package management, that hopefully will stick with the community and in a way that any one would contribute his library with dependencies and version so that others can use it without headache (still with efforts but everything is relative).
    3) Verstility
    PlatformIO provides its core functionality independent from any specific IDE or editor. Atom is for me like Arduino, pretending to be an IDE. I would not forgive an IDE the lack of debug which would require someone to have another IDE so the first one drops the ‘I’ from the IDE.
    4) Visual Studio Code never pretended to be an IDE, I tried making a search on its home page and About, it is a Source Code Editor. It makes git commits faster, and the command line terminal is an integral part of it. It is made by developers and for the developers. To get the idea, just have a look at the “File\Preferences\Keyboards Shortcuts”, well it opens a json file for you, where you can search, copy, paste, generate, backup, the dream of every developer who had to scroll two hours on a gui to find shortcuts in classic editors.
    5) Looks easy but it isn’t
    I completely support the point that with both concepts combined, Platform+VSCode, things look simple, but they are not, well let’s look at it this way : this was never intended for those looking for out of box, no docs reading users, who can stick with Arduino’s IDE, but rather for those who parses the doc, get to know all what’s under the hoods, and once there, then the question to which Framework and editors could be the most efficient, and there it’s hard for me to imagine better.
    – Once someone have his complete environment set up, custom or IDE, then what about package management, and that’s the main thing that would push me to use platformio, probably later to search for libraries and share mine.
    – I’m not an Emacs nor a Vim user, I know already that VSCode might not compete as it’s still possible to argue, but VSCode is rather new to the open source, and I’m astonished to see Microsoft skeptics telling good things about it, so who knows where this is going to end up to.

      1. When mbed started it was online only and, in my opinion, was totally useless because of that. It can now be used stand-alone and supports quite a few processor lines. I found the documentation was quite good.

      2. Well, theoretically you’re right, I was hard by saying closed due to historical strategy and I was rather influenced by the mbed OS 5 which only compiles with armcc that is either expensive or online (they take your source for that). So to be optimistic let us hope these gcc compile issues will (or if not already) be solved, and ARM will play the true open source and would not be afraid of the so called fragmentation.

    1. just use PlatformIO with Visual Studio Community then instead of VS core. I have been doing so for 2 years. Ivan provides excellent support BTW so even if you run into a problem/defect it gets resolved quickly.

      Arduino’s build thing is a mess that leads to terrible code structure, it should be avoided for anything ‘real’. Just look at, a fabulous library that is incomprehensible when you want to change something due to Arduino’s IDE magic background thingies. But PlatformIO understands it so things become tolerable again :-)

  5. Why would you use a javascript based IDE when there are native IDEs that do more, do it better, do it faster and use fewer resources? I do not understand the appeal.

    1. Because all the hipsters know javacript and refuse to program in anything but it regardless of whether it is web based or not. That’s how we end up with a code editor running on a chrome instance and using at least 300MB of RAM at start up (Atom IDE). All hail the crappy javascript!

      Platformio on the other hand when used in cli mode or with another code editor/IDE is pretty awesome…until a bug is encountered that breaks your build system….though they do fix bugs pretty quickly.

  6. Do either of these tools (PlatformIO or VS Code) support hardware debugging for microcontrollers? It looks like they don’t, but I could be wrong. It seems like most folks who want debugging use manufacturer-supplied IDEs, or (shudder) something based on the Eclipse CDT.

    1. Totally, 100%, agree. It’s 2017 — haven’t we figured this out already? I don’t touch MCUs that don’t have reliable debuggers (and good IDEs to go with them), and I have no idea why people put up with development environments (either CLI or graphical) that don’t enable this. Honestly, the whole “community-driven” dev environments have always seemed strange to me. Manufacturers spend a ton of time developing IDEs that work well with their MCUs — why not use them? If you’re going to grab a Freescale (err, NXP…) part, why would you use anything other than Kinetis Design Studio? Same with MCUs from Silicon Labs, Microchip, TI, etc (hell, even Infineon has a great IDE in DAVE). Basically every manufacturer has an Eclipse-based IDE these days, and Mac/Linux users are no longer allowed to bark about OS support, since it seems like there’s pretty good solutions no matter which OS you’re running.

      1. While debuggers are an incredibly powerful dev tool and is in some cases an absolute necessity (debugging DMA stuff), I find that I rarely need to use it if I have access to well developed printf function.

        1. You are joking right? Printf’s alter the flow and timing of your code. Esp on small devices where the serial io is interrupt driven or worse, polled. If you take out the printf’s then the timing is off. Nothing beats a set of breakpoints.

      2. Yeah. Like Atmel studio, that completely crashes/messes up when you put it on a computer with Visual Studio already installed. And when it works and you are using 2 computers(home and office) you must have exactly the same version or weird stuff happens. Or when STM updates their libraries to fix issues you had but after update you version of code is incompatible with the version of the library. The version incompatibility is widely present in all the IAR and eclipse based compilers. Not to mention linux support is mostly non existent.
        Yes arduino IDE is useless and most libraries are classes calling classes to call classes. But if it would have the option to control which library you use and to right click on the function and say Go to implementation it would be in the top cross platform IDEs. If you use the portable version when you finish you create a zip file and in 2 years when you want to change it you open it on any machine windows/linux it will most likely work.
        It also doesn’t install for an hour and it doesn’t take 5minus to turn on.

        1. Atmel Studio is, by far, the worst of the brand-name IDEs. I’ve had nothing but problems with AVR Dragon drivers, weird toolchain issues, and the like, so I completely agree with you (notice I didn’t mention Atmel in my comment you replied to). My advice would be to try another vendor’s tools (ST is not a good choice, as they don’t really have any vendor tools, other than STM32Cube). Check out the Silicon Labs, Microchip, NXP/Freescale, or TI stuff. I’ve seriously never had any of the problems you’re talking about, and *all* of those platforms have Linux support. Look especially at the Silicon Labs stuff. By ticking a checkbox, peripheral libraries / drivers are *copied* (not referenced) into your project. Easy to switch between local toolchain versions (same with MPLAB). Seems to start up and run reliably on a modern computer as well as any other engineering software.

  7. Sadly, both of the editors are based on Chromium which means blurry fuzzy fonts. VSCode has no support for turning it off and atom I could never get it to actually turn it off. I like the crisp bitmap fonts of SublimeText and thus will be sticking with it.

  8. Glad to see Platformio finally get some attention here. Very well deserved. I’ve never been a fan of PlatformIO IDE (probably mostly because I am not a fan of Atom) but I love the CLI core which I think is where all the important bits are anyway.

  9. The Video from @Al Williams focus on Atom, I tried here to focus on VSCode, and also to understand what’s under the hoods of PlatformIO, what does it bring, and what is coming from mBed or from ST, well I was nicely surprised, respect for the platformIO contribution of integrating everything together with a one click install plus all of the compilation and framworks management. So here are lots of details, I even started debugging with VSCode then got stuck :

  10. I been using platformio for many months now. It’s a rather unique tool in its effort to pull together such disparate ecosystems. It’s an enormous timesaver, as has been alluded to already, bypassing all the nitty-gritty of these toolschains. Not only that, but the community and creator support is quite responsive – which is itself an enormously important factor.

    The library management is the most thought out I’ve seen in any embedded environment, and there’s even a little bit of makefile-like behaviors for tracking which source files get included if you don’t want it to autodiscover (default behavior) your stuff.

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.