Why Use PlatformIO Over CMake for Embedded Development

So, your Arduino sketch is a mess. It’s 3,000 lines of spaghetti code. You can’t read it, you can’t debug it, and you’re afraid to touch it.

You did the smart thing: you broke it up. You moved to VS Code, split your code into MotorController.cpp, SensorFusion.cpp, and Pathfinding.cpp. You’re acting like a pro.

But now you have a new headache: The Build System.

If you ask the C++ subreddit how to compile this, they’ll scream “CMake!” at you. For desktop apps, they’re right. CMake is great for that.

For robotics? It’s a trap. It’s an over-engineered nightmare that will waste your time. You want to build robots, not debug build scripts.

Here is why you should ignore the purists and just use PlatformIO.

Cross-Compilation Sucks

If you’re building a desktop app on Linux, CMake is easy. It finds g++, compiles your code, and you’re done.

But your robot isn’t running an Intel i7. It’s running an STM32, an ESP32, or an Arduino Mega. Your PC can’t run that code directly. It needs to Cross-Compile.

If you use raw CMake, you have to deal with this:

Find and download the exact right compiler (toolchain) for your chip.
Tell CMake exactly where that compiler lives.
Manually set a dozen flags like -mcpu=cortex-m4 and hope you didn’t make a typo.

The CMake Way (The Hard Way):

You end up with a massive CMakeLists.txt and a toolchain.cmake file that looks like alien hieroglyphics.

# Just to get started...
cmake_minimum_required(VERSION 3.13)
set(CMAKE_TOOLCHAIN_FILE external/toolchain-arm-none-eabi.cmake)
project(MyRobot C CXX ASM)

# Listing every... single... file...
add_executable(robot.elf src/main.cpp src/motor.cpp src/sensor.cpp)

# And linking manually...
target_link_libraries(robot.elf PRIVATE some_math_lib HAL_driver)

Mess up one flag? Your code compiles but crashes immediately. Have fun debugging that.

Why PlatformIO Wins

PlatformIO isn’t just a VS Code plugin. It’s a build system designed specifically for this embedded madness. It hides the ugly stuff so you can work.

1. `.ini` vs Scripts

CMake is a scripting language. You have to write code to tell it how to build your code. PlatformIO is declarative. You just tell it what hardware you have.

The PlatformIO Way:

platformio.ini:

[env:esp32dev]
platform = espressif32
board = esp32dev
framework = arduino
upload_speed = 921600

That’s it. PlatformIO sees “esp32” and does the rest. It downloads the compiler, sets the flags, finds your files, and links them. Done.

2. It Manages the Toolchains For You

This is the killer feature.

In a normal C++ project, if your teammate joins, they have to spend a day installing compilers and setting paths. With PlatformIO? They clone the repo and click build. PlatformIO downloads the toolchain automatically to a sandbox inside the project. It works identically on Windows, Mac, and Linux. No “it works on my machine” excuses.

3. The Library Manager

Need an MPU6050 driver? Old way: Download zip -> Extract -> Fix include paths -> Link -> Pray. PlatformIO way: Add one line.

lib_deps =
    adafruit/Adafruit MPU6050 @ ^2.2.4

It finds it, downloads it, and links it.

4. Real Structure

PlatformIO forces you to stop being messy. It gives you a standard structure:

lib/ - Your private libraries
include/ - Headers
src/ - Source code

It trains you to be a better developer.

5. Proper Debugging

Since it runs in VS Code, you get real IntelliSense (not the fake Arduino one). And if you have a debugger probe like an ST-Link, you can do real hardware debugging. Set breakpoints, step through code, see memory.

Try setting that up with GDB and CMake manually. I dare you.

Conclusion

Building a desktop app? Use CMake. Building a robot? Use PlatformIO.

Don’t waste 3 days writing a build script. Spend that time making your robot actually work.

Note: If you need deep kernel debugging or prefer the full Visual Studio IDE (not VS Code), check out VisualGDB. It costs money, but it’s powerful. For everyone else, PlatformIO is the answer.