“Не делай так”.
ты не поймешь сколько раз счетчик перекрутился чере з ноль
“Не делай так”.
ты не поймешь сколько раз счетчик перекрутился чере з ноль
Шож ты нудный-то такой ![]()
uint32_t reset_counter = 0;
void check_reset()
{
static uint32_t last_data = 0;
uint32_t now_data = millis();
if (now_data < last_data)
{
reset_counter++;
}
last_data = now_data;;
}
void setup()
{
}
void loop()
{
check_reset();
}
А так?
А с 32-разрядными операциями на 8-разрядных системах разве не так?
В Ардуино есть любые способы, какие пожелает написать программист.
И - да, забыл сказать, что дискретность измерения в 1000 мкс не всегда бывает достаточной.
Так что единственного универсального способа в 32 разрядах нет и быть не может.
Либо некоторый неуниверсальный случай в 16/32 разрядах, подходящий для данного конкретного случая, либо счетчик 48-, 64- или более высокой разрядности.
Оба ответа неверные. Правильный: 24*N+1, где N - целое число.
Если Вас интересуют интервалы менее 1 мс, это бесполезно, если интервалы от десятков до миллионов мс - следить не обязательно, а если речь может идти от миллиардов мс - то и “следить” достаточно раз в неделю.
Еще раз: Вы пытаетесь протолкнуть очень вредную для новичков тему о том, что якобы существует какой-то универсальный подход, дающий программисту право отключить голову.
“Сколько чип провел во сне?”
“24*N+12 товарищ командир“
так и я о том же. я просто предлагаю секунды получать не делением миллис на тыщщу, а делением micros() на миллион. А потом все приводится к 32 битам.
Отнюдь!
Тогда о чем речь?
О том, чтобы измерять время вывода на экран одного символа целым числом секунд?
“Котел: Выключен.
Температура: 22 C
Последний раз включался: 49 дней 6 часов назад“
Например.
Для этого нужен не millis, а RTC, причем с независимым источником питания.
и переносной ядерный генератор, да.
Одну и ту же задачу можно решить массой разных способов.
Кому-то для решения может потребоваться переносной ядерный генератор, кому-то достаточно 2032.
На миллис клин не сошёлся. Функция как задумана, так и работает.
Если не подходит - есть же ещё таймеры.
К примеру, раз в сек. в прерывании увеличиваешь переменную на 1 сек.
На 328р есть даже асинхронный таймер
Переполнение - это такой битик, который отвечает за переполнений, а если Вы такой перфекционист, так отслеживайте этот битик.
Про битик я в курсе(SREG, Z - это на 328р) , это Вы , наверное, не тому ответили))
Звиняй. Не тебе это было. Посыпаю голову пеплом и мою потом ![]()
Считаю, что 32 битный millis это очееень большой запас. Какая вероятность того, что устройство отработает 50 дней без перезагрузок или отключения питания? Да никакой.
Для работы с интервалами, измеряемыми часами и, тем более сутками, нужны либо RTC, либо синхронизация по сети. Иначе, при работе с часами , сутками, нужно писать в EEPROM хотя бы истекшие минуты, а при перезапуске МК считывать прошедшие минуты из EEPROM и продолжать отсчет миллис. Это где допустима такая погрешность, например для таймера полива. Для этого достаточно 16 битного миллис. И в прерывании каждые 1024 мкс будут вычисления быстрее по сравнению с 32 битными числами (для AVR).
Чегой-то? У меня вот сейчас управлялка котопоилкой работает без просыху. И подключена через аккумулятор, дабы кот мог водицы попить, если вдруг свет отключат. И ничего, работает ))
Если у вас игрушка, то ей вобщем-то все равно переполнение через такое количество дней - вы ее включаете поиграть, за один цикл работы она не доберется до предела счетчика.
Если у вас устройство, которое работает в автономке месяцами, то вы просто обязаны предусмотреть и вочдог и восстановление после перезапуска (ошибка, питание, зависание…) И проблема переполнения счетчика времени исчезнет по причине появления более стабильного механизма для автономного (с расписанием) устройства. Если такой механизм не закладывается при проектировании, то у вас опять игрушка.