Skip to content

B6: parity check - PlatformIO build vs the arduino-cli baseline #188

Open

Description

@Strycher

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_type is 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

Activity

  1. Strycher commented on Sep 7, 2026

    @Strycher
    OwnerAuthor

    @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:

    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:

    1. 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.
    2. 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.
    3. 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.

  2. Strycher commented on Sep 7, 2026

    @Strycher
    OwnerAuthor

    @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:

    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:

    1. 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.

    2. 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions