You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
B6: parity check - PlatformIO build vs the arduino-cli baseline #188
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:
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_type is wrong, PSRAM vanishes silently and both the draw buffers and the LVGL heap fail at runtime, not build time
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:
build
Flash
RAM
arduino-cli
1,787,670 (61%)
106,372 (32%)
PlatformIO (dev box)
1,855,926 (64.4%)
103,232 (31.5%)
delta
+68,256
−3,140
A third measurement now complicates that. Building the same source with the same
pinned lib_deps under PlatformIO, but from an empty PLATFORMIO_CORE_DIR — i.e. what
CI will do — gives:
build
Flash
RAM
PlatformIO, dev-box core dir
1,855,926 (64.4%)
103,232
PlatformIO, clean isolated core dir
1,859,542 (64.5%)
103,232
delta
+3,616
0
Same toolchain family, same platform pin (55.03.38-1), same lib_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:
Control for environment. Compare from equivalent starting states — ideally both
toolchains from clean, isolated package directories — rather than whatever each happens to
have cached locally.
Attribute the 3,616 bytes first. It is the smaller, more tractable instance of the same
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.
Compare symbols, not totals.B4: src/ include/ lib/ layout - behaviour-neutral #186 established that identical totals do not prove
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:
PLATFORMIO_CORE_DIR=<empty dir> pio run -e feather_s3
Note it must run from PowerShell or cmd — PlatformIO refuses to run under MSYS/Git Bash.
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:
build
Flash
RAM
dev box — Windows, warm core dir
1,855,926
103,232
CI — ubuntu-latest, fresh
1,856,502
103,232
clean core dir — Windows, isolated
1,859,542
103,232
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.
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.