BlackMark
2cdf56f8d6
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>
58 lines
2.5 KiB
Markdown
58 lines
2.5 KiB
Markdown
# fantemp
|
||
|
||
Temperature-controlled fan firmware (ATmega328P, 16 MHz), rewritten on
|
||
[libavr](https://git.blackmark.me/avr/libavr): thermistor on ADC0 sampled
|
||
free-running and averaged over 1000 conversions, fan on OC0B at 50 kHz,
|
||
115200 Bd serial console (`help` lists the commands), temperature
|
||
histogram persisted to EEPROM, watchdog-reset path into a boot-section
|
||
bootloader.
|
||
|
||
The Steinhart–Hart math of the legacy firmware (runtime doubles + libm
|
||
log) is gone: the Beta equation and the cubic fan curve are evaluated
|
||
consteval into flash tables — the firmware itself never touches floating
|
||
point.
|
||
|
||
Build against a libavr checkout:
|
||
|
||
```sh
|
||
LIBAVR_ROOT=/path/to/libavr cmake --preset atmega328p-generated
|
||
cmake --build --preset atmega328p-generated
|
||
```
|
||
|
||
## Atmel Studio
|
||
|
||
`master` carries a Studio solution, so this branch does too: `ide/fantemp.atsln`
|
||
builds the same firmware — byte-identical `.text` and `.data` to the CMake
|
||
build — from the same sources, with the flags mirrored by hand.
|
||
|
||
Studio expects libavr checked out **beside this repo**, and finds it at
|
||
`$(MSBuildProjectDirectory)\..\..\libavr\include` — anchored to the project
|
||
rather than written relative to the generated makefile, which runs from the
|
||
configuration's output directory and would need a different number of `..`.
|
||
Unlike the CMake build there is no `LIBAVR_ROOT` to point elsewhere: an
|
||
environment variable set in a shell is not visible to Studio launched from the
|
||
Start menu, which fails as a missing `libavr/libavr.hpp` rather than as anything
|
||
about the variable. Pinning libavr as a submodule is the better answer and is on
|
||
libavr's task list.
|
||
|
||
It also needs a GCC 16.1 toolchain registered as flavour `avr-g++-16.1.0`;
|
||
nothing older can compile `-std=c++26`.
|
||
|
||
One generated file is required before the project will load, and one command
|
||
checks the flags have not drifted (both from libavr's `tools/atmelstudio/`):
|
||
|
||
```sh
|
||
python ../libavr/tools/atmelstudio/componentinfo.py \
|
||
ide/fantemp.componentinfo.xml --device ATmega328P
|
||
python ../libavr/tools/atmelstudio/check-flags.py --solution ide/fantemp.atsln \
|
||
--compile-commands build/atmega328p-generated/compile_commands.json \
|
||
--log build/atmelstudio.log
|
||
```
|
||
|
||
CMake remains the build system; the solution is there so the project opens in
|
||
Studio as its predecessor did. Only the Release configuration is gated against
|
||
CMake — the presets define no debug build — and Debug carries the `-Og
|
||
-gdwarf-4` pair libavr's own debug preset uses.
|
||
|
||
Legacy (yazoalfa submodules) stays on `master`.
|