Arduino Mega. Контроллер теплицы. Хроники - 2

РЕКЛАМА НА ФОРУМХАУС

Всю жизнь с паяльником. И только в 60 лет перешел на SMD и пожалел, почему не сделал этого раньше?

Ветку не внимательно читаете. Выкладывал платы симисторного управления с опторазвязкой, потому как надоели танцы с бубном по поводу помех от реле и индуктивной нагрузки.
Сейчас переделал чуть платы (радиаторы поставил побольше, т. к. у меня еще и теплый пол (1,5-2 кВТ) работает с автоматикой).

Хочу забыть как страшный сон, т. к. при заклинивании привода выгорает напрочь...
Жду от китайцев L6203. Тоже, что и L298 только на полевиках. Плюс на плате заложил защиту от перегруза. Плата на 3 канала.

 

Дмитрий, а Ваш код для контроллера предусматривает "нештатные" ситуации - например, действия на случай зависания меги, сетевых контроллеров? Проектируется устройство, которое должно работать круглосуточно, "на природе", в условиях коммутационных помех. Важно чтобы не зависло, например в момент, когда "все краны открыты".
Например, М590 или SIM могут зависать в процессе работы и "вернуть" их можно только перетыркиванием питания. Отслеживают активность на RXTX, и если нет ответов за разумное время, то релюшкой или полевиком в цепи питания дергают.
С мегой сложнее (кроме стандартных процедур bodlevel, сторожевой таймер)- надо чтобы какое-то внешнее устройство отслеживало ее "активность". Например на какомнить выходе "генерить" импульсы, когда мега работает штатно и перезапускать ждущий мультивибратор. Как импульсы "задержались" - дергать питание. После отсылать СМС, чтобы хозяин проанализировал, устранил причину.
Схемки я могу набросать и проверить, а вот с кодом у меня скилла не хватает.
Предлагаю обсудить этот момент.

 

Ветку внимательнее прочитайте, об этом уже говорилось

 

Да, подтверждаю - на SMD много все проще - размеры устройства меньше, сверлить меньше, расход материалов меньше, детали дешевле и "бесплатных" их вариантов сейчас больше (материнки, например).
Минусы (относительные для новичков)- нужен хороший паяльник, несколько жал, пинцет, лупа.

 

Извиняюсь, бегло просмотрел обе ветки, но пропустил, видимо. На схеме и в коде не нашел реализации этого. Что порешили? В топку? Или позже?
PS. Да, нашел. Сообщение 1991. Нужная жеж вещь. Надо бы интегрировать в проект

 

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

Сергей в курсе этого дела, он лучше объяснит, что там за микруха.

 

Могут. Всё может зависнуть, естественно, всех ситуаций я предусмотреть не могу. Нужны будут и полевые испытания, безусловно. Сейчас об этом говорить ещё рано.

 

А что там интегрировать-то? Это внешнее управление, в проекте уже есть модуль таймеров, т. е. всё, что нужно. В модуле таймеров настраиваете какой-нибудь пин, чтобы на нём раз в секунду, например, появлялся высокий уровень на полсекунды. Платку внешнего управления подключаете к этому пину и в разрыв цепи питания, всё. Если плата не обнаружит сигнала - она пересбросит питание - профит.

 

Это "костыль" -я считаю. уж лучше тогда на информационный мигающий диодик повесить и не "занимать" таймер или правила. А второй таймер можно на 24 или 12 часов настроить и сбрасывать Sim800. Да, пока это вариант, но интегрировать в проект - сделать такую специальную функцию.
Я же не настаиваю а предлагаю занести это в список доработок предпоследним пунктом

 

1. Это не костыль, а штатное решение;
2. На диодик повесите - и как вы будете понимать, что мега зависла? Вся фича в регулярной смене сигнала, а диодик - будет гореть, даже если мега зависнет;
3. Правила занимать для этого - зачем, если есть таймеры?
4. Специальной функции в проекте - не будет, там уже всё есть, для обеспечения подключения внешнего контроля по питанию. Кому надо - ставит, кому не надо - не ставит.

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

Но опять же, подчеркну: по поводу детектирования зависания GSM-модема надо думать, т. к. считаю, что принудительно перезагружать контроллер просто так - не айс. Естественно, в случае с GSM-модемом надо будет допиливать прошивку, и посылать ему раз в полчаса, скажем, AT-команду, и если ответ не получен - тады ай-яй, бяда, надо передёргивать затвор

 

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

 

И вот кстати: а как вообще определить, завис ли GSM-модем и что при этом делать? Опишу ситуацию: допустим, GSM-модем подключён к меге. И стоит задача перезагрузить мегу, если модем не отвечает.

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

И вот - нам надо перезагрузить мегу, т. к. модем - повис. Ок - перезагружаем, ждём ответа от модема, его нету - опять перезагружаем, и так до посинения, весело, правда? Ок, мы умные, и перед перезагрузкой меги пишем в EEPROM флаг, что мы перезагружаем мегу по причине зависания GSM-модема, и перед повторной перезагрузкой проверяем - если есть флаг, то не перезагружаемся, а просто прекращаем работать с модемом. Если флага нет - перезагружаемся. При этом - при любом ответе от модема мы сбрасываем этот флаг в EEPROM.

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

Что предлагаю в таком случае: вводить отдельный программный модуль в прошивку, который как раз и будет этим заниматься - на нужном пине ногодрыгом менять уровни (при этом модуль таймеров можно оставить в покое, и все четыре таймера будут свободны), чтобы успокаивать железку-перезагрузчик, и плюс ко всему - анализировать состояние контроллера (придётся добавить пару бит для понимания - висит ли GSM или ESP и т. п.) - и на основе входящих данных уже принимать решение - перезагружать контроллер или нет.

Давайте обсуждать, чтобы, когда уже подойдёт время реализовывать - в голове всё сложилось.

Но: говорю сразу - это будет именно арбитр, ибо - расширяемость и централизованность принятия решений

 

Как вижу программный интерфейс: каждый модуль системы может переопределить функцию GetHangStatus (название навскидку), в которой возвращать статус модуля по зависанию: завис/не завис, разные приоритеты, требуется ли перезагрузка и пр. могущие быть полезными в дальнейшем плюшки.

Класс RebootArbitrage (название тоже навскидку) периодически (допустим, раз в 10 минут) опрашивает все модули, и на основании полученных данных принимает решение - перезагружать контроллер или нет. При этом именно из него, скажем, имеет смысл отправлять аварийные СМС хозяину (конечно, если GSM-модем не висит) с информацией - какой модуль завис. А модуль GSM должен будет научиться обрабатывать СМС с запросом перезагрузки контроллера (просто выставляя себе статус "я завис, нужна перезагрузка" - дальше арбитр сам разберётся).

Как вам такой расклад? Задача интересная, и действительно - считаю, что этому функционалу место в прошивке должно быть выделено. Конечно - настраиваемо, как водится: кому не нужен арбитраж перезагрузки - тот его не юзает.

Ы?

 

У GSM Shield SIM900 есть пин (9) аппаратного ресета.
За М590 не скажу, но может и у него есть аналогичный функционал или реализовать нечто подобно самостоятельно .

 

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

Надо много думать, и собирать разных мнений, в общем