Зависания и вачдог

Все возможно и не лечится ,но в всяком случае мои железки всегда на связи и мне не надо ехать за сто вёрст перезагружать из за какой нибудь фигни

 

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

 

На Leonardo ETH c W5500 на борту, было замечено, что иногда, после заливки кода, у W5500 так съезжала крыша, что устройство не могло получить IP адрес.
После нажатия на кнопку ресет, - все начинало нормально работать.
Замечено такое поведение было только после прогрузок, но ситуация как-то напрягала.
Устройство должно было работать за 70 км от города.

Внутренний WDT в такой ситуации помочь бы не смог, стал искать внешний.
Из того, что нашел максимум по времени были на 1,6 секунды.
С загрузкой через bootloader хотелось что-то, с периодом между сбросами побольше.

Сделал WatchDog на Тини13. Период 25 секунд. Сигнал с снимал с 13-го выхода, мигание встроенного светодиода - показывает нормальную работу устройства. Если код обнаруживает проблему - блокирует инвертирование выхода, 25 секунд - аппаратный ресет.

За два года ни разу не срабатывал, но так как то спокойнее.

 

Какое космическое излучение где переворачивает биты? У меня позабытая флешка у одного заказчика пролежала 4 года на даче. Через 4 года забрал оттуда, где и положил))) Рабочая полностью.
Возвращаясь к миганию светодиодом. В алгоритме клок -> счетчик -> компаратор -> триггер зависать вообще негде.

 

простите, если у вас в программе такие "ответвления", что ЛУП крутится медленнее периода ватчдога - это говорит только о том, что программа неверно спроектирована и других версий тут быть не может.
Все "заходы в настройки" и "мигания лампочкой" по уму пишутся так, чтобы они возвращали управление в Луп не реже 100 миллисекунд, иначе ни о какой оперативной работе программы говорить не придется
Если же все спроектировано правильно и ЛУП оборачивается хотя бы пару раз в секунду - ватчдог достаточно поставить в нем один раз.

Практический опыт - имею систему, управляющую асинхронными мотором 1.5КВт. тиристорный драйвер смонтирован прямо на моторе, в его клеммной коробке. Управление на основе Атмеги328 - на станине мотора. Наводки - сами понимаете. Поначалу система зависала и перегружалась по ватчдогу 2-3 раза в сутки, добавил пару конденсаторов по 100 мкФ прямо на ножки атмеги - с тех пор за 4 месяца - только два зависания, но благодаря ватчдогу на работу системы они практически не влияют - программа сохраняет все параметры в ЕЕПРОМ и при ресете возобновляет работу с прежними настройками.

 

Не соглашусь. Бывают программы, которые не вертятся в лупе, а распределяются от туда куда им дальше. Несколько разных задач в одной программе, нафига при настройке в меню тормошить управление двигателем? И наоборот. Есть задачи где произвдительность имеет значение критическое, прерывать ее надо по одному сигналу, а никак не обрабатывая кучу дел. И так далее. Я сделал отключение вачдога на время работы с оператором, а при возвращении в дежурный режим он включается. Считаю, так оптимальнее всего.

 

не бывает. Это неправильные программы.

Представьте, что оператор зашел в настройки и тут его отвлекли - что, ваша программа будет "висеть" и ждать, пока он вернется? А если это управление каким-то оборудованием, за параметрами которого надо постоянно следить? - пока оператор вернется, реактор химзавода взлетит на воздух. Для сколько-нибудь оперативного управления ваш подход в принципе не применим, разве что для игрушек

Любой заход оператора в меню или работа с настройками выражается в каких-то действиях пользователя - нажатии на конопки, кручении энкодера, пролистывание тачскрина. Вот на эти события и надо реагировать. А пока оператор думает, какую следующую кнопку нажать, между событиями - по 10-20 раз в секунду - надо возвращаться в Луп, обрабатывать сигналы с датчиков и обеспечивать работу других ветвей программы.
У меня сделано так - луп буквально несколько строк, он только в цикле (как можно быстрей) перебирает основные ветви программы. Например:

Код (C++):

void loop() {
menu();
opros_datchikov();
Miganie_diodom();
}

При заходе в меню мы первым делом проверяем флаги нажатия кнопок и движения энкодера - если что-то нажато - реагируем, если ничего не нажато - сваливаем из функции в следующую

Код (C++):

void menu() {
// если кнопки не нажаты - тут же выходим
if ( ! ( (buttons_press()) || (encoder_move()))) return;
// если нажаты - обработка сигналов кнопок и энкодера
}

Причем 100мс - это уже много, я стараюсь крутить луп не долше 10мс.

 

у меня такие. У меня даже этой лупы нет.

 

добавлю практический пример
имею проект, где на TFT экране 240х320 показывается стрелочный секундомер (то есть раз в секунду перерисовывается стрелка), сверху по экрану скроллится движущаяся строка, внизу экрана тачкнопки настройки - и одновременно с этим система примерно 30 раз в секунду контролирует и, при необходимости, регулирует давление в пневмосистеме.
Если использовать вашу концепцию с "программами, которые уходят из лупа" - написать такое в принципе невозможно.

 

Неправильная программа это та программа, которая не работает. Уход из лупа это вполне приемлемо для мелких программ, и даже упрощает работу. Но с ростом масштаба начинает создавать всё больше проблем. Так что и тот и тот вариант допустим, но оптимален в разных ситуациях.

Прерывания по таймеру

 

Нет, не согласен.
Не заход в loop() (main()) - это блокировка для ардуино или нормального кода на Си.
То же самое, что delay(). Loop может быть пустым, но туда мы должны попадать.
То есть, в данной ситуации весь основной цикл игнорится, а это не правильно.
Можно написать так, чтобы не было таких проблем

 

Да, на ESP8266, с использованием Ардуино ИДЕ и библиотек - это костыль, и с ним приходится мириться.
На Ардуино, код можно писать так, чтобы не зависать на ожиданиях и сваливаться в loop, работая по флагам.

 

Чего?

 

Того!
Что функции реконнекта могут подвисать до 7 секунд.

 

В ардуино-ядре для esp8266? Там реконнект происходит автоматически в фоне.

 

Ага... Сейчас!

Вот эти теоретики, что Вы, что @parovoZZ!
Вы попробуйте, потом говорите! Не путайте людей.

Когда соединение разваливается, и нет коннекта ни по WiFi ни по MQTT ждем соединения.
В loop() или в функции под ним, входим в функцию реконнекта и подвисаем там секунд на пять.

Тут спасает таймер, для событий которые нужно обработать в RT

 

В какую вообще функцию реконнекта? При отвале это происходит автоматически. Вызов reconnect() работает только тогда, когда подключение к точке установлено.