Разработки ecoins для дисплея Nextion

[ecoins]

1.Тема Nextion ecoins интересует давно;
2. Ее успешная реализация в том числе реализуется с распределением временных ресурсов контроллера и буферированием обмена через UART.
3. "Медлительность" блоков FLProg Nextion отмечали нескольких пользователей.
4. Этим постом анонсируем начавшую работу по создании библиотеки и блоков для работы с дисплеем NEXTION.
--------------------------------------------------------------------------
Последние версии библиотек размещаются в теме "Экосреда ecoins"
=> viewtopic.php?f=247&t=8064#p114987
------------------------------------------------------------------------

1000_EIS_Library_1.03d_03.02.23.zip

0150_FLProg_UBL_EIS.zip

NX8048P050_012_testFix_03.02.23.zip

Test_NXT_03_030223.zip

[spoiler=Комментарий (частично устаревший)]
Сообщение для тех кому интересна тема "Дисплей Nextion:
1.Вышла версия Nextion Editor 1.6.12. По сравнению с предыдущей версией (0.53) у нее есть важные дополнительные возможности. Поэтому библиотека и блоки разрабатываются под новый редактор.
2.После поиска и исследований выбран следующий протокол обмена:
2.1. Из контроллера в дисплей (NXT) в текстовой форме: va0.val=0x12FA45DE, или va1.val=5 --> Запись in32t_t в NXT (без контроля достоверности). В NXT должны быть зарезервированы переменные va0,va1...и так с запасом, скажем до 32 (размер памяти позволяет). Если передается не существующая переменная, то запись игнорируется.
2.2. Из дисплея в контроллер упрощенное подобие ModBus ASCII:
1-байт - идентификатор начала посылки =':'
2-байт - тип посылки =1 передача байт; =2 передача uint16_t; =3 передача uint32_t;
3-байт - кол-во данных
.... передаваемые данные
n-байт - контрольная сумма
n+1 13 10 (коды завершения посылки).
В блоке FLProg должны будут зарезервированы необходимые буфера. Если данных больше чем буфер, то лишние данные отбрасываются.
Разработанный протокол - компромисс между скоростью и надежностью обмена, а также простотой реализации (в NXT большие программы писать не очень удобно).
-----
3. Дисплей посылает данные в контроллер , если они данные изменились или периодически(например 1раз в сек) для поддержания активного обмена.
Контроллер работает аналогично.
Устройства не ожидают подтверждения об отправленных посылок и потому обмен быстрый.
Прием и передача (RX,TX) независимы.
--------------------
Дисплей с большими возможностями, но имеющиеся программные продукты прямолинейны и тормозные.
Предлагаемая разработчиками библиотека ITEADLIB_Arduino_Nextion_master в наших разработках использовать не планируется - она избыточная, "тормозная" и т.п.
--------------------
Если есть какой-то опыт использования дисплея NXT, идеи по организации обмен, оформлению и т.п. - пишите.
Если есть вопросы по работе NXT - задавайте, ответим.
--------------------
[/spoiler]

Новая версия библиотек и блоков от 01.07.22.
Базовая библиотека (других библиотек не требуется)

RT_00_HW_BASE_v7.05_01.07.22.zip

Библиотеки ПБ

EIS.10==SYSTEM_SIMPLE вер.1.05 (01.07.22).zip

EIS.02---DEVICE_вер.3.05 (01.07.22).zip

EIS.01---SYSTEM вер.3.05(01.07.22).zip

Тестовый пример для дисплея

Test_Nextion_7_v01_010722.zip

Тестовый пример для FLProg

Test_Nextion_7_v01_010722.zip

Test_NXT_03_030223.zip

Платформенно независима, тест проверялся на MEGA2560
===================
Очень полезный вклад от пользователя WildCat -инструкции:

FLPROG-Nxt-Ecoins.pdf

FLProg_Nextion_Ecoins_руководство.rar

nextion_ecoins_рабочий проект.rar

[Dryundel]

2.1. Из контроллера в дисплей (NXT) в текстовой форме: va0.val=0x12FA45DE, или va1.val=5 --> Запись in32t_t в NXT (без контроля достоверности).

Думаю правильней отправлять в формате page0.va0.val=0x12FA45DE - Дисплей принимает.
А без page0 только на активную страницу можно передать.

3. Дисплей посылает данные в контроллер каждые 100мс, если данные изменились или каждые 2 сек для поддержания активного обмена.

