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

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

Спасибо за лог. Обнаружил два различия. Первое - штатная работа:

Код:

+RECEIVE DETECTED, CLIENT #0, LENGTH=275
DATA AVAILABLE FOR GARDENBOSS.RU !!!
HTTP: line catched=
HTTP: line catched=HTTP/1.1 200 OK
HTTP: line catched=Date: Mon, 17 Jun 2019 02:48:43 GMT
HTTP: line catched=Server: Apache/2
HTTP: line catched=X-Powered-By: PHP/7.0.33
DATA AVAILABLE FOR GARDENBOSS.RU !!!
HTTP: line catched=Cache-Control: no-cache, private
HTTP: line catched=Vary: Accept-Encoding,User-Agent
HTTP: line catched=Connection: close
HTTP: line catched=Transfer-Encoding: chunked
HTTP: line catched=Content-Type: text/html; charset=UTF-8
DATA AVAILABLE FOR GARDENBOSS.RU !!!
HTTP: line catched=
HTTP: line catched=a
HTTP: line catched=[CMDEND]
HTTP: Handler reports DONE!
<== SIM800: 0, CLOSED

Второе - возможная пропажа данных:

Код:

+RECEIVE DETECTED, CLIENT #0, LENGTH=275
DATA AVAILABLE FOR GARDENBOSS.RU !!!
HTTP: line catched=
HTTP: line catched=HTTP/1.1 200 OK
HTTP: line catched=Date: Mon, 17 Jun 2019 02:53:52 GMT
HTTP: line catched=Server: Apache/2
HTTP: line catched=X-Powered-By: PHP/7.0.33
HTTP: line catched=Cache-Cont
HTTP: line catched=0, CLOSED
HTTP: Handler reports DONE!

Поскольку в порт данные падают очень быстро, то в какой-то момент, теоретически, часть их может быть не вычитана во внутренний буфер (контроллер чем-то долго занят). Это единственный критический участок кода, так сказать. Именно поэтому я и предлагал - тестировать по возможности в минимальной конфигурации, для начала - @olegmak3, это тебе - понимаю, что рабочая теплица и т. п., но и зависимости надо искать.

Буду думать, что с этим делать, и в этом ли дело вообще.

Как будут обновления - отпишусь. На первое время добавлю успокоение собаки в указанных местах. А там - посмотрим: если контроллер будет зависать, вместо пересброса - то будем думать дальше. Выход есть всегда Строго говоря, я и так достаточно часто (между обновлениями каждого модуля и внутри yield) вычитываю из буферов Serial* во внутренний буфер, но и это, конечно, не исключает варианта, когда какой-то модуль ооочень долго чего-то делает. Если что - впилим вычитку по таймеру Сейчас надо понять, именно в этом куске кода - проблема, или нет.

Ждите

 

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

Короче, теперь при возникновении проблем, если правильно определено их место - контроллер должен просто зависнуть в цикле, и строчки вида

никогда не появится в логе. Отпишитесь, плз, как будет работать. Если проблема локализована правильно, то тогда будем думать, как её решать.

 

По предварительным расчётам: если в течение примерно 22 миллисекунд не будет происходить вычитка из буфера Serial* (128 символов на скорости 57600 бод) - то буфер переполнится, и новые данные потеряются. Т. е. контроллер не должен висеть в блокирующей операции дольше, чем 20 миллисекунд - жёсткие требования, да?

Однако, следует понимать, что огромная часть кода писана не мной: например, библиотеки для работы с SD и пр. - кто его знает, какое сочетание вводных к чему приведёт. Я встречался с ситуацией, когда всё начинало по непонятным причинам жутко тормозить, когда с SD было что-то не так.

Короче, наша задача на первую итерацию - подтвердить, правильно ли мы нашли проблемный участок кода. Если да - то можно, например, под Mega заюзать TimerOne (выключает ШИМ на пинах 11 и 12) - и с обработчика таймера раз в 10 миллисекунд, скажем - вычитывать из внутренних буферов Serial*.

Жду логов/багрепортов

 

Я в своих контроллера установил время сброса сторожевого таймера 40-60 секунд. Для контроля теплицы пропадание управления на 1 минуту роли не играет, а сторожевой таймер не сбросит контроллер из за "неправильной" работы программы.

 

Да тут видишь в чём дело: зоопарк мы развели знатный, а на Меге уже расширенный (если делать по инструкциям вверху Main. ino) буфер Serial* - всего 128 байт. За 20 миллисекунд пролетят эти байты, и если не успеть вычитать со служебного буфера в свой - всё, суши вёсла.

Возможно, именно в этом и дело, т. к. если брать ThingSpeak - там мне пофиг на ответ, главное, что запрос отправлен и всё. А вот с gardenboss. ru - могут приходить задачи, поэтому вычитать весь ответ - очень важно. И если какая-то сволочь в прошивке не отдаёт управление за 20 миллисекунд - это может стать проблемой.

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

