Использование millis() и micros() внутри процедуры прерывания

Цитируемая фраза не является предупреждением, это просто утверждение о том, как все работает.

Нет ничего изначально неправильного в использовании millis() или micros() в правильно написанной процедуре прерывания.

С другой стороны, делать что-либо вообще в рамках неправильно написанной процедуры прерывания по определению неправильно.

Процедура прерывания, выполнение которой занимает более нескольких микросекунд, по всей вероятности, написана неправильно.

Короче говоря: правильно написанная процедура прерывания не вызовет и не вызовет проблем с millis() или micros().

Редактировать: Что касается “почему micros() "начинает вести себя беспорядочно"”, как объясняется навеб-странице “изучение функции Arduino micros”, код micros() на обычном Uno функционально эквивалентен

unsigned long micros() {
  return((timer0_overflow_count << 8) + TCNT0)*(64/16);
}

Это возвращает четырехбайтовую длину без знака, состоящую из трех младших байтов из timer0_overflow_count и одного байта из регистра подсчета таймера-0.

Счетчик timer0_overflow_count увеличивается примерно один раз в миллисекунду обработчиком прерываний TIMER0_OVF_vect, как описано в обзоре веб-страницы функции arduino millis.

Перед запуском обработчика прерываний аппаратное обеспечение AVR отключает прерывания. Если бы (например) обработчик прерываний выполнялся в течение пяти миллисекунд с отключенными прерываниями, было бы пропущено по крайней мере четыре переполнения таймера 0. [Прерывания, написанные в коде C в системе Arduino, не являются реентерабельными (способны корректно обрабатывать несколько перекрывающихся исполнений в одном и том же обработчике), но можно написать реентерабельный обработчик языка ассемблера, который восстанавливает прерывания до того, как начнется трудоемкий процесс.]

Другими словами, переполнения таймера не “накапливаются”; всякий раз, когда переполнение происходит до того, как было обработано прерывание от предыдущего переполнения, счетчик millis() теряет миллисекунду, а несоответствие в timer0_overflow_count, в свою очередь, также делает micros() неправильным на миллисекунду.

Что касается “менее 500 мкс” в качестве верхнего ограничения по времени для обработки прерываний, “чтобы предотвратить блокировку прерывания таймера слишком надолго”, вы можете увеличить время чуть менее 1024 мкс (например, 1020 мкс), и millis() все равно будет работать большую часть времени. Однако я рассматриваю обработчик прерываний, который занимает более 5 мкс, как вялый, более 10 мкс как ленивый, более 20 мкс как улиткообразный.

Нет ничего плохого в том, чтобы использовать millis() или micros() в подпрограмме прерывания.

Неправильно использовать их неправильно.

Главное здесь то, что, пока вы находитесь в режиме прерывания, "часы не тикают". millis() и micros() не изменятся (ну, micros() сначала изменится, но как только он пройдет ту волшебную миллисекундную точку, где требуется миллисекундный тик, все развалится.)

Таким образом, вы, конечно, можете позвонить в millis() или micros (), чтобы узнать текущее время в вашем ISR, но не ожидайте, что это время изменится.

Именно об этом отсутствии изменений во времени предупреждается в приведенной вами цитате. delay() зависит от изменения миллиса (), чтобы узнать, сколько времени прошло. Так как это не меняет, функция delay() никогда не сможет закончиться.

Таким образом, по сути, millis() и micros() сообщат вам время, когда был вызван ваш ISR, независимо от того, когда в вашем ISR вы их используете.

Вы никогда не должны ничего делать внутри ISR, кроме как установить флаг, сообщающий, что вы получили прерывание, и вернуться.