Join my daily Newsletter

Subscribe to get my latest content by email.

    I respect your privacy. Unsubscribe at any time.

    preloader

    Why I dislike PlatformIO

    • Sunday, Dec 18, 2016
    blog-image

    Update: I’ve created a new post with a much better argument. This post will stay around for completeness.

    What is PlatformIO?

    In their own words: “PlatformIO is an open source ecosystem for IoT development Cross-platform build system. Continuous and IDE integration. Arduino and ARM mbed compatible”

    I’m still trying to figure out the definition of “ecosystem” in this context, given what I’ve seen. I wonder if when the creators of PlatformIO find a more concrete noun, their product would also become more concrete.

    I’m very much at odds with it, mostly out of rejected enthusiasm. It feels like it should be an excellent arrow in my quiver, but every time I take a closer look, I’m dismayed with it.

    I’d *really* like to like it, but I can’t.

    In my very personal opinion, it can’t decide what it is, and thus ends up being several things, badly.

    What do I mean by “undecided”?

    Its proponents will be quick to tell you how many things it can do for you:

    • it has an IDE
    • it tries to be most things a build system is
    • It provides a convenient interface to your embedded boards
    • it offers a library manager

    When I tried it out I was rather enthusiastic about how smooth, simple

    and just plain modern everything was. For at least ten minutes. Then it kinda came apart for me.

    Let’s discuss the features in more detail.

    The IDE

    I’m not sure why I need yet another IDE. I suppose most developers have already found one they are happy with. Also: IDEs delivered by vendors are famously annoying. Many not-delivered-by-vendors ones are also terrible (looking at you, Eclipse). This makes me immediately suspicious, through no fault of PlatformIO.

    However, since they thankfully don’t force me to use it at all, I don’t mind it. Perhaps developing it binds resources that they could better use elsewhere, but whatever. It’s fine. It’s just not particularly relevant.

    The library manager

    Again, that’s very nice, but kind of orthogonal to everything else.

    Its value is also rather limited outside the hobbyist market (end even inside it). After all, how often do you need to shop for new libraries, unless (and even if) you’re a hobbyist trying out a bunch of things?

    Automating this process saves you minutes (yes! minutes!) every, uh, few months, when you need to incorporate something new.

    Sarcasm aside, unless you have extremely quick project turnaround, and no commonalities between your projects, its use is limited.

    In practice you figure out your libraries once, and that’s it. If you need to find and add a new one, it’s not such a huge deal.

    I’m also suspicious of it, because it seems to force me into a particular project structure, which may or may not fit my project.

    The embedded baord interface

    This is a part I actually like.

    It relieves me of the inconvenience of having to fiddle with upload settings. Together with some of their other offerings, like the embedded unit test framework (which runs test on the target hardware), it shows considerable promise.

    I only tried flashing, and only on on one board, but there it all worked smoothly. I expect the others will be similarly nice.

    The build system

    I’ve saved the juiciest point for last: the build system.

    PlatformIO offers targets for building, testing (only since version 3 — see my rant on that subject) and uploading to embedded targets. Given you keep to their conventions, this works pretty well. Very nice.

    Very quickly though, I found a big red flag: it completely lacks the flexibility of a generic system such as make or Cmake, but at the same time seems to have no decent way of integrating itself into one.

    Not reinventing the wheel is actually the correct approach: I don’t need yet another build system. I’ve got plenty of well-tested ones to choose from. When I need make’s functionality, the rational course of action is to simply use make (or one of its cousins).

    In fact, PlatformIO is based on a build system called SCons (which I have no experience with, but it seems to be quite decent).

    However, PlatformIO attempts to be the only thing you need to build your product. Yet all it offers to users is ways to build and upload. This is a very ’90s perspective on software development: all you need to do is write code, and voilà, your product is finished.

    PlatformIO Plus, their paid variant, at least incorporates unit-testing — using a framework they supply.

    Using their framework gives the nice advantage of being able to run unit tests on the target hardware without having to rig something. For everyone who has ever tried it, this will be a relief.

    However, it would be nice (for green-field projects) or vital (for brown-field projects) to be able to integrate other test frameworks easily.

    According to their marketing page, PlatformIO Plus also claims to support static analysis, but there is no trace of this in the documentation (even the search function comes up empty), and concrete details are nowhere to be found.

    There’s also a “ci” command, which is aimed at continuous integration systems. It might just be me, but I don’t understand how to use it (the documentation is a bit confusing).

    More importantly, I don’t understand why to use it. I want my build system to behave identically on my dev machine and on my CI server, so I should be using the same set of commands at all times. This command actually feels like a bad idea.

    This last argument seems a bit characteristic of PlatformIO: good ideas, very good intentions, but somehow not completely thought through.

    Summary

    It’s not clear to me how to integrate other tools or build steps, and generally adapt it to my development process. This is the fundamental thing that breaks PlatformIO to me.

    I can’t find a link now, but when I tried to figure out unit testing in PlatformIO 2.x, the PlatformIO team seriously suggested using a separate Makefile to build and run the test targets. I worry that this failure to anticipate and adapt to other peoples’ use of PlatformIO got baked into the architecture of the product.

    The kind of hand-holding they provide is fine for beginners and hobbyists (much like Arduino was a tremendous positive impulse on the embedded community), but there needs to be a clear path to grow out of it.

    I assume I can somehow extend PlatformIO, as it’s based on SCons. But there is no guidance in the documentation on how to accomplish this. It also means that PlatformIO forces me to use a particular build tool that I may not know, instead of going for one me and my team are familiar with.

    I think that a few of the issues I have could be alleviated by better documentation, and I wouldn’t be surprised if I missed options that PlatformIO in fact gives me (but if I can’t find them, they are essentially nonexistent).

    The verdict

    However, the true problem is more fundamental: in its current form, I can’t see this being a tool that’s suitable for professional, or serious hobbyist development. It give me no clear path to use as much or as little of it as makes sense to me, and to revise this choice later. For all its other virtues, this is a deal-breaker for me.