Three things the solution got wrong, all found by opening it in the GUI rather
than building it headlessly.
The project listed only main.cpp, so none of the headers could be opened from
Solution Explorer. Every source and header is listed now, with <Link> mirroring
the on-disk src/ layout, which is what master's project did.
Neither configuration compiled in the GUI: libavr was found through
$(LIBAVR_ROOT), and a variable exported in a shell is not visible to Studio
launched from the Start menu. Release only looked healthy because its objects
were already up to date from a headless build. The path is now anchored to the
project directory, which also side-steps a second trap: a plain relative include
is resolved against the generated makefile's own directory, the configuration's
output directory, not the project's. Pinning libavr as a submodule would remove
the assumption that the two sit side by side, and is on libavr's task list.
Both configurations verified with LIBAVR_ROOT deliberately unset, Release still
byte-identical to the CMake build and the flag gate still green. Debug's own
translation unit carries DWARF-4 as intended.
Studio's per-user state under ide/.vs/ and the build logs are ignored.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
master opens in Studio, so this branch should too. One project, the port's own
chip, flags mirrored by hand against the CMake build — and the acceptance is
not that it builds but that it builds the same firmware: .text (7094 B) and
.data (336 B) come out byte-identical to the CMake output from the same
sources.
libavr is found through $(LIBAVR_ROOT), the variable the CMake build already
uses, so no machine path is committed; Studio expands it from the environment.
The toolchain is named by flavour only, since nothing Studio ships can compile
-std=c++26 and the path to one that can is per-machine state.
The componentinfo file the project cannot load without is generated by
libavr's tools/atmelstudio/componentinfo.py and ignored here, as are Studio's
output directories. Release is what the flag gate compares, the presets
defining no debug build; Debug carries the -Og -gdwarf-4 pair libavr's own
debug preset uses.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Both headers described the port transformation ("legacy cubic becomes",
"no hand-rolled series needed") rather than what the code is. State the
cubic and the __builtin_log rationale directly.
Co-Authored-By: Claude <noreply@anthropic.com>
The thermistor Beta curve and the fan cubic move onto avr::flash_table
instead of hand-rolled [[gnu::progmem]] arrays with raw pgm_read, and
the compile-time logarithm uses __builtin_log (which constant-folds on
the AVR backend) instead of a hand-rolled series. Same 11284 B, still
byte-identical across libavr modes.
Co-Authored-By: Claude <noreply@anthropic.com>
Same controller: thermistor on ADC0 averaged over 1000 free-running
conversions, 50 kHz fan PWM on OC0B, 115200 Bd console with the full
command set, EEPROM temperature histogram, watchdog-reset path into the
boot section. The Steinhart-Hart math and the libm log are gone — the
Beta equation and the cubic fan curve are consteval-evaluated into
flash tables; the firmware never does floating point. Byte-identical
.text in both libavr modes. Legacy stays on master.
Co-Authored-By: Claude <noreply@anthropic.com>
BlackMarkandClaude Opus 5