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

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

@promavto - Саш, обновил на гитхабе, впилил новый код для работы с часами под Due, грубо говоря - всю твою версию. Для начала - что сделано:

1. В Main. ino вынес в функции инициализации и сброса I2C код - см "void initI2C()" и "void resetI2C()" - это инициализация по умолчанию - и принудительный сброс SCL импульсами на шину. У нас это было до этого, но - в отдельных функциях наглядней;

2. В RTCSupport.* - добавил код работы с часами для Due. Если компилируем под Due - юзается именно он, Wire не используется.

Закачал, протестировал. Что заметил: во-первых, таки удалось поймать зависон. Во-вторых - такое странное поведение: иногда по нажатию кнопки reset на плате - рестарт очень быстрый. Но стоит понажимать резет несколько раз - рестарт идёт, время читается, но - процесс рестарта становится сильно медленнее, по ощущениям - где-то 5 секунд, это прям ну очень как-то много.

Что удалось понять по факту: где-то таки есть косяк, который при рестарте не отпускает шину I2C. Но! Новый код работы с часами таки переподнимает эту шину (с чем не справляется штатный Wire. begin, к слову). Поскольку у нас первым устройством на I2C читаются именно часы (это происходит, например, при настройке модуля полива - цепочка вызовов из setup ведёт туда), то вот именно это место - чтение с часов при многократных reset - и тормозит.

Что косвенно может влиять на шину, если пройтись по устройствам на I2C, в порядке обращения к ним внутри setup:

1. В модуле полива в его функции Setup идёт чтение текущего времени с часов, при этом шина - уже инициализирована в setup(), который в Main. ino;

2. В модуле освещённости для BH1750, при вызове функции void LuminosityModule: Setup() - идёт запись в шину I2C. При этом шина - уже инициализирована в setup(), который в Main. ino;

3. Все дальнейшие возможные обращения к часам, не выходя из контекста setup() в Main. ino - происходят ПОСЛЕ того, как шина инициализирована;

4. Инициализация часов (вызов RealtimeClock. begin() - происходит внутри controller. Setup() и ДО регистрации любого модуля в системе.

То есть получаем пока не совсем понятную мне ситуацию, а именно: ПОЧЕМУ затык именно с часами? Если они сидят на первом I2C (в моём случае, предыдущая версия отладочной платы, отличная от твоей текущей, как я понимаю), при этом ВСЁ РАВНО переинициализация шины требует каких-то плясок с бубном? Смотри, какое дело: все остальные датчики, которые висят на первом I2C - нормально всё, и шина пересбрасывается, как здрасьте, иначе бы это было давно замечено. Однако - у нас проблема именно с DS3231. Очевидно, что в моём случае, поскольку часы висят на первом I2C, а не на втором, и обращение к ним - ПЕРВОЕ обращение к устройству на I2C при старте контроллера - всё становится понятней: Wire. begin не справляется с корректной инициализацией, код пересброса импульсами на SCL - не справляется, а вот код внутри RealtimeClock. begin - таки переподнимает шину, но - иногда мееедленно.

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

Если что - весь код, который компилируется под Due и связан с I2C и часами - закрыт внутри

#if TARGET_BOARD = DUE_BOARD

По этим строчкам до следующего #elif или #endif - можно посмотреть куски, которые компилируются, когда в менеджере плат выбрана Due. В целом, повторюсь: взял практически целиком твой код, убрав пару ненужных функций, чтобы сохранить полную совместимость по public-секции класса RealtimeClock.

Да, ещё важное: в моей версии платы часы висят на DS3231_WIRE_NUMBER 0, т. е. на первом I2C. Это, в моём случае - определённо ключевой момент!

У меня подозрение, что может быть что-то с настройками - пересечение по номерам пинов где-то? Ну уж больно неприятная ситуация с I2C, сил нет уже Что там происходит по осциллографу в момент зависания? SDA постоянно в высоком, или что? Найти бы гада, который так шину давит - придушил бы собственными руками!

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

З. Ы. И да - с введением твоего кода внутрь RealtimeClock. begin - настройка I2C_SPEED для Due становится как бы не очень и в тему, поскольку в новом коде - юзается 400 КГц частота шины, и плевать он хотел на нашу настройку

З. З. Ы. Чтобы ты лучше понимал логику того, что происходит в setup:

1. MainController: Setup - посмотришь сам, вызывается ДО регистрации модулей;
2. Вызов controller. RegisterModule - косвенно вызывает функцию Setup того или иного модуля, например, WateringModule: Setup.

Т. е. пробежавшись поиском по строке ":Setup" - ты можешь быстро глянуть, чего делает тот или иной модуль. Плюс, если помнишь - есть настройка DUE_START_DEBUG в Configuration_DEBUG.h - она выводит последовательно чиселки в Serial, и можно заметить, после какой чиселки - затуп. Именно так я понял, что иногда первое чтение с часов, вызванное при настройке модуля полива - тормозит на N секунд.

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

 

@promavto - я сейчас ещё попробую поработать над принудительным пересбросом I2C импульсами (нашёл возможное решение), и отпишусь - будет ли эффект.

 

@promavto - Саша, похоже, мы его победили! Использовал решение вот отсюда для сброса шины: https://github.com/esp8266/Arduino/issues/1025

Блин, почему раньше не догадался сам? Идея-то на поверхности лежала: надо послать NACK и STOP сигналы в шину, чтобы устройство на I2C отпустило её. А оно не отпускает шину, если reset попал прямо на середину чтения из неё, что очевидно. Именно это происходило и с часами. Я больше чем уверен - если бы запараллелить кнопку reset с отрубанием питания DS3231 - вообще бы не было проблем.

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

 

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

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

Жду отзывов, а пока почитаю, что там по уровню сигнала с GSM-модема. Команда AT+CSQ, вроде, так?

 

Обновил на гитхабе, добавил отрисовку уровня сигнала GSM-модема, в правом верхнем углу экрана ожидания TFT.

Заюзал уже имеющуюся настройку - проверка модема на доступность через определённые промежутки времени (настройка GSM_AVAILABLE_CHECK_TIME). Раньше там посылалась команда AT, теперь - AT+CSQ. Теперь, при настройке по умолчанию в 30 секунд - каждые 30 секунд происходит автоматическое обновление уровня сигнала с модема, что, по идее, должно отображаться и в виде изменений на TFT-экране.

Протестировал с моим Tele2 - показывает одну палочку, ну да и не удивительно - плохо ловит Tele2.

@promavto - Саш, тестируй. Вроде всё учёл - при отрисовке сперва стирается сегмент, потом - либо рисуется закрашенный, либо - незакрашенный, в зависимости от уровня сигнала. Всего уровней - 5: все четыре сегмента незакрашены - нет сигнала, далее - каждый закрашенный сегмент - плюс 25% к уровню сигнала.

Всё, я спать, запарился с этими рюшечками

 

у меня подобная фигня была, когда с МТС-свистком боролся. Тоже несколько станций, уровень сигнала плавал, а свисток в автомате постояно переключался на более сильный сигнал - с 4G на 3G и обратно.

 

Раз у нас пошла тема с информационными иконками на TFT - считаю, будет полезно иметь информацию, есть ли соединение с GPRS через SIM800, ну и статус Wi-Fi - тоже чего-нибудь придумаю. Сегодня постараюсь прикрутить

 

Обновил на гитхабе, добавил статусы соединения по GPRS и к роутеру в виде иконок на экране ожидания TFT, в правом верхнем углу.

 

Ну ты замучил уже. Решил доложить, что работает, а эта версия уже устарела.
Итак, все работает! Уровень сигнала показывает, мелочь а очень приятно. Была мысль, добавить бы и уровень WiFi, но побоялся озвучивать, да и точно не знал есть такая команда или нет. Похоже начинаем думать одинаково.
Кстати, по уровня сигнала. Есть такая особенность. Когда модуль подключился к базовой станции (мигает NETLIGHT 3000 ms), уровень на индикаторе показывает "0". С одной стороны как бы уже есть контакт со станцией, но с другой (а у меня это регулярно), не факт что подключится к интернет. И только когда подключиться к интернет, на индикаторе показывается уровень сигнала. Есть два варианта. 1) оставить как есть.
2) Может измерять уровень когда подключился к базовой станции и подсвечивать индикатор красным цветом. А уже когда подключился к интернет (мигает NETLIGHT 340 ms), индикатор подсвечивать зеленым цветом. В этом случае будет понятно, крути антенну или переноси теплицу.