А вот здесь я бы пересмотрел алгоритм и скорее всего полностью.
Дисплей Nextion, штука событийная и по моему может что то отсылать только по какому то действию (событию). В оновном требуется отслеживать нажатия. А для этого в нем есть отличная реализация.

2020-12-14_151423.jpg

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

[ecoins]

А вот здесь я бы пересмотрел алгоритм и скорее всего полностью.
Дисплей Nextion, штука событийная и по моему может что то отсылать только по какому то действию (событию). В оновном требуется отслеживать нажатия. А для этого в нем есть отличная реализация.

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

По испытанному: собираю состояния всех бинарных элементов в 32-разрядное слово и отправляю его по изменению каждые 100мс. Это чтобы в случаях ошибок не забивать транзакциями UART. С другой стороны наверное правильно делать тоже, но с ограничением частоты посылки, скажем 50мс.
Наверное так будет лучше. Спасибо.

Думаю правильней отправлять в формате page0.va0.val=0x12FA45DE - Дисплей принимает.
А без page0 только на активную страницу можно передать.

Проверю. В описании val это создаваемые в достаточном количестве глобальные переменные - вроде они не должны быть привязаны к page. Еще раз проверю.

[Dryundel]

собираю состояния всех бинарных элементов в 32-разрядное слово и отправляю его по изменению каждые 100мс

Мне всегда было не понятно зачем это делать. Может Вы мне поясните в чем фишка.
Вот есть у нас переменная. Отслеживаем ее изменение и по изменению отсылаем в UART в нужном формате. Всё. И так со всеми переменными. Для чего надо отсылать весь пакет?

Отправлено спустя 15 минут 11 секунд:

Проверю. В описании val это создаваемые в достаточном количестве глобальные переменные - вроде они не должны быть привязаны к page. Еще раз проверю.

val (который в самом конце) это атрибут элемента такой же как txt, font, bco, pco и т.д.
val0 (который перед ним) это имя элемента.
Там нет переменных как таковых. Любому элементу присваивается любое имя t0, b0, bt0 (по умолчанию) или knopka0, text25 без разницы как назовете.
Есть элемент var который так же имеет атрибут val , единственный атрибут у этого элемента.
На любой странице (хоть на всех) может присутствовать bt0 и каждому такому элементу может быть назначен статус "глобальный"
И кроме как по имени страницы идентифицировать их никак. Либо "разговаривать" только с активной страницей.

Отправлено спустя 7 минут 16 секунд:
Элементы имеют до десятка атрибутов. Их условно и можно назвать переменными. И когда мы что то отсылаем в дисплей, то обращаемся к конкретному атрибуту.
Вот так я понял. Если не прав, поправьте меня.

[grin-mpx]

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

А что будет, если в этот момент контроллер будет находится где нибудь во While. Буфер UART работает в это время?
Команда не потеряется?

[Dryundel]

А что будет, если в этот момент контроллер будет находится где нибудь во While. Буфер UART работает в это время?
Команда не потеряется?

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

[ecoins]

val (который в самом конце) это атрибут элемента такой же как txt, font, bco, pco и т.д.
val0 (который перед ним) это имя элемента.
Там нет переменных как таковых. Любому элементу присваивается любое имя t0, b0, bt0 (по умолчанию) или knopka0, text25 без разницы как назовете.
Есть элемент var который так же имеет атрибут val , единственный атрибут у этого элемента.

Возможно мы говорим о разных версиях Nextion Editor.
Новая версия 1.6.12 внешне почти не отличается от предыдущей 0.53 - но есть немного значимых возможностей.
Появилась возможность использования глобальных переменных как в C++ (возможно только типа int - в дисплее это 32 разряда, другого не проверял), к которым можно обращаться напрямую без указания атрибутов.

Nextion_переменные.JPG

Это позволяет иначе смотреть на процесс проектирования.

Мне всегда было не понятно зачем это делать. Может Вы мне поясните в чем фишка.
Вот есть у нас переменная. Отслеживаем ее изменение и по изменению отсылаем в UART в нужном формате. Всё. И так со всеми переменными. Для чего надо отсылать весь пакет?

В транзакциях есть заголовок, окончание - данные только часть переменной. Для Nextion используемый формат данных - слова 32 бита.
Наполнить эти биты содержанием это способ снижения кол-ва транзакций.
При исследовании с логическим анализатором примера, который прислал один из пользователей, было установлено, что одной из причин "торможения" контроллера Arduino - это поток транзакций, длинных по содержанию и по одной на каждый бит. Поскольку передача в FLProg выполняется без буферирования, то все это набегает на доли секунды и более.
Упаковывать данные в слово - на этот метод указал Rovki как рекомендация при обмене в KaScade через шлюзы.
Метод оказался очень действенным, двухсторонний обмен с KaScaда существенно улучшился (остались огрехи из-за реализации ModBus в FLProg).
Этот же метод мы реализуем и для Nextion. Что в итоге получится предсказать не готов.

