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

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

Прошивка для ESP чуть подпилена, все три ESP, что стоят на разных платах - перешиты на скорость 57600, прошивка для контроллера теплицы перепахана порядно, появились новые настройки для датчиков SMS статистики по умолчанию (если вдруг на SD ничего не записано), появилась возможность выкл в SMS статистики информации по окнам и поливу (вдруг не надо кому). Убраны некоторые путающие людей настройки, теперь всё стало попроще, кмк.

Запустил внутренний тест, погоняю несколько часов. Если всё будет ок (ттт) - можно будет выкладывать на общее тестирование. Знаю, что ещё тонкие места есть, сознательно пока не копал работу с RS-485 (хотя возможность оптимизации заложил) - там всё блокирующе, по 30 байт пакеты, за это время, теоретически, может случиться что-то плохое с ESP и SIM800 - прокиснет буфер, например. Это всё надо, ессно, будет ещё плотно тестировать. Пока форсировать изменения в работе с RS-485 не стал, т. к. сломать всегда легче, чем построить

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

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

Вот что мешало создателям Wiring сделать ОЧЕНЬ ПРОСТО, на примере:

Код:

#if defined(UART1_RX_vect)
ISR(UART1_RX_vect)
#elif defined(USART1_RX_vect)
ISR(USART1_RX_vect)
#else
#error "Don't know what the Data Register Empty vector is called for Serial1"
#endif
{
  Serial1._rx_complete_irq();
// СТРОЧКА НИЖЕ - ДОБАВЛЕНА МНОЙ
if(Serial1RXImmediateReaction) Serial1RXImmediateReaction();
}

Где Serial1ImmediateReaction объявлена как:

Код:

void Serial1RXImmediateReaction() __attribute__((weak));

Всё, ребята, всё! И каждый, кто хочет НЕМЕДЛЕННО реагировать на появление в приёмном буфере Serial1 нового байта - просто объявляет эту функцию (тупой пример - ниже):

Код:

String espBuffer;
void Serial1RXImmediateReaction()
{
   while(Serial1.available()) espBuffer += (char) Serial1.read();
}

И всё - НИКОГДА не пропадёт ни один байт в критичных местах. При этом сохраняется ПОЛНАЯ совместимость с тем кодом, что уже есть и периодически вычитывает из приёмных буферов Serial*.

Вот что им мешало? Какая идеология?

 

По ходу тестирования, после полутора часов работы, поймал пересечение по памяти, когда одновременно упали с ThingSpeak почти 400 байт, и пришла рекламная SMS от GSM-провайдера. Как итог - контроллер в панике

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

Перезалил код, тестирую. С SIM800 ничего не сделаешь, если приходит +CMT - оно валится в порт целиком, и если это полное SMS на кириллице - это минимум 300 байт памяти надо, чтобы его проглотить нормально. Будем посмотреть, как оно, тем более что сейчас - самое благоприятное время: все так и приглашают на выборы разными путями - через SMS в том числе Вот и будем смотреть, как оно

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

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

 

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

Поймал ситуацию, когда два исходящих клиента попали в один таймслот на запрос коннекта - по итогу ThingSpeak отвалился Не поставь я каждые 30 секунд на отсыл на ThingSpeak и каждые 45 секунд на отсыл на gardenboss. ru - ни в жисть бы не выловил, а тут - по логу всё видно:

Как видно - ещё не были отработаны результаты подсоединения одного клиента, как в тот же слот сунулся второй. Сложность тут в том, что я заранее не знаю - свободен этот слот у ESP или нет: во время, пока в ESP отсылается команда, на этот слот может придти коннект с вебморды, и когда команда с контроллера дойдёт - слот уже тю-тю, занят. Я, конечно, храню состояние слотов в контроллере, но полная синхронизация возможна только по факту ответа от ESP (вот эти самые 1, CONNECT или ALREADY CONNECTED). Поэтому до факта ответа от ESP у клиента нет привязки к слоту, т. е. он как бы - сиротка без роду без племени. Вот эта сиротка ThingSpeak и затерялся, потому что второй жирнючий дворовый пёс полез поперёк первого. Поправил код, очередной этап тестирования ESP; его бы откатать, да за SIM800 вплотную уже взяться. А там - конфигуратор прогнать хоть чуть-чуть - вдруг чего выплывет, кто знает...

