Electronics > Microcontrollers

Rant... Why I dumped Platform IO IDE after a week

(1/26) > >>

Aside from odd projects here and there... Microchip whatevers >>> Rowley Crossworks >>> Kiel uVision >>> Segger Embedded Studio >>> Eclipse CDT and STM32CubeIDE >>> VS Code + PlatformIO >>> VS Code CMake.

I recently decided to dump Eclipse / STM32CubeIDE. While it's a TON better than my previous (Segger Embedded Studio, seriously, that can go to hell), I wanted VS Code but still wanted "support". I wanted tools that were made and maintained by someone. Someone to call on if there was an issue. I'm not paid to play with tooling all day, I'm paid to make things.

My first and last week with PlatformIO...

- There is pretty literally one guy answering questions on their forum. I hope Max is paid, because if he isn't I imagine there is an end to his generosity. This does not count as having someone to call on. Paid support for PIO is absurdly expensive at $250/mo with a 12 month use it or lose it contract. This iirc on the prices, is more than a year of IAR, Keil, and CLion together. That's some lunatic pricing.  (EDIT I swear last week they had a $500 per month no contract, but it's gone now)

- Good luck manually adding a floating point flag. I spent a two days trying to figure out how to get an STM32 to build with floating point. Any other system you click a button, or add -fpv4-16 or some other flag. No, not PIO!! You need to add the flag to the compiler, as well as the linker, but In PIO the config .ini only allows for editing the compiler flags. So... What you need to do is create a python script that will add the flags in a backend way, and then call that flag from the ini file. Complete backwards BS. Why are there no linker arguments in the ini? F U is why, I assume.

- You'll have no options and be happy about it. Similarly, you have access to flags they thought you would want access to. I wanted to add context RTOS awareness to the JLink debugger. Despite a guide saying you can easily to it, adding the "-rtos freertos" didn't work.

- What do you mean multiple ram sections!? A ton of new chips have multiple ram sections like STM32's tightly coupled memory. You can place things in these sections using the linker and gcc compiler options, but PIO is hard coded to only should a build usage percentage chart of RAM and FLASH. Not all ram, or all flash, just one "main" section they per-determine. This is 1990s thinking, at best. No great way to fix it, and it's been on their open issues for at least a year.

- "Will you be able to build the project in 10 years?". EEV Members warn/warned others about this. I say no. I could barely build today, and that was not using any of their tooling, just bringing my own files in like a big boy. I initially scoffed this warning, but I recant. Their package manager looks nice, but it's trying to do too much. For STM32, they have a hard coded "platform" build script that tries to replace CubeMX and select the files you might need. I don't trust they will maintain it. I decided early to bring my own files in and it was also trouble.

- It probably works well if you still to absolute basics. Using their tools the way they intended. However... At it's root, they're using python scripts to interpret an ini file, then make a SCons config, which makes me wonder why not just use a Makefile or CMake to existing standards? PIO is a build system helper for SCons. I guess when something goes wrong, I'd rather have the millions deep CMake community to ask instead of hoping Max is around.

- It's still vendor lock in. Despite big bullet points saying it isn't. You're in their system or you aren't. You do get the source, but that doesn't mean it's portable or your changes would be maintainable. You're paying for it with your time. They're a vendor, and their system is exclusive. It's not the hardest lock-in I've ever seen. But there was nothing stopping me from dumping Keil and taking my code to GCC, just a couple flags to change here and there.

- Inexplicable limitations. You are forced root source folder for your code. They build from multiple folders and libraries, but give you access to only one root folder. If you have configurations for two micros, and one folder must be excluded, you are expected to add both to the root source folder, then add a build flag to explicitly exclude the "wrong" folder per build. Backwards and they easily could have selected an "opt-in" system for source files, like every other build tool ever.

- .C or .S files, pick one. You can not have both with the same name, ever, anywhere. Annoying that in STM32 you may have a .C or .S option with the same name. Startup is one example but in the CMSIS folders there are a few more. PIO just can't handle this. Goes back to the single root source folder, and that everything inside will try and be compiled whether you want it to or not.


1. They're trying to be Arduino. I would only rank it slightly above.

2. I don't think the current development is very active. Blame the war in Ukraine if you want.

3. It took me longer to try and learn PIO and it's odd .ini system and workaround than it did to open VSCode, install all the extensions I wanted, and create a CMake file. That's the worst thing I can say about PIO and why I'll probably never recommend it.

I don't regret trying it. I have a great setup now in VS Code. I finally feel like my embedded tooling isn't perpetually 15 years in the past.

My personal favorite: CLion + CMake. But CLion is not free. And their embedded support is far from done (still waiting for disassembly listing panes and live CPU register views -- need to debug with gcc objdump and gdb commands). But their C/C++/general programming tool suite is very well regarded/supported..

I agree with your findings. And I can rant along too. PIO... I've tried it, and my first impression: it's a steaming pile of ****. I like the Arduino IDE more because it does less things and doesn't get in the way. I hate when embedded tools try to be "automagic" but then get it wrong. It's a general theme IMO in your comments. It's a 1-size-fits-all approach which only works in the software world where you can say "this software runs on any Windows 7 or later system".

I've tried to build a custom IOT application based on the Tasmota project, and I don't think I can fault the Tasmota guys for how crappy PIO is. For mysterious reasons, the upload_port will never change even when I manually set it in ALL the .ini files with CTRL+F search in the project folders and brute-force replaced them all. It still defaults to COM5. I'm not even on Windows(!), and there is absolutely no mention in ANY file of "COM5".  |O

Eventually I gave up on trying to fix PIO, so I hacked in the correct serial port right at the exception line in one of those python scripts. It worked.. but then rebuilding a project takes forever. Now this may be because of the large Tasmota project size, but I was really not amused by an almost 2 min build/upload cycle... IIRC it kept rebuilding libraries and trying to link this huge 1MB final binary :-//. I rather spend my energy on writing an Arduino sketch with a basic MQTT library and handing over data via a handful of published/subscribed topics.

why i dumped platform io after one hour: it should be self explanatory. How do people stand that pile of garbage? I couldn't make sense of anything, the workflow, how to know when things are being done, everything seems like an hack upon another hack.

I'd rather have poor documentation, but at least one hello world C project that actually builds and works so i can make sense of things one little step at a time

Sal Ammoniac:

--- Quote from: jnz on September 07, 2022, 05:16:05 pm ---Segger Embedded Studio, seriously, that can go to hell
--- End quote ---

I'm curious...what did you not like about Segger Embedded Studio (and presumably Rowley CrossWorks)?


[0] Message Index

[#] Next page

There was an error while thanking
Go to full version
Powered by SMFPacks WYSIWYG Editor
Powered by SMFPacks Advanced Attachments Uploader Mod