Примеры в интернете либо не компилировались, либо не работали, либо работали через жопу. Ни один из примеров не имел самого главного параметра: погрешности измерений. Один из примеров, автора с какого-то форума, оказался работающим через жопу - но именно на основе этой жопы родился рабочий алгоритм, в т.ч. не требующий никаких инклудов.

Arduino имеет несколько таймеров - акцент сделан на TIMER2, т.к. для него корректно отключается предделитель (понижатель частоты). TIMER2 является 8-битным - обнуляется каждые 256 тиков. В связи с этим, был создан счетчик таких обнулений. Соответственно, формула общего числа тиков - умноженное на 256 число обнулений, сложенное со счетчиком таймера TCNT2. Смещение на 8 битов вправо не работает - поэтому используется именно умножение.

Далее, при попытке выйти на период 1с, эмпирически выяснилось: таймер с отключенным предделителем становится счетчиком тиков процессора - определен период работы 62.5нс. Однако сама регистрация количества тиков занимает много времени при выполнении. И именно с этого момента начинается главное: адаптация этого таймера под конкретную задачу или умение писать быстрый код - и из этого определится его погрешность.

Например, из полученного примера можно исключить unsigned long int в пользу более быстрого unsigned int, если количество тиков не превысит 65535. Или эмпирически вычисляется, что перетипирование TCNT2 в unsigned long int обходится в 2 процессорных тика - и ну его нафик.

В моем случае, исходный код в системе защиты от протечек выполняется ~70мс - необходимо реализовать задержку ~30мс с высокой точностью. Итого, на ровно 100мс потребует 1.600.000 тиков - годится только unsigned long int.

Строка "while (g_uliTIMER2_OVF*256 + TCNT2 < F_CPU) {}" выполняется 23 тика - погрешность таймера при такой реализации составляет +1437.5нс, в 23 раз больше периода. Переменные uliBegin и uliEnd именно volatile: замедляют работу - но считают точно (если убрать volatile от g_uliTIMER2_OVF - цикл 1с вообще перестает работать).

При макетировании еще раз подтвердилось, что delay и delayMicroseconds непостоянны в своих задержках, даже при одном и том же входном параметре. Здесь же, при одинаковом исходном коде без delay, - всегда реализуется одинаковое количество тиков.

(добавлено 08.02.2023) Никто не мешает в формуле сравнения из 1.600.000 тиков вычесть 23...

(добавлено 09.02.2022) Никто не мешает вычесть в формуле большую половину тиков - превратив погрешность в ±12 тиков, ±750нс.

(добавлено 19.02.2022) Так и сделал, обновив исходники.

(добавлено 05.12.2023) К сожалению, долговременное тестирование системы защиты от протечек показало: погрешность составляет -26мин за 2мес и еще -31мин за 2мес (прошло 2 длительных цикла). Причины - неизвестны. Сюда включены вероятные задержки посыла SMS оператором и разница во времени посыла SMS самим модулем Arduino - но все равно очень много. Мало того, погрешность еще и колбасит.

Для первого случая получается погрешность -30093нс/цикл, для второго -35880нс/цикл. "Никто не мешает вычесть в формуле" - похоже, довычитался... -12 тиков стоит в формуле (g_uliTicks_Needed = F_CPU/10 - 12) - похоже, это лишнее. Возможно, перепрограммирую исходники, залью - и через 4-6мес отпишу сюда еще раз.

(добавлено 27.02.2024) Ещё хлеще. Повторный тест - +50мин в месяц. Именно в момент внедрения в исходный код проекта исходного кода таймера что-то пошло не так. Возможно, хаотичность выбора "в плюс или в минус" в момент включения Arduino возникает.