B6: parity check - PlatformIO build vs the arduino-cli baseline #188
Description
Recreated from Strycher/Field_Compass-archive#188 — originally opened by @Strycher on 2026-08-09. Credentials redacted where present.
Epic: #154
Compare the PlatformIO artifact against the known-good arduino-cli build before anything is flashed.
The baseline exists now - it did not when this was planned
This task was written against "the known-good arduino-cli binary", which did not exist: main would not link (#164). It does now. Baseline, from the image currently running on the device:
Flash: 1,815,046 bytes (62%)
DRAM: 103,096 bytes (31%), 224,584 free
Live confirmation via /diags: PSRAM 1765K / 2048K, Free Heap 136,628, Render: LVGL 9.5 (2x46KB PSRAM buffers).
Compare
- Flash and DRAM within a documented tolerance - a large divergence means the toolchains disagree about something material
- PSRAM actually present. If B1's
memory_typeis wrong, PSRAM vanishes silently and both the draw buffers and the LVGL heap fail at runtime, not build time - Partition layout and flash mode
Acceptance criteria
- A written comparison table attached to this issue
- Every delta explained, not merely observed
- Explicit go/no-go recorded before B7: Epic B integration test — PlatformIO build on hardware #161 flashes hardware
Activity
Strycher commentedon Sep 7, 2026
@Strycher — 2026-09-06
Scope addition: build environment is a variable, not just toolchain
Folded in per owner decision, from the CI diagnosis (#219,
docs/ci-diagnosis.md).B6 exists to explain the PlatformIO ↔ arduino-cli delta:
A third measurement now complicates that. Building the same source with the same
pinned
lib_depsunder PlatformIO, but from an emptyPLATFORMIO_CORE_DIR— i.e. whatCI will do — gives:
Same toolchain family, same platform pin (
55.03.38-1), samelib_deps, identical RAM.Only the core directory differed.
Why this changes B6's method
B6 was scoped to compare two build systems. This shows the environment alone moves flash
by kilobytes on identical source. So a raw PlatformIO-vs-arduino-cli number is confounded:
some unknown share of the 68 KB may be environmental rather than attributable to the build
system.
B6 should therefore:
toolchains from clean, isolated package directories — rather than whatever each happens to
have cached locally.
question, and whatever explains it probably explains part of the 68 KB. Candidates, none
proven: differing resolved toolchain/framework patch versions between core dirs, or
build-path length affecting embedded strings — the isolated path is substantially longer.
identical output: symbol set, sizes and types were identical across 14,958 symbols while
608 addresses shifted purely from link order. Totals are the weakest available evidence.
Consequence for CI and for E4
CI output will not be byte-identical to a local build. Any verification that compares
build artifacts — including E4's per-extraction harness (#212, task 1.4) — must compare
like-for-like environments, or compare symbol sets rather than size totals.
Reproduce:
Note it must run from PowerShell or cmd — PlatformIO refuses to run under MSYS/Git Bash.
Strycher commentedon Sep 7, 2026
@Strycher — 2026-09-06
Third data point: CI, measured
Field Compass's first green CI run (PR #235, run 34025968299) gives a third measurement of the same source with the same pinned
lib_deps:RAM is byte-identical across all three. Flash spans 3,616 bytes.
Two things this adds to the earlier finding:
It is not the operating system. The ubuntu CI build lands closer to the Windows dev box (+576) than the Windows isolated-core build does (+3,616). If OS were the variable, the two Windows builds would agree. They do not. That points at package/toolchain resolution or build-path length, and away from platform.
CI output is not byte-identical to any local build. This matters beyond B6: E4's per-extraction verification harness (Epic E4: break src.ino into translation units #212, task 1.4) cannot compare a CI artifact against a local one by size totals. It must compare like-for-like environments, or compare symbol sets — which B4: src/ include/ lib/ layout - behaviour-neutral #186 already established is the stronger check anyway, having found 608 shifted addresses across 14,958 identical symbols.
CI now pins PlatformIO to 6.1.19 (C1, #221), so the CI figure is at least reproducible going forward. The dev box and isolated-core builds used the same 6.1.19, so the tool version is not the variable either.
Reproduce the CI number: any run of
.github/workflows/compile.yml. Reproduce the isolated one:PLATFORMIO_CORE_DIR=<empty dir> pio run -e feather_s3, from PowerShell — PlatformIO refuses to run under MSYS.