И предпоследнее - вставь пожалуйста в конец setup строчку очистки буфера порта.
while (Serial.available() Serial. read();

А то при подключении конфигуратора в начале лезет всякий мусор из порта. Мне все равно, но клиенты будут тыкать пальцем.

Ну и последнее. Не знаю что еще можно усовершенствовать. Осталось одно - избавиться от
74HC595. В следующей версии контроллера специально заменю эти регистры на MCP23017.
Мучайся потом.

 

Ошибочка при копировании: правильно while (Serial.available() Serial. read();
Правда при обновлении программы первый раз все равно лезет мусор, но потом все нормально.

Загрузил новую версию. Предлагаю индикатор WiFi немного отодвинуть от GPRS и подписать.
Возможно индикатор "антенну" оставить, но добавить шкалу уровня. Не совсем понятно какой уровень WiFi слишком мелкий индикатор.

 

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

Ок, сделаю и отпишусь.

Категорически - НЕТ! Заменишь - живи потом с этим сам. Трогать код управления фрамугами - НЕ БУДУ, писал неоднократно. Что плохого в 74HC595 - не знаю, нормальная микросхема, пусть живёт в проекте. Саш, я серьёзно - лучше не трогай, я в таком случае принципиально ничего менять не буду. Когда-нибудь, я писал уже об этом - когда-нибудь я, возможно, доберусь и до этого. Но когда это будет - хз, пока же - не вижу проблем при использовании 74HC595.

 

Нет у ESP AT-команды для получения уровня сигнала. Надо прошивку корёжить, разбираться. Поэтому пока - просто иконка: серая - нет коннекта к роутеру, голубая - есть коннект к роутеру. Остаётся как есть - это просто справочная информация. Подписывать - не нужно, это стандартный значок Wi-Fi, ежу понятен, есть на всех смартфонах и т. д. и т. п.

 

@promavto - обновил, подвинул иконку WiFi левее, добавил очистку Serial. По поводу значка Wi-Fi - потом перерисую на более яркий и более плоский, чтобы было посхематичней и понаглядней. По поводу уровня сигнала - пока почитаю, что там есть по этому поводу в API от Espressif, и если найду - допилю прошивку для ESP и добавлю AT-команду. Потом уже - можно будет думать, что делать с иконкой уровня сигнала для ESP: вполне вероятно, что придётся ручками отрисовывать, отказавшись от рисунков (которые юзаются сейчас). Так что пока - рефлексировать на качество рисунков не стоит

 

Индикатор WiFi при отсутствии подключения к точке (у меня их несколько на разном расстоянии) показывает максимальный сигнал. Возможно он меряет сигнал всех точек, независимо подключен или нет к конкретной точке. Нужно смотреть datasheet.

 

Аааа! понял