З. Ы. Уже начинаю побаиваться писать на форум Но дело, как показывает практика - хорошее: сразу новые баги выползают из-за угла, посмотреть - чой-то он там написал на форум, неужели хвалится, что всё работает?

З. З. Ы. Уже много повыловлено, и это хорошо. Как и обещал - постараюсь на днях выложить обновы.

 

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

Обновления:

1. Прошивка для ESP - теперь скорость 57600, пока на ней и остановимся;
2. В прошивке контроллера: допилена работа с ESP, чутка повставлял вызов критичных ко времени действий, куда только можно, полностью переписан модуль работы с SIM800 (теперь есть полноценный транспорт, а не набор кусков кода), добавлены новые настройки, убраны некоторые неактуальные старые;
3. Из важного: сделан нормальный интерфейс для вывода отладочной информации - теперь вывод отладочной информации не блокирует другую работу, как было раньше (пока не выплюнет всё в Serial - не отпустит), что исключает в этой части протухание буферов ESP и SIM800.

Вебморда работает стабильно, память (ттт) не течёт, по MQTT топики ходят, в сеть - данные отправляются. Тестовый исполнительный модуль по RS-485, собранный на макетке из г@вна и палок - отзывается, на команды реагирует, ESP и SIM800 не глушит. Линия регистрации через конфигуратор - работает, модуль видит.

Чой-то я немного поднапрягся с этими перепиливаниями, хочу чуть-чуть откиснуть от проекта, с вашего позволения - буквально на несколько дней Надеюсь, к тому времени вам будет что мне предъявить Но в целом - код стал лучше, честно-честно - теперь он больше похож на код проекта с большой нагрузкой, кмк. Конечно, это не финиш, например, под Due не тестировал ещё, там есть одна потенциальная засадка, которая не даёт мне покоя, а именно - огромный TFT-экран и, как следствие, порядочное время на некоторые операции, типа заливки всего экрана фоновым цветом - ожидаю, конечно, лучшего (что библиотека UTFT вызывает yield периодически), но, как водится - морально уже готов на всё

Что ещё сказать - не знаю, надо гонять в хвост и в гриву, надеюсь, вы в этом поможете, мои дорогие друзья Очень жду отзывов. Всем добра.

З. Ы. Ага, хренушки там (это я про UTFT):

Код:

void UTFT::fillScr(word color)
{
    long i;
    char ch, cl;
   
    ch=byte(color>>8);
    cl=byte(color & 0xFF);

    cbi(P_CS, B_CS);
    clrXY();
    if (display_transfer_mode!=1)
        sbi(P_RS, B_RS);
    if (display_transfer_mode==16)
        _fast_fill_16(ch,cl,((disp_x_size+1)*(disp_y_size+1)));
    else if ((display_transfer_mode==8) and (ch==cl))
        _fast_fill_8(ch,((disp_x_size+1)*(disp_y_size+1)));
    else
    {
        for (i=0; i<((disp_x_size+1)*(disp_y_size+1)); i++)
        {
            if (display_transfer_mode!=1)
                LCD_Writ_Bus(ch,cl,display_transfer_mode);
            else
            {
                LCD_Writ_Bus(1,ch,display_transfer_mode);
                LCD_Writ_Bus(1,cl,display_transfer_mode);
            }
        }
    }
    sbi(P_CS, B_CS);
}

Хоть один yield в цикле видите? И я тоже - не вижу. Печальбеда. Ну ничего - доберёмся до плотного тестирования под Due - и это дело, если выплывет проблема - будем фиксить

 

