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

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

Вот, может у кого возникнут идеи, как с этим жить:

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

Есть у кого идеи (помимо снижения скорости работы с ESP, чтобы ошибок фреймов было поменьше) - как вообще с этим жить? Может сто раз нормально послать/принять, потом хлоп! - и вот такая бодяга. Вводить какой-то признак окончания пакета - так не факт, что и этот признак не проглотится во время передачи

Ещё раз подчеркну: как только я вижу в порту +IPD - я только тем и занимаюсь, как вычитываю из порта данные, т. е. вариант "оно там где-то шаро@бится" - сходу не катит. Ясное дело, что прерывания всё равно работают, millis там чего-то считает, по прерыванию в Serial отладочная инфа уходит, но продемонстрированный кусок вычитки - это то, что реально прочиталось с порта ESP _до_ вывода в Serial, т. е. там реально битые данные. На стороне ESP эта строка лежит в оперативке, УЖЕ вычитанная с клиента:

Код:

 int readed = client.read(read_buff,buf_sz);
  if(readed > 0)
  {
    // есть данные, сообщаем о них. Приходится через raise, чтобы не вклиниться между команд
    String toRaise;
    toRaise.reserve(readed + 20); // резервируем буфер сразу
    toRaise = "+IPD,";
    toRaise += clientNumber;
    toRaise += ",";
    toRaise += readed;
    toRaise += ":";
    for(int i=0;i<readed;i++)
      toRaise += (char) read_buff[i];

    toRaise += ENDLINE;

    Events.raise(toRaise.c_str(),toRaise.length());
   
  } // if(readed > 0)

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

З. Ы. Сейчас буду править прошивку под ESP, вставлю везде flush для Serial, нехай никуда не переключается, пока не выпулит данные - надо исключить все тонкости по-максимуму. Дай бог сил разобраться в компоте этом...

 

Потихоньку набирается статистика: выяснил, что таймаут по чтению появляется тогда, когда разбирается CTGET=0|STAT. Т. е. ситуация следующая: ESP не занята обработкой команд от контроллера, и выплёвывает одну за другой в порт строчки

Чуть перед этим мы ей посылаем AT+CIPSENDBUF, но на момент выплёвывания первой +IPD эта команда ещё не добралась до ESP, асинхрон, паанимаишь.

По факту что имеем при таком раскладе: ESP стреляет в порт кучей данных, мы при этом - получаем первую часть

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

Кмк, этот вариант развития событий представляется наиболее вероятным, т. к. поймал два таких пересечения с CTGET=0|STAT - в предыдущем посте и в логе, который запустил уже после очередного зависона. Почему нерегулярно ловится? А вот как звёзды сойдутся - так и поймается.

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

Если фишка в этом - то это уже половина победы: исключим потерю данных при чтении из порта, и всё будет ОК.

 

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

 

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

 

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

Таки есть предложение перевести ESP на 57600 - как думаете, пойдёт? Не очень хочется, но с высокой скоростью я чой-то запарился малясь.

 

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

 

SIM800 тоже придётся переписывать, по ходу - сейчас попробовал СМС послать - ESP отваливается, данные теряются При тяжёлой нагрузке вот такие слабые места и вылетают косяками

Пока потестирую чисто ESP, если с ним всё ОК будет - начну перепиливать SIM800, от Neoway откажусь, не надо оно нам, кмк. Там давно просится код на перепиливание, ибо так коряво разросся - что пипец.

З. Ы. Короче, один хрен - тухнут данные, я уже вычитываю их где только можно. 15 минут работы - и зависон на чтении +IPD. Эх, терпения бы мне побольше... В общем, пока комментирую SMS-модуль, дабы исключить его влияние, хотя бы.

 

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

А ручками самому под мегу и под Due сейчас весь код работы с UART переписывать - это, честно говоря, жесть С другой стороны - я могу поправить исходники, прикрепив там нужный функционал, но это осложнит первоначальную настройку системы перед компиляцией.

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

Дилемма на дилемме

 

Да, по ходу проблема была в SMS-модуле - чего-то он там делал блокирующе, а в это время приёмный буфер ESP протухал. Надо переписывать

 

Почти допилил новую версию кода под SIM-800. Neoway из списка поддержки - вычёркиваем, не хочу возиться даже. Сейчас дописываю первое приближение, но уже СМС ходят и на звонки реагирует.

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

Очень надеюсь, что на днях что-то да родится уже нормальное, под интенсивные нагрузки.

З. Ы. Гляжу, молчаливые все, только "спасибы" ставят Всё будет норм, камрады - кто ж знал, что проект разрастётся до такой степени, когда вылезут критичные ко времени выполнения болячки? Вот и пилим потихоньку, заодно код причёсывается, давно пора

 

