Three src.ino comments cite an 80MHz TFT bus that the repo has no evidence ever existed

[Strycher]

_{Recreated from Strycher/Field_Compass-archive#242 — originally opened by @Strycher on 2026-09-07. Credentials redacted where present.}

Epic: #155
Feature: #217

Found while auditing #224. Filed rather than folded in, because the comments carry #116's rationale and correcting them is a claim about hardware history, not a text fix.

The discrepancy

src/src.ino:1054   "allowing 80MHz TFT traffic to corrupt idle SPI slaves"
src/src.ino:5170   "bus speed conflicts with TFT_eSPI running at 80MHz"
src/src.ino:5313   "stale bus state from TFT_eSPI's 80MHz DMA transfers"
platformio.ini:123 -D SPI_FREQUENCY=40000000
docs/HARDWARE.md:140,215  40 MHz

What the history actually shows

• 09f30d6 (2026-02-25, SD card intermittent mount failure #116) introduced both the 80MHz claim and SD's explicit 10MHz, in the same commit. The 80 appears as stated rationale, never as a transcription of a config value.
• 5fc8686 (same day) dropped SD 10MHz to 4MHz, "maximum reliability on shared bus", leaving the 80MHz text untouched. So the empirical move was go slower until it works, not a ratio computed from 80.
• At that time TFT_eSPI's configuration was not in git. It lived in three files in the Arduino libraries directory — User_Setup_Select.h, User_Setups/Setup_Field_Compass_ESP32S3_ST7789.h and an edited User_Setup.h. A library reinstall wiped them, which is why B2: TFT_eSPI config via build_flags - retire the out-of-repo setup headers #184 exists. Nobody can now read what SPI_FREQUENCY they held.
• When B2: TFT_eSPI config via build_flags - retire the out-of-repo setup headers #184 transcribed the active header into build_flags, it read 40 MHz.
• The only 80000000 anywhere in the repo is board_build.f_flash = 80000000L — the flash chip clock, not the display bus.

The likely explanation, unproven

80MHz is TFT_eSPI's commonly cited ESP32 maximum, and it is also this board's flash frequency. Either is an easy source for a number written from memory rather than read from the header. But the authoritative file was outside git at the time, so this cannot be settled from the repo.

What is NOT in doubt

The 4MHz SD frequency is sound regardless. It was reached empirically — 10MHz proved unreliable, 4MHz did not — not derived from the 80 figure. Correcting the comments does not call for any behaviour change, and this issue proposes none.

Acceptance

• Determined whether 80MHz was ever the configured TFT SPI frequency, or record that it cannot be determined and say so in the comment rather than silently swapping the number
• The three comments state the actual configured frequency and describe SD card intermittent mount failure #116's rationale as empirical
• If any external record survives (OneDrive sketchbook backup, an old User_Setup copy, issue SD card intermittent mount failure #116's own discussion), cite it

Do not

Change SD_SPI_FREQ, SPI_FREQUENCY, or any timing. This is a documentation-truth issue on working firmware.