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

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

Ещё раз повторите в деталях, плз: что я должен сделать, чтобы у меня не стартовало? У меня USE_FEEDBACK_MANAGER раскомментирован сейчас, стартует нормально. Чтобы поймать зависимость - мне надо, как минимум, знать ваши настройки прошивки - какие модули у вас выключены, какие - включены. По процитированному выше сложно понять, что именно у вас происходит.

Замечу лишь, что USE_FEEDBACK_MANAGER должна использоваться с USE_TEMP_SENSORS, т. к. работат совместно с модулем окон. Использовать её без модуля окон - некорректно.

 

@evgeny1241 - просмотрел код, никакого криминала в использовании USE_FEEDBACK_MANAGER - не нашёл. Даже если USE_TEMP_SENSORS закомментирована - там этот вопрос обрабатывается директивами условной компиляции.

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

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

 

Обновил на гитхабе, попытка заставить шину I2C под Due не виснуть при старте. Что было сделано:

1. Все вызовы Wire. begin из всех классов, использующих I2C - были закомментированы;
2. Вызов Wire. begin помещен в самом начале setup;
3. Перед вызовом Wire. begin на шину SCL подаётся несколько импульсов, для прочухивания.

На мега, как обычно, всё работает, как и работало. Как будет на Due - будем пробовать, несколько раз передёрнул контроллер - стартует, но несколько раз передёрнуть - явно недостаточно для удовлетворения (поручик, молчать! )

 

Проверил, все равно виснет. Отключил все - не помогло. Зависает, если повторно нажать сброс через 3-5 секунд. Зуммер пищит постоянно. Экран белый.

 

Я несколько раз передёргивал питание, Саш.

Блин, ты экран не отключил что ли в настройках? Я же тебе говорил - надо на МИНИМАЛЬНОЙ конфигурации выяснять, в чём проблема, понимаешь? Оказывается, у нас USE_TFT_MODULE раскомментировано. Ну ёп. Саш, мы решаем проблему I2C, или пытаемся иголку в стоге сена найти?

