know.2nth.ai Technology tech embedded platformio
tech/embedded · PlatformIO · Skill Leaf

One CLI for every board.

PlatformIO is a unified embedded development platform — a single CLI, a single config file, and a single build system that covers 1000+ boards from ESP32 to STM32 to RP2040. It replaces the Arduino IDE's limited toolchain, vendor-specific SDKs, and hand-rolled Makefiles with one platformio.ini and pio run. Build, upload, test, debug, and manage libraries without leaving the terminal or VS Code.

Live Python · C/C++ Apache 2.0 CLI + IDE 1000+ boards

A build system, package manager, and device manager for embedded.

PlatformIO Core is a Python CLI that wraps GCC cross-compilers, vendor SDKs, and upload tools behind a single interface. You declare your board, framework, and libraries in platformio.ini; PlatformIO downloads the right toolchain, resolves library dependencies, compiles your source, and uploads the binary. One command does what used to require four separate tools and three different vendor portals.

It runs headless in a terminal for CI/CD, or inside VS Code with a first-party extension for interactive development. The same project builds on macOS, Linux, and Windows without a single change to the config file.

Why this matters for DroneScan + ScanMan Hive

DroneScan drones carry embedded controllers (ESP32, STM32) for barcode capture, flight control, and comms. ScanMan Hive's robot-ready architecture expects ground AGVs and aerial drones to hit the same REST endpoint. PlatformIO is the firmware pipeline that gets the scan logic onto the silicon — and keeps it updated across a fleet of 50 drones without manual USB uploads.

The embedded toolchain problem is a vendor lock-in problem.

Every silicon vendor ships their own IDE, their own SDK, their own build system. Espressif has ESP-IDF. ST has STM32Cube. Nordic has nRF Connect. Arduino has the Arduino IDE. A team building firmware for two boards needs two toolchains, two library ecosystems, and two ways of doing the same thing.

PlatformIO collapses that into one. Your platformio.ini declares which boards and which frameworks; PlatformIO handles the rest. Switch from ESP32 to STM32 by changing two lines, not two toolchains. Run the same unit tests on a native host and on real hardware from the same test directory. Ship the same CI pipeline regardless of the target MCU.

Without PlatformIOWith PlatformIO
One IDE/SDK per vendorOne CLI, one config, every vendor
Manual toolchain install per OSpip install platformio
Library copy-paste or submoduleslib_deps in platformio.ini
No CI without custom Docker buildspio run on any CI runner
No unit tests or native simulationpio test -e native

platformio.ini is the unit of everything.

Sound familiar? Frappe has doctypes. PlatformIO has environments. One config declares the full build context — board, framework, libraries, flags, upload method, test targets. The CLI reads that config and does the work.

; platformio.ini — DroneScan Hummingbird firmware
[platformio]
default_envs = hummingbird

[env:hummingbird]
platform    = espressif32
board       = esp32-s3-devkitc-1
framework   = arduino
monitor_speed = 115200
upload_speed  = 921600
build_flags =
    -DBOARD_HAS_PSRAM
    -DDRONESCAN_UNIT=HUMMINGBIRD
    -DHIVE_ENDPOINT=\"https://api.hive.scanman.co.za\"
lib_deps =
    bblanchon/ArduinoJson@^7.0.0
    knolleary/PubSubClient@^2.8

[env:meerkat]
platform    = espressif32
board       = esp32dev
framework   = arduino
build_flags =
    -DDRONESCAN_UNIT=MEERKAT
    -DHIVE_ENDPOINT=\"https://api.hive.scanman.co.za\"

One repo, two products. The Hummingbird (aerial drone, ESP32-S3 with PSRAM) and the Meerkat (ground unit, standard ESP32) share the same source tree. The [env:...] block is the only thing that changes. pio run -e hummingbird builds one; pio run -e meerkat builds the other. Both firmware binaries post scan events to the same ScanMan Hive scan_event endpoint.

More than a build tool.

PlatformIO is a platform: CLI, IDE extension, package registry, board database, CI integration, and remote device management. Each piece earns its place.

ComponentWhat it does
pio runBuild firmware for any board with one command
pio testRun Unity tests on-device or native (desktop)
pio device monitorSerial monitor with ESP32 exception decoder
pio pkgLibrary + platform package manager with semver
VS Code extensionIntelliSense, build tasks, serial monitor, debugger
PlatformIO Registry14 000+ libraries searchable by board, framework, keyword
PlatformIO RemoteUpload and monitor over the network — OTA for dev
CI integrationGitHub Actions, GitLab CI, Jenkins — just run pio run

