Как справиться с rollover millis()?

Короткий ответ: не пытайтесь “обработать” опрокидывание миллиса, вместо этого напишите код, безопасный для опрокидывания. Ваш пример кода из учебника в порядке. Если вы попытаетесь обнаружить опрокидывание для реализации корректирующих мер, скорее всего, вы делаете что-то не так. Большинству программ Arduino приходится управлять только событиями относительно короткой продолжительности, такими как отключение кнопки на 50 мс или включение обогревателя на 12 часов... Тогда, и даже если программа предназначена для работы в течение многих лет, ролловер в миллис не должен вызывать беспокойства.

Правильный способ управления (или, скорее, избежать необходимости управления) проблемой опрокидывания состоит в том, чтобы рассматривать длинное число без знака, возвращаемое millis (), в терминах модульной арифметики. Для склонных к математике некоторое знакомство с этой концепцией очень полезно при программировании. Вы можете увидеть математику в действии в статье Ника Гэммона " Переполнение миллиса ()"... что-то плохое?. Для рассматриваемой проблемы важно знать, что в модульной арифметике числа “обернитесь” при достижении определенного значения – модуля – так, чтобы 1 − модуль-это не отрицательное число, а 1 (подумайте о 12 −часовых часах, где модуль равен 12: здесь 1 - 12 = 1).

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

Примечание к micros(): Все, что здесь сказано о millis (), применимо аналогично функции micros(), за исключением того факта, что функция micros() выполняется каждые 71,6 минуты, а функция setMillis (), представленная ниже , не влияет на функцию micros().

Мгновения, метки времени и длительности

Когда мы имеем дело со временем, мы должны проводить различие по крайней мере между двумя различными понятиями: мгновениями и длительностью. Мгновение-это точка на оси времени. Длительность-это длина временного интервала, т. е. расстояние во времени между моментами, определяющими начало и конец интервала. Различие между этими понятиями не всегда очень четко прослеживается в повседневном языке. Например, если я скажу “Я вернусь через пять минут”, то “пять минут” - это предполагаемое время продолжительность моего отсутствия, в то время как “через пять минут” - это момент моего предсказанного возвращения. Важно помнить об этом различии , потому что это самый простой способ полностью избежать проблемы опрокидывания .

Возвращаемое значение millis() можно интерпретировать как длительность: время, прошедшее с момента запуска программы до настоящего времени. Однако эта интерпретация рушится, как только миллис переполняется. Как правило, гораздо полезнее думать о millis() как о возврате меткивремени, т. е. “метки”, идентифицирующей конкретный момент. Можно утверждать, что эта интерпретация страдает от неоднозначности этих меток, поскольку они используются повторно каждые 49,7 дня. Однако это редко бывает проблемой: в большинстве встроенных приложений все, что происходило 49,7 дней назад-это древняя история, которая нас не волнует. Таким образом, утилизация старых этикеток не должна быть проблемой.

Не сравнивайте метки времени

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

unsigned long t1 = millis();
delay(3000);
unsigned long t2 = millis();
if (t2 > t1) { ... }

Наивно было бы ожидать, что условие if () всегда будет истинным. Но на самом деле это будет ложно, если миллис переполнится во время delay(3000). Думать о t1 и t2 как о этикетках, пригодных для вторичной переработки, - самый простой способ избежать ошибки: метка t1 явно была назначена мгновению до t2, но через 49,7 дня она будет переназначена на будущий момент. Таким образом, t1 происходит как до, так и после t2. Это должно прояснить, что выражение t2 > t1> не имеет смысла.

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

1. later_timestamp - более ранняя метка времени дает длительность, а именно количество времени, прошедшее между более ранним моментом и более поздним моментом. Это наиболее полезная арифметическая операция, включающая временные метки.
2. метка времени ± длительность дает метку времени, которая находится через некоторое время после (если используется +) или до (если −) начальной метки времени. Не так полезно, как кажется, поскольку полученная временная метка может использоваться только в двух видах вычислений...

Благодаря модульной арифметике, оба они гарантированно будут работать нормально во время ролловера millis, по крайней мере, до тех пор, пока связанные с этим задержки будут короче 49,7 дней.

Сравнение длительностей-это нормально

Длительность-это просто количество миллисекунд, прошедших в течение некоторого интервала времени. До тех пор, пока нам не нужно обрабатывать длительность дольше, чем 49,7 дней, любая операция, которая имеет физический смысл, также должна иметь смысл с точки зрения вычислений. Мы можем, например, умножить продолжительность на частоту, чтобы получить количество периодов. Или мы можем сравнить две продолжительности , чтобы узнать, какая из них длиннее. Например, вот две альтернативные реализации функции delay(). Во-первых, тот, что с багги:

void myDelay(unsigned long ms) {          // ms: duration
    unsigned long start = millis();       // start: timestamp
    unsigned long finished = start + ms;  // finished: timestamp
    for (;;) {
        unsigned long now = millis();     // now: timestamp
        if (now >= finished)              // comparing timestamps: BUG!
            return;
    }
}

И вот правильный ответ:

void myDelay(unsigned long ms) {              // ms: duration
    unsigned long start = millis();           // start: timestamp
    for (;;) {
        unsigned long now = millis();         // now: timestamp
        unsigned long elapsed = now - start;  // elapsed: duration
        if (elapsed >= ms)                    // comparing durations: OK
            return;
    }
}