Отправлено спустя 4 минуты 56 секунд:

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

Пока проблема только из ардуино - там без буферирования. Но обмен через UART требует в целом осмысленной доработки (буферирования, прерывания) - отчасти и это было причиной переписывания всего кода RT_HW_BASE.h - там такая возможность заложена, обращение к UART уже возможно по его номеру. Если аппаратный UART отсутствует, то компиляция все-равно выполняется без ошибок, транзакции на несуществующий UART игнорируются.
Наличие UART в системе проверяется отдельной функцией.

[ecoins]

Отправлено спустя 2 минуты 49 секунд:

е

А что будет, если в этот момент контроллер будет находится где нибудь во While. Буфер UART работает в это время?
Команда не потеряется?

Стандартный приемный буфер UART обычно равен 64 байта. Для контроллеров с достаточным ОЗУ ('это почти все кроме AVR328) полезно будет расширить до 256 байт. И сделать обработку по прерываниям.

[grin-mpx]

Упаковывать данные в слово - на этот метод указал Rovki как рекомендация при обмене в KaScade через шлюзы.
Метод оказался очень действенным, двухсторонний обмен с KaScaда существенно улучшился

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

[ecoins]

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

Согласен.

[Dryundel]

Новая версия 1.6.12 внешне почти не отличается от предыдущей 0.53 - но есть немного значимых возможностей.
Появилась возможность использования глобальных переменных как в C++ (возможно только типа int - в дисплее это 32 разряда, другого не проверял), к которым можно обращаться напрямую без указания атрибутов.

Так, и что это дает?
На сколько я понял, все что прописано во вкладке program.s* выполняется только один раз при старте дисплея и может быть использована только для резервирования (декларирования) этих глобальных переменных.
Дальше что?
Что делать пользователю-обывателю с этими переменными?

Блин! Бесит! Эти разработчики сначала пытаются создать удобный девайс для рядового пользователя. Потом извращают правила С++, а теперь наворачивают еще и системные переменные с которыми вообще не понятно что делать.
Это нормально? Или это я один такой дебил что ни хрена не понимаю идею разработчиков?

[ecoins]

Блин! Бесит! Эти разработчики сначала пытаются создать удобный девайс для рядового пользователя. Потом извращают правила С++, а теперь наворачивают еще и системные переменные с которыми вообще не понятно что делать.
Это нормально? Или это я один такой дебил что ни хрена не понимаю идею разработчиков?

Присоединяюсь. Начав, разработчики могли бы добавить немного С++ в редактор. В дисплеях стоит STM32 c достаточной памятью.
Но у всех ведь свои представления и проблемы и не очевидно что проект "Nextion" достаточно рентабельный, чтобы развивать сделанное. И конкуренты поджимают.
Например, у Rovki к в KaScade все гораздо лучше - из достоинств Nextion проще встраивать по сравнению со смартфоном и планшетом (они уже дешевле Nextion) в оборудовании. Если бы у Rovki появились технические решения. Например разобрать планшет, из него сделать стандартное устройство, которое можно было поставлять по требованию. Мы бы в таком проекте поучаствовали и финансово, и можно было бы отбросить Nextion в сторону.

На сколько я понял, все что прописано во вкладке program.s* выполняется только один раз при старте дисплея и может быть использована только для резервирования (декларирования) этих глобальных переменных.
Дальше что?
Что делать пользователю-обывателю с этими переменными?

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

[grin-mpx]

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

А как они обрабатываются в коде таймера дисплея? Просто по имени?
До этого тоже можно было работать с любой глобальной переменной в любом месте, но с указанием ее местоположения.
if(sinhro.stroka.txt!="")
{
substr sinhro.stroka.txt,va1.txt,va4.val,1
va2.txt=va2.txt+va1.txt
}

[Dryundel]

А как они обрабатываются в коде таймера дисплея? Просто по имени?

Вот и меня вопрос интересует.

Отправлено спустя 34 минуты 59 секунд:
Судя по мануалу именно так - просто по имени.

[ecoins]

А как они обрабатываются в коде таймера дисплея? Просто по имени?
До этого тоже можно было работать с любой глобальной переменной в любом месте, но с указанием ее местоположения.
if(sinhro.stroka.txt!="")
{
substr sinhro.stroka.txt,va1.txt,va4.val,1
va2.txt=va2.txt+va1.txt
}

Вот и меня вопрос интересует.

Работа таймера.JPG

Вроде из картинки будет понятно.
Если не вполне, поясню подробнее.
Сложного вроде ничего нет, стоит попробовать новую версию Nextion Editor(1.61.2) и многое интуитивно становится понято.

[grin-mpx]

Сложного вроде ничего нет, стоит попробовать новую версию Nextion Editor(1.61.2) и многое интуитивно становится понято.

Понятно, но не всё. Как записать в "бездомную" переменную какое либо значение, именно штатными средствами FLprog?
Похоже никак, через запись системной переменной? Так там только sys. Или делать ПБ или через какую-то страницу таймерами загонять через промежуточные переменные. А стоит ли?
Пока не вижу плюсов с этими переменными без роду и племени:) разве что меньше текста печать в обработке таймера или события. Во всяком случае в связке с FLp теперешней сборки.

