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

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

Сейчас замерил скорость заливки всего экрана у 7-дюймов TFT - 103 миллисекунды. Это только заливка фоновым цветом. На скорости 57600 за это время по UART может прилететь примерно 590 байт, что (надеюсь, все заменяли файл HardwareSerial. h, что лежит на гитхабе?), т. е. при уже расширенном до 128 байт буфере Serial - 4,5 приёмных буфера.

Вот это вот - и есть печалька, собственно. Я тут крутил/вертел по всякому, прикидывал про немедленное реагирование по приходу байта в Serial (вклинивание в Wiring), так вот: это тоже нетривиальная проблема, т. к. прерывание - оно на то и прерывание, чтобы прерывать основной код. Т. е. оно будет прерывать и код работы с ESP, когда я там что-то с буфером делаю. По итогу, если так и делать - получается дикая жесть с обеспечением безопасной работы с буфером, т. к. память постоянно перевыделяется динамически. Короче, куда ни кинь - везде клин.

Пока будем исходить из другого: за 1 миллисекунду у нас может прилететь пускай 6 байт. При размере приёмного буфера в 128 байт (надеюсь, все заменяли файл HardwareSerial. h, что лежит на гитхабе?) получаем, что максимальная длина паузы, которую мы можем БЕЗОПАСНО проглотить, до переполнения буфера - это 128/6 = 21 миллисекунда, негусто.

RS-485 у нас блокирует выполнение максимум на 6 миллисекунд, хорошо, этот вопрос пока откладываем. Остаются медленные операции работы с дисплеем, в частности - заливка его фоновым цветом. И, по закону подлости, обязательно в этот момент что-то длинное свалится в UART: либо SMS придёт, либо данные от ThingSpeak и т. п. Короче, надеяться на лучшее тут сильно не стоит, проще предотвратить, так сказать.

Сегодня попробую покорёжить библиотеку UTFT, вставляя вызовы yield, где можно - посмотрим, скажется ли это на работоспособности библиотеки. Если таким способом можно будет решить проблему долгой блокировки - это уже хорошо, ибо, как я писал уже выше - если влазить в логику Wiring - это значит опять полностью пересматривать и логику работы с моими динамически выделяемыми хранилищами больших входящих данных по UART, как минимум.

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

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

 

Кто то вроде хотел дополнительное кнопочное управление? На платке 7 кнопок и светодиод, работает по RS485, да специально не использовал SMD

 

Я, я хотеть такую плату, очень хотеть, сильна хотеть Вижу, что под стандартные модули (Pro Mini и китайский модуль RS-485), что есть оченно даже гуд в моём случае Моя хотеть новые бусики

 

Так, ребята - обновы на гитхабе:

1. Библиотеку UTFT надо ОБЯЗАТЕЛЬНО переставить из архива в папке Libraries !;
2. Провёл оптимизацию по критичным ко времени операциям (и для LCD при прорисовке почаще yield вызываю, ну и UTFT немного покромсал, чтобы под Due обеспечить более частые вызовы yield);
3. Понимаю, что не все любят читать инструкции, однако - кое-что надо делать перед первой компиляцией проекта, поэтому специально для всех - прямо ВВЕРХУ файла Main. ino (он откроется в первой вкладке всё равно, и всё будет на виду) описал, что надо сделать перед первой компиляцией проекта. Это очень важно, поверьте!
4. Раз у нас TFT медленный, а оперативки у Due всё равно вагон, который нам не осилить (и слава богу), то увеличил размер буферов для всех Serial со 128 байт аж до килобайта (инструкции, как это сделать у вас - сверху в файле Main. ino) - теперь даже на относительно медленных операциях (которые уже разбавлены yield) всё должно быть ок (ттт): по расчётам выше самая медленная операция (заливка экрана) занимает время, чтобы принять аж полкилобайта данных. Однако, сейчас эта операция уже не блокирует так надолго - это раз. Ну и два - приёмный буфер теперь целый килобайт, не жалко ни капли.

Проверил под Due - работает, оперативки ещё 70 килобайт с гаком, вот бы под Мегой так было . Проверил под Mega - замедления отрисовки LCD не заметил, оно и так медленное, как полудохлая коза. Если замечу проблему с переполнением буфера из-за LCD - влезу в u8glib, там тоже можно поставить yield где-нибудь, надеюсь.

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