У меня иногда возникает ощущение, что я пытаюсь натянуть штаны 30-го размера на тушку 60-го - уж больно по острию ходим. Но решить проблему надо - кто знает, может она и под Due выплывет (а вот там с таймерами уже - сложнее, надо смотреть, какой ни один пин не трогает).

Будем решать

 

А вот подумалось - щас как возьму, да как задействую таймер 1, сделаю выключаемую настройку в Configuration_Mega_NEW.h - и всё

 

Всем привет.
У меня неделю проходит тестовый режим. Перезагрузок не наблюдаю. Мега.

 

Спасибо за отзыв, это хорошо, что всё хорошо в вашем случае. Однако, конфигурации у всех разные, и наша задача - впихнуть невпихуемое Пока считаем, что иногда работает, иногда - нет, т. е. суслик вполне может быть

 

@necrjd, @olegmak3 - ребята, у вас есть ссылки на исходники на гугьдиске. Берём - и качаем их, основной файл конфигурации (Configuration_MEGA.h) - можно скопировать с предыдущей версии.

Далее - идём в Configuration_MEGA_NEW.h - и там видим закомментированную настройку

/#define USE_TIMER_ONE_FOR_ESP_SIM800

Раскомментируем её, настраиваем период в настройке чуть ниже (по умолчанию сделал 10 миллисекунд) - и перезакачиваем прошивку. Теперь, по идее - каждые 10 миллисекунд, если какая-то бздня не отключит прерывания - будет принудительно вычитываться из служебных буферов Serial* во внутренние буфера ESP и SIM800. Т. е. налицо попытка решить возможную проблему, если мы правильно обозначили её границы.

По таймеру1, на всякий, статейка: http://robocraft.ru/blog/arduino/614.html - не забываем, что он завязан на пины, однако, в применяемом варианте он с ними, по идее, не работает. Но следует помнить этот нюанс

Библиотеку TimerOne качать НЕ НАДО, я её положил рядом, и чуть модифицировал, чтобы компилировалось и под Due, и под Mega

Очень жду отзывов.

 

Тааак... Подумалось мне, что крайние изменения - не самые годные, и вот почему: таймер у нас по прерываниям вызывается, т. е. может прервать выполнение кода в любой момент, даже в тот, когда с памятью что-то делается.

Поэтому - пока НИЧЕГО НЕ ДЕЛАЕМ, игнорируем предыдущее сообщение - спешка нужна при ловле блох, мне надо подумать, правильный ли подход я выбрал

 

Сделал следующее: ввёл флаг: если SIM800 (или ESP) внутри своей функции update (т.е. работают со своим внутренним приемным буфером - перевыделяют память и т. п.), то функция обновления по таймеру - не будет просить их вычитать из порта в свой внутренний буфер. Таким образом - всё должно работать корректно: пока ESP и SIM800 обновляются - таймер ничего не делает. Как только обновляется какой-то другой модуль - тогда таймер периодически дёргается.

Лучше пока не обновляться, надо ещё подумать

 

Еще один лог - поинтереснее.
Запуск в 12:00. В 15:12 перестали ходить данные на тингспик, в 15:16 на гарденбосс, в 15:25 перестал писаться лог. Перезапуска контроллера небыло (смска не пришла). Около 20:00 пошла запись лога, в 20:12 пошли данные на тингспик. На гарденбосс-нет. Пришел домой около 23 - контроллер не висел - на кнопки реагировал, лампочками подмаргивал

 

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

Можно пробовать, настройка USE_TIMER_ONE_FOR_ESP_SIM800 в Configuration_MEGA_NEW.h - по умолчанию выключена.

Буду признателен за тестирование.

 

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

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

 

@necrjd - обновил на гугльдиске ещё раз, можно пробовать крайние изменения, добавил очистку пула клиентов у SIM800 при рестарте - пропустил этот момент.

Короче, при каком-то стечении обстоятельств (предположительно - потеря данных в порту) - в части работы с SIM800 транспорту сносит крышу, вот тут видно, что 0, CLOSED попало не туда, куда нужно:

Код:

HTTP: line catched=X-Powered-By: PHP/7.0.33
15:25:51.903>
HTTP: line catched=Cache-Cont
15:25:51.903>
HTTP: line catched=0, CLOSED
15:25:51.965>
HTTP: Handler reports DONE!
15:25:51.965>
DATA AVAILABLE FOR GARDENBOSS.RU !!!
19:29:50.594>
DATA AVAILABLE FOR GARDENBOSS.RU !!!
20:06:05.378>
SIM800: want to check modem availability...
20:06:05.378>
SIM800: Check if modem available...
20:06:05.378>
SIM800: ==> AT+CSQ

И почему так странно работает лог - тоже хз, руки опускаются, у меня такого никогда не ловилось: видно, что 15:25, а потом аж в 20:06. Предположу, что что-то по аппаратной части, и опять настоятельно рекомендую: поотключать всё по-максимуму, оставить один датчик и модулей по-минимуму, чтобы сузить диапазон поисков.

Короче, что происходит у вас - пока хз, надо для начала попробовать вариант с TimerOne, который выложен на гугльдиск.