Отправлено спустя 9 минут 20 секунд:
Вот если бы они сделали глобальный таймер, чтоб на каждой странице этот таймер и его код не дублировать, было бы просто замечательно.

[Dryundel]

Как записать в "бездомную" переменную какое либо значение, именно штатными средствами FLprog?

Проверил. Все очень просто.
Декларируем переменную в Nextion ну типа myVal=0
Посылаем в UART строку "myVal=8" следом пишем туда же три чара - Serial.write(0xff); и все. Значение в дисплее присваивается.

Отправлено спустя 6 минут 5 секунд:
Короче вот так:

Код: Выделить всё

	Serial.print("myVal=");
	Serial.print(8);
	for (int i = 0; i < 3; i++) 
	{
		Serial.write(0xff);
	}

[ecoins]

Просто сообщаю - работы по дисплею возобновились. Результаты хорошие.
Получается достаточно просто.
Хорошо работает отправка данных в формате in10=134, где in10 зарезервированная переменная в дисплее, не привязанная к конкретной странице.
Через такую транзакцию на стенде на дисплее 8 светодиодов весело "бегают".
Многое тестируется, пробуются варианты (ну и другие задачи отвлекают) - потому не очень быстро.
Но теперь с еще большей убедительностью повторю: "По функционалу и удобству все это будет значительно уступать KaScada".
Пока относительно KaScada мы видим только одно преимущество. Это более удобный конструктив относительно планшета и смартфона - питание, доступ к контактам RX,TX, встраивание в готовые устройства.
Может Rovki со временем предложит какую-нибудь упрощенную техническую реализацию?
Не представляю как, но вдруг? Было бы отличным прорывным решением.

[Sancho]

[ref]ecoins[/ref], Энвер. Хотел Вам напомнить об одном немаловажном моменте в использовании панели не только как показометр, но и как управление процессом.
Вы всегда исходите из ситуации возможного отключения устройства, потери связи, и восстановления. Говорю это потому, что горячее отк/подкл занимало в Ваших наработках немалое место.
При отключении панели это нужно обязательно учесть, особенно, если панель переносная, возможно, подключается через 485, и т.д.
Не предприняв мер предзагрузки в неё, Вы рискуете внести нулевые значения, исходные.
Какое-то время назад, пару лет, с Сергеем, SSSergeich, мы эту тему проходили, была неплохая идея, проверенная.
Возможно, он её выложит.
Надеюсь, замечание будет полезно.

[ecoins]

ecoins, Энвер. Хотел Вам напомнить об одном немаловажном моменте в использовании панели не только как показометр, но и как управление процессом.
Вы всегда исходите из ситуации возможного отключения устройства, потери связи, и восстановления. Говорю это потому, что горячее отк/подкл занимало в Ваших наработках немалое место.

Наверное понимаю о чем Вы пишите.
Если говорить конкретно о дисплеях Nextion, то в силу его слабого функционала по программированию, это только показометр и нажиматель кнопок.
При обрыве и восстановление связи мы предусматриваем обновление данных.
К слову сказать обмен с Nextion через UART не "тормозит" процессор - Вы ранее указали на то, что это не дефект Arduino(мы так думали из-за обмена ModBus FLProg) - и полностью оказались правы.
Вопрос кто в распределенной системе может (или должен) восстанавливать данные многосторонний - проще когда один центральный контроллер, но это не всеза оптимально.
По KaScada - совсем иное дело. Такое устройство может сохранять и восстанавливать параметры и еще выступать как активный коммутатор между несколькими контроллерами.
------
Спасибо.