Задача: отключить всё нахер, кроме часов и памяти, всё. И смотреть - будет ли виснуть. Можешь в терминалке настроить периодический опрос контроллера любой командой - и смотреть, когда он зависнет. в программе Terminal (не та, что виндовая, а вот эта:



это делается макросами на раз.

Это значит, что зависает ПОСЛЕ того, как после инициализации TFT класс поддержки TFT пищит пищалкой (см. строку 2020 в файле UTFTMenu. cpp). Т. е. ПОСЛЕ того, как прошла инициализации экрана, но ДО ТОГО, как закончился setup. После инициализации TFT в setup только строчки:

Код:

controller.RegisterModule(&zeroStreamModule);
// модуль алертов регистрируем последним, т.к. он должен вычитать зависимости с уже зарегистрированными модулями
  controller.RegisterModule(&alertsModule);

  controller.begin(); // начинаем работу

  // Печатаем в Serial готовность
  Serial.print(READY);

  #ifdef USE_DS3231_REALTIME_CLOCK
 
   DS3231Clock rtc = controller.GetClock();
   DS3231Time tm = rtc.getTime();

   Serial.print(F(", "));
   Serial.print(rtc.getDayOfWeekStr(tm));
   Serial.print(F(" "));
   Serial.print(rtc.getDateStr(tm));
   Serial.print(F(" - "));
   Serial.print(rtc.getTimeStr(tm));
     
  #endif

  Serial.println(F(""));

  #ifdef USE_LOG_MODULE
    controller.Log(&logModule,READY); // печатаем в файл действий строчку Ready, которая скажет нам, что мега стартовала
  #endif

Всё. Если ты утверждаешь, что проблема в I2C, значит единственное, на что остаётся грешить - это вот на эту строчку в setup:

Код:

DS3231Time tm = rtc.getTime();

Именно там происходит работа с I2C. Почему виснет - не знаю, не должно оно виснуть. Ты можешь открыть терминалку, подконнектиться к контроллеру и смотреть, что выдаёт в порт при нажатии reset? В момент, когда повиснет, там должна быть хотя бы часть слова "READY", но не будет времени, если проблема с I2C.

Я сам тоже так попробую, и отпишусь. А тебе пока советую начать с МИНИМАЛЬНОЙ конфигурации - никаких экранов, ничего, кроме часов и памяти. Вылечишься тут с вами, блин - пошёл смотреть, что происходит с Due.

 

@promavto, подключил контроллер Due к компу, открыл монитор порта. Раз пять передёрнул reset - и контроллер тупо повис, не доходя до писка. Вывод - при reset не всегда корректно сбрасывается контроллер.

Отключил от USB, подключил снова. Жмакал reset не меньше 20 раз - ни одного зависания, время в мониторе порта показывает. Вывод - I2C стартует нормально.

Кмк, надо прошерстить проблему аппаратной части, а именно резета контроллера. В первый раз, когда он повис, очевидно, что дело даже не дошло до setup.

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

 

@promavto, обновил на гитхабе. Скачиваешь последнюю версию, идёшь в Configuration_DEBUG.h, находишь там и раскомментируешь строчку #define DUE_START_DEBUG. Компилируешь и заливаешь прошивку. Открываешь монитор порта, и смотришь на циферки - в setup сделал аж 36 промежуточных контрольных точек. Последнее выведенное число при нормальном старте должно быть 36. Если это не так, например, последнее число 25, то идёшь в Main. ino, и ищешь там строку START_LOG (25); (на примере последнего числа в мониторе порта 25). Значит, в промежуток между этой строкой и следующим выводом START_LOG - произошла бяка. Отписываешься мне по результатам.

 

Дима привет, как здоровье? Загрузил, зависает на часах.
26
27
28
29
30
31
32
33
34
READY,

 

Здоровье хреново, прихватило дай боже Вот смотри - у тебя зависает на часах. У меня - на часах не зависает, у меня при нажатии reset иногда просто камень не стартует. Ты что-то там долго мудрил с I2C, и наши платы сейчас - разные по части железа. Какой из этого можно сделать вывод? Если осторожный - то МК неправильно пересбрасывается. Я уже, как ты видел - добавил выдачу 8 импульсов на SCL перед стартом Wire. begin. После 8 импульсов ведомые ОБЯЗАНЫ отпускать шину, если именно они её держат. Но: на момент, когда у тебя виснет - если и была работа с I2C (модулей много) - то ТОЛЬКО с памятью EEPROM. Т. е. если ведомый как-то неправильно работал с шиной - то проблема может быть не в часах, а в памяти. Из памяти читает модуль правил, например - и читает в момент своей регистрации в системе как раз (т.е. до первого опроса часов).

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

 

Железо у нас почти одинаковое. Я только добавил буфер шины I2C и немного поработал со схемой сброса. Так как предполагал, что сброс формируется плохо. Даже заказал в Китае специальную микросхему, драйвер сброса (пока не получил). В самом микроконтроллере есть специальный драйвер сброса и контроля питания. Поэтому применение дополнительной микросхемы сброса вряд ли изменит ситуацию. Но учитывая что начальное выполнение других программ (до пункта 34) выполняется нормально. Это означает - не в сбросе дело. Вернее сброс не сбрасывает шину SDA в исходное состояние. А вот у кого не сбрасывает (микроконтроллер или внешние микросхемы) не совсем понятно понятно. Я дополнительно завел сигнал сброса на микросхему часов (по умолчанию он висит в воздухе и поддерживается внутренним резистором), но это не изменило ситуацию.

Была мысль совсем с другой стороны, хочу перепроверить. У нас применяется микросхемы MCP23S17 с протоколом SPI. Не знаю каким боком, но может есть какая то зависимость. Несколько лет назад у меня были проблемы с библиотеками этих микросхем. У меня есть пару микроконтроллеров теплицы в которых применяются микросхемы MCP23017 протокола I2C. Протестирую на них поведение схемы.

Вторая мысль, как мне кажется ближе к истине, какой то не учтенный баг в протоколе шины I2C. Попробую сравнить наш протокол с протоколом другой (работающей) библиотеки. Переделывать, конечно не нужно (знаю твое отношение к этому). Но может будет достаточно добавления какой либо команды или настройки. Предполагаю, что библиотеки писали индусы (они частенько обнаруживаются в иностранных компаниях). Я немного расист в душе, и не очень доверяю выходцам не из европы.

Очень любопытно как устроена библиотека I2C от разработчика микроконтроллера. В библиотеках на STM32 эта процедура хорошо описана. Поищу аналогичную документацию и на Atmel.

 

Проверил контроллеры c MCP23017. Точно также зависают. Значит дело не в шине SPI.

 

Я писал выше - дело не в часах. Дело в памяти - ДО получения инфы из часов идёт работа с памятью по I2C - читаются настройки тех же правил. Ты эту часть моего комментария читал?

По поводу сброса - когда у меня виснет - дело не доходит даже до setup, вообще. Это именно некорректный сброс МК, пмсм.

 

Саш, не путай Я тебе говорил о том, что крайне, крайне плохое решение - это реализовывать работы с I2C в конкретном классе, например, работы с часами. Должен быть HAL, роль которого выполняет библиотека Wire. Её можно и поправить, если что. Но править - именно её, не классы работы с часами, памятью, другими датчиками на I2C - а именно класс HAL, в роли которого выступает библиотека Wire. Это самое грамотное архитектурное решение, другого быть - просто не должно.

 

Дима!
Верну с небес на землю...
В меге так и не стартуют нормально окна (после ресета).
Идет закрытие секунд 5 (обе фрамуги) и стоп. Мои 75 секунд не отрабатываются. Далее кмк сразу опрос правил, и если по правилам окна д. б. открыты, то стоп.(Статус окон остается открыты, хотя реально промежуточное положение. Соответственно в перспективе перегрев теплицы).Если по правилам окно д. б. закрыто, то доходят по крайнего положения.
Конфигуратор честно пишет 75 секунд, но реальные сигналы как я выше писал-секунд 5.
Реальный статус окон в ручном режиме в конфигураторе отследить сложно-живет своей жизнью.
Вот два последовательных скрина-закрываются и после отрабатывания положенного времени сразу открыто
А этот скрин вообще не понятен-одновременно и открыто и закрыто
Здесь примерно то же, но столбец "Управление" в конфигураторе пустой
Вот два скрина одного и того же состояния окон из конфигуратора и вебморды.
Концевики не использую, гирокомпасы тоже. Прямое управление окнами.
Кмк, все началось с момента привязки в прошивку компасов.
В прошивке вот эти параметры не нужно подстраивать?

#define FEEDBACK_MANAGER_WAIT_TIME 15000 / если в течение указанного кол-ва миллисекунд после старта контроллера не придёт информация
/ по положению окон - окна принудительно погонятся контроллером в закрытую позицию, чтобы обеспечить начальную точку отсчёта
#define FEEDBACK_MANAGER_UPDATE_INTERVAL 5000 / через сколько миллисекунд запрашивать информацию у модулей обратной связи
#define FEEDBACK_MANAGER_POSITION_HISTERESIS 500
?
По поводу gprs-а.
Около недели отработал без сбоев.
Вчера глюканул. Сегодня просто не было времени разбираться с логами-окна все свободное время съели.
А reset по смс очень актуален.
Вроде ничего не забыл...

 

Вчера-таки победил некорректную работу GSM модулей. "Спасибо" китайским обозначениям на Mege TX&RX. Тема озвучивалась, но о прошлом годе сия чаша миновала меня, а нынче подзабыл и два дня просто убил(
Сегодня запустил контроллер в работу в теплице. Второй сезон.
Диме - гран мерси!