Большинство программистов на C написали бы вышеуказанные циклы в более сжатой форме, например

while (millis() < start + ms) ;  // BUGGY version

и

while (millis() - start < ms) ;  // CORRECT version

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

Что, если мне действительно нужно сравнить метки времени?

Лучше постарайся избежать этой ситуации. Если это неизбежно, все еще есть надежда, если известно, что соответствующие моменты достаточно близки: ближе, чем на 24,85 дня. Да, наша максимальная управляемая задержка 49,7 дня только что сократились вдвое.

Очевидное решение состоит в том, чтобы преобразовать нашу проблему сравнения временных меток в проблему сравнения продолжительности. Скажем, нам нужно знать, является ли мгновенный t1 до или после t2. Мы выбираем некоторый опорный момент в их общем прошлом и сравниваем длительности от этой ссылки до t1 и t2. Опорный момент времени получается путем вычитания достаточно большой длительности либо из t1, либо из t2:

unsigned long reference_instant = t2 - LONG_ENOUGH_DURATION;
unsigned long from_reference_until_t1 = t1 - reference_instant;
unsigned long from_reference_until_t2 = t2 - reference_instant;
if (from_reference_until_t1 < from_reference_until_t2)
    // t1 is before t2

Это можно упростить следующим образом:

if (t1 - t2 + LONG_ENOUGH_DURATION < LONG_ENOUGH_DURATION)
    // t1 is before t2

Заманчиво еще больше упростить, если (t1 - t2 < 0). Очевидно, что это не работает, потому что t1 - t2, вычисляемый как число без знака, не может быть отрицательным. Это, однако, хотя и не портативно, но работает:

if ((signed long)(t1 - t2) < 0)  // works with gcc
    // t1 is before t2

Ключевое слово, подписанное выше, является избыточным (всегда подписывается простое длинное), но оно помогает прояснить намерение. Преобразование в длинное значение со знаком эквивалентно установке значения LONG_ENOUGH_DURATION равным 24,85 дня. Трюк не переносим, потому что, согласно стандарту C, результат определяется реализацией. Но поскольку компилятор gcc обещает поступать правильно, он надежно работает на Arduino. Если мы хотим избежать поведения, определенного реализацией, приведенное выше сравнение со знаком математически эквивалентно этому:

#include <limits.h>

if (t1 - t2 > LONG_MAX)  // too big to be believed
    // t1 is before t2

с единственной проблемой, что сравнение выглядит в обратном направлении. Это также эквивалентно, если длина 32 бита, этому однобитовому тесту:

if ((t1 - t2) & 0x80000000)  // test the "sign" bit
    // t1 is before t2

Последние три теста фактически скомпилированы gcc в один и тот же машинный код.

Как мне проверить свой скетч на соответствие опрокидыванию millis

Если вы будете следовать вышеприведенным наставлениям, у вас все должно быть хорошо. Если вы все же хотите протестировать, добавьте эту функцию в свой скетч:

#include <util/atomic.h>

void setMillis(unsigned long ms)
{
    extern unsigned long timer0_millis;
    ATOMIC_BLOCK (ATOMIC_RESTORESTATE) {
        timer0_millis = ms;
    }
}

и теперь вы можете путешествовать во времени по своей программе, вызвав SetMillis(пункт назначения). Если вы хотите, чтобы это повторялось снова и снова, как Фил Коннорс, переживающий День сурка, вы можете поместить это в loop():

// 6-second time loop starting at rollover - 3 seconds
if (millis() - (-3000) >= 6000)
    setMillis(-3000);

Отрицательная временная метка выше (-3000) неявно преобразуется компилятором в unsigned long, соответствующую 3000 миллисекундам до опрокидывания (она преобразуется в 4294964296).

Что делать, если мне действительно нужно отслеживать очень длительные промежутки времени?

Если вам нужно включить реле и выключить его через три месяца, вам действительно нужно отслеживать переполнение миллисекунд. Есть много способов сделать это. Наиболее простым решением может быть простое расширение функции millis() до 64 бит:

uint64_t millis64() {
    static uint32_t low32, high32;
    uint32_t new_low32 = millis();
    if (new_low32 < low32) high32++;
    low32 = new_low32;
    return (uint64_t) high32 << 32 | low32;
}

Это, по сути, подсчет событий опрокидывания и использование этого числа в качестве 32 наиболее значимых битов 64 - разрядного отсчета миллисекунд. Чтобы этот подсчет работал должным образом, функцию необходимо вызывать не реже одного раза в 49,7 дня. Однако, если он вызывается только один раз в 49,7 дня, в некоторых случаях возможно, что проверка (new_low32 < low32) завершится неудачно, и код пропустит количество high32. Использование millis() для принятия решения о том, когда делать единственный вызов этого кода в одном "обертывании" millis (конкретное окно 49,7 дня) может быть очень опасным, в зависимости от того, как выстраиваются временные рамки. В целях безопасности, если вы используете millis() для определения времени совершения единственных вызовов на millis64(), в каждом окне 49,7 дня должно быть не менее двух вызовов.

Однако имейте в виду, что 64-разрядная арифметика на Arduino стоит дорого. Возможно, стоит уменьшить разрешение по времени, чтобы остаться на уровне 32 бит.