И да, не забываем: SD-карточка в текущих реалиях - практически неотъемлемый атрибут проекта. Вот я забыл из Due переткнуть карточку в Mega - и проблем-с, висим, ждём инициализации карточки, потому что многие модули её требуют. Так что если вдруг что не так идёт - убеждаемся, что SD-карточка вставлена

Вот так вот потихоньку всё и причешем. Не без вашей помощи, друзья, за что вам всем огромное спасибо

 

Скачал обновления, выполнил все инструкции и DUE теперь работает с конфигуратором! Проблема исчезла!

 

Где то видел рекомендацию, причем от "производителей", не делать буфер Serial >256 байт.
Думаю, связано с разрядностью и атомарностью.
Или увеличение буфера - только для DUE?
ЗЫ времени пока нет, собрался на выборы, вернусь поищу, если надо.
ЗЗЫ Все, увидел Main, забираю слова обратно, но как удалить пост - не нашел.

 

Не, ни с атомарностью ни с разрядностью это никак не связано, это связано только с размером оперативки доступной В Wiring буфера для Serial* используются, чтобы, в частности, при приёме байта по UART сложить его в этот буфер, да и всё, собственно. Т. е. никаким таким сторонним эффектом увеличение буферов не чревато, имхо. Что касается DUE - там оперативки вагон, TFT - медленный, для заливки 7-дюймового экрана одним цветом идёт выполнение аж 385000 записей в шину, за это время буфер любого размера может забиться под завязку, как следствие - последующие байты будут просто игнорироваться - так написан HardwareSerial в Wiring, можете посмотреть исходники

Если же про адресацию - то это дело компилятора - расположить эти буфера так, чтобы они были доступны в пределах нижних 64К памяти. Увеличив размеры буферов для Due до 1К - разницы в работе я не заметил.

Если найдёте ссылку на встреченную вами рекомендацию - киньте плз, интересно почитать.

 

Нашел. Как раз с атомарностью и разрядностью.
Из HardwareSerial. h

При индексе > 255 он становится 16 разрядным,

т. е. в 8-разрядной системе за раз его не инкрементировать, да и косвенная адресация (если она есть в avr, я только интеловские асмы знаю) не будет так просто, быстро и атомарно работать.

ЗЫ Хотя странно, коментарий написан для всех систем. Забыли про DUE?

 

С разрядностью у Mega всё норм, там стоит uint16_t для случая > 256, да и не используем мы буфер больше 256. Что касается Due - посмотрел, там объявлено

Код:

volatile uint8_t _aucBuffer[SERIAL_BUFFER_SIZE] ;

Т. е. просто массив байт нужного размера. В RingBuffer. cpp проблемы с разрядностью не видно, там просто в одном месте

Код:

int i = (uint32_t)(_iHead + 1) % SERIAL_BUFFER_SIZE ;

Так что всё должно быть норм, собственно

Спасибо за ссылку, внимательно почитаю и подумаю - грозит ли нам это чем-то или нет, в случае с DUE.

 

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

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

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

 

Если 8-битная система - AVR, то за раз можно не только инкрементировать, но и складывать с 6-бит числом (см. команду ADIW). Косвенная адресация есть. Быстро работать будет. Атомарность соблюдается (если не одна команда, то см. пару CLE - SEI).

 

Владимиру Александровичу - за поддержку.

 

@DIYMan, Как у вас ведёт себя DUE после передёргивания по питанию? У меня - что-то не понятное: вроде не зависает, и в то-же время начинает сильно тормозить! Тоесть, при включении после исчезновения питания 7" дисплей отвечает с большой задержкой, конфигуратор подключается не всегда, а если подключается - то тоже тормозит. Время RTC не в конфигураторе, не на дисплее (всё что угодно, но не время) не отображается? Что делать?
Помогает только перезаливка прошивки, больше ничего...
А это не есть хорошо, т. к. в деревне часто пропадает липездричество!

 

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

Не, прошивка как прошита - так прошита. Пробуйте просто выключить питание на полминуты хотя бы, потом - включить. В чём проблема - надо изучать, но кмк, дело в не совсем корректной инициализации камня, я тут не при делах. Возможно, дело в не совсем корректной инициализации дисплея иногда - опять же, пока не могу сказать, в чём конкретно дело. Сергей @HANTER333 сейчас разрабатывает плату, одевающуюся сверху на Arduino Due - вот на ней и будем обкатывать, решать такие вот вопросы. Дело житейское, всё решится со временем

 

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