avr/ds3231
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

deps: the libavr pin advances, and this repository gets a committed gate

Browse Source 
The pin moves to libavr's USI I2C rate fix and to the two override surfaces the
fan-controller port filed - a PWM solve that can be pinned, and a capture edge
that is a value rather than a template argument. Nothing here names any of
them; four presets green and no image moved.

`tools/check.sh` is new, and its absence was the defect: this repository had no
committed gate at all, so "run the suite" was a snippet somebody remembered -
and the order in a snippet is the one thing nobody re-derives. Every preset
built before any is tested is subtle and load-bearing, because the
mode-identity check reads the sibling mode's tree and a build-then-test-per-
preset run holds a fresh image against a stale sibling. The loop is libavr's
`tools/check-presets.sh`; nothing is written after the call, there being nothing
beyond the presets this repository knows to ask.

And `.vscode/settings.json` stops naming a toolchain prefix. It named
`D:/dev/libavr/local/toolchain/avr-gcc-16.1.0-mingw`: a path true of one machine
(libavr guidance rule 50) and, since the in-repo toolchain copies went, true of
none. `local/machine.cmake` is where a checkout says that, and it already did.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
BlackMark
2026-09-03 02:39:15 +02:00
parent d778383d88
commit 52faaf9920
3 changed files with 18 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
.vscode/settings.json vendored
View File

@@ -14,14 +14,13 @@
"--header-insertion=never"
],
// The presets are the build interface; the toolchain file inside the
// libavr submodule is the one place the compiler is chosen. The submodule
// carries no local/toolchain for it to discover, so the prefix is named
// here, for the window that opens this folder.
// The presets are the build interface, and the toolchain file inside the
// libavr submodule is the one place the compiler is chosen. **No prefix is
// named here**: a committed file may not name a path that is true of one
// machine (libavr guidance rule 50), so the gitignored local/machine.cmake
// at this repository's root is where a checkout says where its toolchain
// is - one file, and it answers for both hosts.
"cmake.useCMakePresets": "always",
"cmake.environment": {
"LIBAVR_TOOLCHAIN": "D:/dev/libavr/local/toolchain/avr-gcc-16.1.0-mingw"
},
"cmake.configureOnOpen": true,
"cmake.options.statusBarVisibility": "compact",