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

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

Нет, статус выдаётся в топике REPORT, без вариантов. На запрос TEPLICA/SET/PIN/10 придёт ответ TEPLICA/REPORT/PIN

Впрочем, вы можете это посмотреть в любом клиенте, подписавшись на все топики.

 

Значит так: вроде потихоньку завелось, намучился изрядно, если честно. Как только пишу сюда тему о том, что всё завелось - обязательно где-нибудь выплывет косяк

Сейчас тестирую на своей прошивке для ESP, но она не нравится по одной причине - иногда ооочень долгий коннект к роутеру. Есть большое желание таки залить последнюю AT-прошивку от китайцев в ESP - и проверить на ней, вдруг взлетит - всё-таки архитектуру переписал.

За конфигуратор пока не брался (это я про топики с расходомеров).

Короче, всё будет

 

По поводу топиков отчёта о выполнении команды: там не всё так просто, смотрите: первое слово после SET или GET - это имя модуля, к которому адресована команда. Модуль может поддерживать овердохрена команд, и каждая из них - с овердохрена параметрами. Т. е. я НЕ МОГУ в топике REPORT отправить обратно все параметры, которые переданы в контроллер, и склеить их в имя топика. Хотя бы потому, что ответ модуля не равен запросу к модулю, т. е. в ответ на TEPLICA/GET/WATER/MODE мне модуль WATER вернёт строку MODE|AUTO, а в ответ на TEPLICA/GET/WATER/T_SETT - там вообще вернётся кучу параметров - и циферки, и прочее - запихивать их как имя топика - нельзя.

Именно поэтому было принято решение к топику REPORT прибавлять только имя модуля, к которому обращались, а всё остальное - в сообщении идёт, либо в формате JSON, либо простым текстом, в зависимости от настроек.

Как то так.

З. Ы. Ну вот, пока писал - сработал ватчдог, контроллер проработал 38 минут Пойду разбираться, уже сил моих нету с ESP. Но добить - надо.

 

Пытаюсь прошить ESP-07 последней прошивкой штатной. NodeMCU с ESP-12E на борту - прошил успешно, немного поразбираться, и всё. А вот ESP-07 - ну ни в какую не шьётся: GPIO2 - на питании, GPIO15 - на земле, GPIO0 - на земле, СH_PD - на питании. При загрузке дёргаю RESET проводком: начинает грузиться, грузится, и Flash download tools говорит мне "ERROR".

Шью так:

Что интересно - если не писать blank. bin - то всё шьётся, но, ессно, не работает. ЧЯДНТ? Уж очень хочется залить штатную прошивку и таки проверить - как с ней будет работать

В инфо о чипе выдаёт вот что:

 

О чудо - стоило только написать сюда, как оно таки прошилось, но, опять же - без blank. bin. Чем это грозит - хз.
Питание надо передёргивать, RESET не помогает.

 

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

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

 

@DIYMan, blank. bin это файл нулями забитый. его заливают чтоб гарантированно затереть следы предыдущей прошивки. т е вначале бланк по всей флеши. потом прошивку

 

Работает по полчаса, потом - как что-то пересекается вместе: зависон. Такая веселуха, скажу я вам, когда всё это зверьё вместе работает (это я про MQTT, ThingSpeak, вебморду и gardenboss. ru) - словами не передать

Ищу причину, в чём дело. В целом всё стабильно, если бы не как в анекдоте про "есть нюанс"

 

@DIYMan, Попробуйте через этот прошивальщик: https://github.com/nodemcu/nodemcu-flasher
У меня через него "дело" лучше шло!

 

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

 

Роутер через юарт

 

Чо творится - не понимаю Вот падает мне в порт строка от ESP: +IPD,1,554: - это значит, что за двоеточием будут данные длиной 554 байта, и они - для клиента номер 1.

Что делать? Ясное дело - раз ESP сообщило, что 554 байта - надо эти самые байты вычитать из UART. Что я, собственно, и делаю, предварительно обложившись тестовым таймаутом аж в 10 секунд. Что я увидел после часа работы? Выпало в этом месте по таймауту, прочитав 550 байт из 554-х.

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

Это, так сказать, одна из фич - неудивительно, что при интенсивной нагрузке вебморда нестабильно работала.

Вторая замеченная фича, которая тоже ловится крайне редко - после отсыла буфера можно тупо не дождаться ни SEND OK, ни SEND FAIL - просто ничего.

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

 

Назовём проблему "проблемой четырёх байт" Вот код вычитки из потока:

Код:

  char ch;
  while(workStream->available())
  {
     if(wiFiReceiveBuff->startsWith(F("+IPD")) && wiFiReceiveBuff->indexOf(":") != -1)
     {
      
        processIPD(*wiFiReceiveBuff);
.....

Вот тут - сразу читаются данные, в функции processIPD:

Код:

while(totalWritten < lengthOfData) // пока не запишем все данные с клиента
            {
                if(workStream->available())
                {                
                  *writePtr++ = (uint8_t) workStream->read();
                  packetWritten++;
                  totalWritten++;
                }
                else
                  continue;

Перед этим - делается чуть-чуть разбора строки, чтобы понять, сколько данных. Программный буфер у UART не резиновый, понятное дело. По факту на скорости 115200 имеем 11500 байт в секунду (грубо), т. е., грубо - 87 микросекунд на байт, если я всё правильно посчитал. Т. е. 64 байта приёмного буфера UART забьются за 5568 микросекунд, или - на 5,5 миллисекунды. Некисло, чо.

Т. е. надо исключить простои на время, длиннее 5,5 миллисекунд, по идее. Иначе кольцевой буфер завернётся в тряпочку, и всё.

Однако: как только я вижу в порту +IPD - я сразу начинаю оттуда читать. Т. е. факт того, что обнаружено +IPD - уже говорит о том, что эти данные лежали в начале кольцевого буфера, и надо только быренько вычитать из потока. Но имеем иногда вот это крайне непонятное поведение в таймаутом по вычитке

Где-то я чего-то не догоняю, видимо. Конечно, проще всего спихнуть на ESP и сказать, что, мол - это её потолок по нагрузке, и иногда там внутри что-то не то происходит. Но мне бы хотелось исключить всякие неоднозначности, прежде чем кивать на сторону.

Надо это победить, и будет сильно лучше, чем текущая версия, по стабильности работы с ESP. Только победить осталось.

 

Цитата с форума по esp, т-щ признаёт, что со стандартной AT-прошивкой почти нереально сделать нормальный конечный автомат:

В последнем предложении упоминаются битые байты, кстати. Ооххх. Вот что он пишет про нагрузку и таймауты:

Короче, на более-менее нормальной нагрузке - выплывают всякие баги ESP, я так понял.

 

32-разрядный проц при частоте 80МГц? Хотя при желании и (не) умении можно и не такое железо остановить)
А если, для пробы, чтоб выловить блох, снизить скорость до 57600?

Хм, так тормозит не ESP?