Where this lands in the 2nth stack.

DroneScan Hummingbird + Buffalo + Meerkat firmware

One PlatformIO repo with three [env] blocks builds firmware for all three DroneScan product lines. Shared barcode-capture logic, shared Hive endpoint integration, per-product flight controller and motor driver config. CI runs pio run on every push; binaries land in R2 ready for OTA.

ScanMan Hive IoT edge devices

Temperature, humidity, and door-open sensors in cold-chain warehouses. Each sensor posts scan events to the same scan_event API a picker's phone or a DroneScan drone uses. PlatformIO builds the firmware; Cloudflare Tunnel routes the MQTT broker back to the Hive.

Rapid MCU prototyping

Client hands you an ESP32-S3 devkit and says "make it scan a barcode and talk to our ERP." PlatformIO lets you go from zero to uploading in under 10 minutes: pio project init --board esp32-s3-devkitc-1, add a barcode lib, write 40 lines of C++, pio run -t upload.

From Arduino IDE to cloud-native firmware CI.

PlatformIO started as a CLI alternative to the Arduino IDE. It has evolved into the embedded equivalent of what npm + webpack became for JavaScript — the standard toolchain that everything else plugs into.

EraToolchainLimitation
2005–2014Arduino IDESingle board, no library management, no CI, no tests
2014–2018PlatformIO Core + CLIMulti-board, unified build, early library registry
2018–2022PlatformIO + VS Code + CIIntelliSense, debugging, GitHub Actions pipelines
2022–nowPlatformIO + Remote + FleetOTA dev, remote monitoring, fleet firmware management

When to use it. When to skip it.

PlatformIO is not always the right tool. If you're deep in a vendor-specific SDK with custom drivers that don't port, forcing PlatformIO into the middle adds friction for no gain.

Use when

  • You target more than one board family (ESP32 + STM32, or Hummingbird + Meerkat)
  • You want CI for firmware — build on every push, test on a native host
  • You need reproducible builds across macOS, Linux, and Windows
  • You want library management with version pinning, not copy-paste
  • You want to write tests that run without flashing hardware
  • You want one toolchain for a fleet of heterogeneous devices

How this node connects in the tree.

PlatformIO is the firmware layer underneath DroneScan's fleet. When a Hummingbird drone hits the ScanMan Hive scan_event endpoint, the firmware that captured the barcode, compressed the image, and posted the HTTP request was built by PlatformIO. The platform connects downward to silicon and upward to the Hive.

partner/dronescan
DroneScan Fleet
Hummingbird, Buffalo, Meerkat, and RFID firmware is built with PlatformIO. One repo, multiple [env] blocks, one CI pipeline. The firmware posts scan events to ScanMan Hive.
partner/scanman-hive
ScanMan Hive
The Frappe-native WMS that receives scan_event payloads from PlatformIO-built firmware. The device_type: "Aerial Robot" or "Ground Robot" field on every WMS Transaction traces back to the firmware that sent it.
tech/cloudflare/workers
Cloudflare Workers
Firmware OTA binaries live in R2. A Worker serves the latest build to drones checking for updates. The update check is an HTTP GET to a signed URL — same Cloudflare edge, different surface.
tech/frappe/framework
Frappe Framework
The @frappe.whitelist() endpoint the drone firmware calls. PlatformIO builds the client; Frappe serves the API. The boundary between embedded C++ and server-side Python is one HTTP POST.
tech/embedded/esp-idf
ESP-IDF
Espressif's native SDK. PlatformIO wraps it as a framework option (framework = espidf). For DroneScan hardware that needs FreeRTOS-level control, ESP-IDF is the framework; PlatformIO is still the build system.
data/mqtt
MQTT
IoT sensors and some drone telemetry use MQTT rather than HTTP. PlatformIO firmware pulls in PubSubClient or AsyncMqttClient from the registry. The MQTT broker routes through Cloudflare Tunnel to the Hive.

Go deeper.

The PlatformIO docs are comprehensive. The registry is the fastest way to find a library for any board. The GitHub is actively maintained and responsive on issues.