Немножко обновил, для повышения совместимости с разными типами настроек. У нас, как известно, можно по всякому настраивать прошивку, например, не иметь ни одного окна, пришпиленного к контроллеру, а вынести всё по RS-485, например. Соответственно, сие действо требует некоторых хитростей при настройке. И если раньше всё равно надо было оставлять те же пины управления сдвиговым регистром на меге свободными (даже если никаких окон прямо к ней не пришпилено), то теперь - достаточно просто указывать такие пины, как пины с номерами больше 80, т. е. с номерами больше VIRTUAL_PIN_START_NUMBER - эта настройка тоже есть). В такие пины, соответственно, ничего физически не пишется, просто их состояние сохраняется в карте пинов, и всё.

Т. е., указав для какого-то функционала номера пинов больше, чем VIRTUAL_PIN_START_NUMBER - получил следующее: в порты МК ничего не пишется, однако в карте состояния пинов это дело отображается. Соответственно, привязав исполнительный модуль к такому виртуальному пину - имеем отображение его состояния по шине RS-485

Собственно, так было и раньше, просто с окнами поправил чуть-чуть: там писалось напрямую в сдвиговый (при настройке USE_WINDOW_SHIFT_REGISTER), что есть - нехорошо. Теперь этого недочёта уже нет

Для состояние контроллера, которое по шине пихается - у нас 128 пинов, т. е., если виртуальные пины начинаются с 80 - там доступно аж 48 пинов виртуальных, кмк, норм.

 

Вроде бы работает, не виснет.

 

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

 

Что-то перестал работать конфигуратор с платой DUE! При подключении: "ждём данные из порта" - и всё! Подумал, что Я олень, попробовал на МЕГЕ, - всё работает!, А на DUE - не хочет!

 

Я уже писал выше, что на Due я крайние изменения не тестировал, от слова "совсем". Теоретически - всё должно работать и там, сходу не вижу причин, чтобы не работало. Попробуйте пока отключить USE_SMS_MODULE и USE_WIFI_MODULE и посмотрите - изменилось что или нет. Проверьте, закомментированы ли отладочные режимы. Попробуйте не юзать TFT пока, как вариант. Надо найти минимальную конфигурацию, на которой работает, и потихоньку раскомментировать, чтобы понять, на какой - перестало работать.

Я уже упоминал о том, что решение с периодической вычиткой из Serial* - не панацея, т. к. это не спасает при длинных операциях, а TFT - оооочень медленный. Поэтому, возможно, что-то идёт не так.

Вы можете проверить, что и как происходит, без конфигуратора - включив отладочные режимы и посмотрев монитор порта. Я пока не готов к тестированию нововведений на Due - считаю, что надо сначала сделать, чтобы работало как часы на Mega, а уже потом прыгать, как блох на собакене.

 

@tchernyavsky, только что загрузил в Due последнюю версию, закомментировал только USE_WIFI_MODULE и USE_SMS_MODULE - конфигуратор работает. Сейчас буду пробовать раскомментировать эти модули, включать отладочный режим и смотреть, что там.

 

Закомментировал USE_SMS_MODULE и USE_WIFI_MODULE, отладочные режимы - тоже закомментированы. Что-то изменилось: теперь при обращении к порту из конфигуратора DUE пезагружается, но, по прежнему не коннектится.

 

@tchernyavsky, раскомментировал USE_WIFI_MODULE, закачал прошивку в Due, настроил MQTT - ходят данные, при этом конфигуратор открыт. Думаю, то же самое будет и с USE_SMS_MODULE.

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

 

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

 

Буду разбираться! Сейчас уже башка не "варит", попробую с утра.

 

@tchernyavsky - ESP-то перешили крайней прошивкой? Настройки скоростей одинаковые? Пробуйте без конфигуратора, включа отладочные режимы - и простыню с монитора порта сюда можно.