Пока автор занят делом, от безделия и от бессонницы лезет в голову всякая фигня.
Ну, а поскольку опытом работы с МК я не обременен, море кода мне не переписывать, ответственности перед пользователями никакой, то рассуждать могу вольно, ни на что не оглядываясь, фантазию свою ничем не ограничивая. Ну может ведь безлошадный крестьянин, лежа на печи, порассуждать о трудностях плантаторства в Африке и какие косы применять при сборе урожая бананов?
Итак надобно автоматизировать тепличное хозяйство и хочется, чтоб было это и управляемо автоматически, и подправляемо ото всюду, где есть электричество и/или радиоволны.
Выбор пал на связку Мега + ESP. А что, нормально, у одной контактов дофига, другая в интернет выходит. Дешево, да и платы девелоперские есть. На них обкатать систему, а там кто хочет так оставит, кто хочет из элементов спаяет.
Платформа выбрана, а теперь бы роли между платами распределить.
Начинаем с ТТХ. А с чего еще, если больше о системах ничего не знаешь? (это я про себя).

Ага, Мега vs ESP.
Разрядность:<->8 против 32
Частота:<->16МГц против 80 (160) Мгц
Память:
Ну тут в лоб не сравнить, потому по кусочкам.

Скомпилируем пустую прогу.

Мега.
"Скетч использует 656 байт (0%) памяти устройства. Всего доступно 253952 байт.
Глобальные переменные используют 9 байт (0%) динамической памяти, оставляя 8183 байт для локальных переменных. Максимум: 8192 байт."

Wemos D1.
"Скетч использует 246043 байт (23%) памяти устройства. Всего доступно 1044464 байт.
Глобальные переменные используют 32208 байт (39%) динамической памяти, оставляя 49712 байт для локальных переменных. Максимум: 81920 байт."
Ого, всего доступно было аж 1 Мегабайт. А ведь даже Билл Гейтс говорил - "640К хватит всем!".
Стартап код, правда, раздут. Но в нем, полагаю всякая вайфай и прочая напихана.

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

Если бы ESP, да кучу GPIO! Ну, да ладно, даже наш президент говаривал про бабушку, которая была бы дедушкой, если у бы нее все было.
Во всяком случае по ТТХ ESP рвет Мегу в разы.
Омрачает жизнь то, что за все нужно платить. За WiFi в бекграунде тоже. Но мы сейчас про идеальный мир, где можно доверяться ТТХ и по нему же сравнивать.
А в нем напрашивается мысль, что сделать главной ESP. Ресурсов и быстродействия у нее с лихвой - и парсить, и управлять, и хранить и т. д.
А Мегу использовать как хозяина пинов.
Можно просто на уровне подай-принеси - включи тот пин, прочитай значение того устройства. Тут, правда может канал обмена стать узким местом.
А можно и поуправлять ей дать немного - держи температуру от сих до сих, будет меньше включи такой то пин (обогрев), больше - такие то пины (форточки).
Выполнять! Будут нештатные ситуации - докладывай! Ну или дергай за фал (interrupt), я сам спрошу.

Фу, выговорился.
Сильно не пинайте, а то я про RTOS рассуждать начну - вам же хуже будет, я в нем совсем ни гугу!

 

Ю. Ревич Практическое программирование микроконтроллеров AtmelAVR на языке ассемблера.
Ю. А. Шпак Программирование на языке С для AVR и PIC микроконтроллеров
А. В, Кравченко 10 практических устройств на AVR-микроконтроллерах
Г. Шонфельдер, К. Шнайдер Измерительные устройства на базе микропроцессора Atmega
Первые две помогут приблизительно понять, что такое программирование (для AVR)
Вторые - как приблизительно должно выглядеть устройство на AVR.

З. Ы. ну и еще кучка apnotes и datasheets от бывшей Atmel

 

Ну программистом я когда то был и контроллеры программировал, правда не микро, а программируемые (так они тогда назывались). И С, и С+ и ассемблер (только для i8080, Z80, i8086 (-286, -386) знал. Даже в Линуксе чуть-чуть моего кода есть (хотя может уже и нет - выкинули или переписали, не смотрел). Вот только давно это было, еще в прошлом веке.
Подзабылось многое. Изучать ли новое?
Хм, уже и лень как то. Только только за 30 лет программизма, а потом админства от компов голову оторвал, на мир глядеть стал не через монитор. Он большой и удивительный, а ночью, оказывается, можно спать и высыпаться.
Потому сдерживаю себя. Не получается у меня спокойно и равномерно. А только запоем, в режиме - всю неделю до 4 утра, суббота, воскресенье на отсып.
Не. Уже не потяну.

 

Ничё, Дим, дачный сезон откроется - все станут бэта-тестерами Причём сразу

 

Вот и надо успеть, постараюсь