Как стать автором
Обновить

Выбор графического движка (GUI) для встраиваемой электроники

Время на прочтение 15 мин
Количество просмотров 25K
Всего голосов 46: ↑46 и ↓0 +46
Комментарии 39

Комментарии 39

Как так вышло, что вы пропустили https://github.com/lvgl/lvgl ?

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

А Azure RTOS емнип, лицензия не открытая (в том числе и у компонентов). Только для одобренных майкрософтом линеек чипов - поправьте, если я неправ.

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

Есть графический редактор для LVGL: squareline.io
Однако в бесплатной версии его функциональность несколько ограничена: squareline.io
Плюс сам он еще в процессе разработки.

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

Еще у NXP есть gui guider. Но тоже бедненько весьма.

УПД. Т.к. не могу чаще раза в час, потому здесь.

Между тем в lvgl также как и в GUIX нет концепции частичного фреймбуфера.

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

Тоже зашёл написать про lvgl. У него ещё требования к ресурсам гораздо ниже, можно запустить и на stm32f103.

А точно нужен редактор для интерфейса зарядного устройства? У вас в итоговом видео 6 полей с метками, это вполне можно сделать и кодом, без редактора.

И да, ещё хотел спросить: а зачем зарядному устройству Stm32h7?

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

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

По поводу ресурсов, то основные ресурсы съедают сами элементы дизайна, картинки шрифты, анимация. Сколько Flash памяти и RAM занимает сам движок GUI имеет меньшее значение. Да и не могут движки GUI сильно отличаться по ресурсам памяти. Если какому-то движку надо меньше ресурсов, это только значит что у него меньше виджетов и фичей. Но лишние фичи не прикомпилятся если их не использовать и не займут ресурсы. У GUIX так.

Между тем в lvgl также как и в GUIX нет концепции частичного фреймбуфера.
Т.е. коммерческий emWin уделает обоих по компактности. Его ранние версии я на атмеге запускал с рендеренгом ttf шрифтов в реалтайме без предварительной растеризации. Но на то он и коммерческий дорогой продукт.

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

а рисование в отдельном редакторе, без привязки к движку не рассматривали? например, относительно недавно делали устройство с круглым дисплеем. Дизайнер создавал интерфейс в фотошопе, потом переносили на устройство в виде фиксированной картинки, чтобы понять как оно смотрится в живую. Что-то по мелочи я исправлял в обычном paint.net, полученную картинку утверждали и потом уже переносили в код (разбивка на примитивы, получение таблицы координат объектов).

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

кстати, ещё один вариант Qt. Они ведь тоже рекламируют свой продукт под контроллеры, да ещё и демки красивые показывают.

Дизайнер создавал интерфейс в фотошопе

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

Более того, ни в каких дизайнерах под embedded в реальности дизайн не создают. Там нет таких инструментов. Все эти тени, переливы, блуры, 3D эффекты создаются как раз в фотошопах. И все демки под тот же GUIX изначально рисовались без сомнения в некоем фотошопе. Потом разбивались на битмапы, а потом битмапы импортировались в редактор GUIX.

Но я как раз хотел избежать такой технологии. Она в данном случае не требуется. Цель была как можно проще портировать, писать как можно меньше кода для вывода GUI, и как можно меньше времени тратить на создание экранов.

Нужен быстрый и эффективный рефакторинг экранов.Сегодня одна информация, а завтра может быть другая

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

Более того, ни в каких дизайнерах под embedded в реальности дизайн не создают.

embedded linux для микрокомпьютеров с Qt смотрят на вас с недоумением. Но для микроконтроллеров возможно вы правы.

Там нет таких инструментов. Все эти тени, переливы, блуры, 3D эффекты создаются как раз в фотошопах.

Опять же, зависит от целей и задач.

Но я как раз хотел избежать такой технологии. Она в данном случае не требуется. Цель была как можно проще портировать, писать как можно меньше кода для вывода GUI, и как можно меньше времени тратить на создание экранов.

это понятно, это логично.

Присоединяюсь к вопросу про Qt - с недавнего времени они позиционируют себя как пригодную и для embedded-систем GUI`евину. Технически к этому подвели несколько дизайн-решений, например alien-виджеты, QtQuick, уровень абстракции от платформы. Правда сами либы весят порядка 10мб, как я понимаю это сверх лимита многих микроконтроллеров.

Может это не очевидно, но в моих проектах всегда присутствует специфика рабочего процесса. На мой взгляд типичного для малых систем.
Этому рабочему процессу характерен ряд особенностей.

Первая особенность в том, что мало интересует "абстракция от платформы"
Смена платформы настолько трудоёмка, что всеми силами стараются её избежать. GUI может быть и абстрагирована, но драйвера то все равно надо писать самому. Для малых встраиваемых систем никто драйвера бесплатно не даёт. Так какой смысл в этой абстракции?

Потом, никак не привлекает из-за GUI изучать некие дополнительные языки типа QML. Эмбедеру и так надо знать C, C++, Python, HTML, JScript, CSS, Matlab, SPICE, VBA и т.д. А большое количество модулей Qt без указания совместимости с малыми платформами или голыми платформами только затрудняет процесс портирования.

Ни и наконец малые встраиваемый системы разрабатывают в очень проприетарных, но очень эффективных средах типа IAR Embedded Workbench, которые абсолютно несовместимы с воркспейсами Qt.

Кстати GUIX Studio, с скрупулёзно показывает сколько места в памяти займёт каждый шрифт и каждый битмап. Это для малых систем критически важно. Представьте если бы таким приходилось заниматься в Qt, в какой ад превратилась бы там работа.

Ни и наконец малые встраиваемый системы разрабатывают в очень проприетарных, но очень эффективных средах типа IAR Embedded Workbench, которые абсолютно несовместимы с воркспейсами Qt.

Сильно проприетарные среды нужны только при необходимости иметь сертификат безопасно кода для критически важных систем. Опять же основная стоимость того же IAR определена компилятором. Редактор кода там сильно на любителя.

Идеология Qt позволяет подцепить любой внешний компилятор, так что вопрос совместимости воркспейсов заменяется вопросом подключения компилятора.

Первая особенность в том, что мало интересует "абстракция от платформы"Смена платформы настолько трудоёмка, что всеми силами стараются её избежать. GUI может быть и абстрагирована, но драйвера то все равно надо писать самому.

Драйвера внешнего уровня (светодиоды, АЦП, МЭМС и т.д) вполне себе переносятся нормально. А вот нижний уровень (шины интерфейсов) да, слишком уж специфичная вещь. С графикой тоже самое.

Для малых встраиваемых систем никто драйвера бесплатно не даёт. 

Гитхаб стал платным ?!

Хотя некоторые специфичные вещи таки да, бесплатно не найти (из примера драйвер для NOR QSPI памяти для nrf52 с поддержкой выравнивания износа и сборкой мусора бесплатно не нашелся).

Сильно проприетарные среды нужны только при необходимости иметь сертификат безопасно кода для критически важных систем

Забавно, но IAR именно такую фичу не рекламирует.
Я бы назвал их киллер-фичой - Comprehensive debugger

Идеология Qt позволяет подцепить любой внешний компилятор

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

Драйвера внешнего уровня (светодиоды, АЦП, МЭМС и т.д) вполне себе переносятся нормально.

Тут широкое поле для терминологического спора. Я драйверами называю программные модули с API совместимым с верхним уровнем. На голых платформах нет верхнего уровня, соответственно там нет и драйверов. Там просто BSP. Но если вы работаете с развитой RTOS типа Azure, то BSP не спасёт. Нужны именно драйвера и под конкретный API. И на гитхабе их не найти. Вернее там выкладывают для затравки некие одиночные решения, но без всякой поддержки.

Забавно, но IAR именно такую фичу не рекламирует.Я бы назвал их киллер-фичой - Comprehensive debugger

раньше не встречал, хватало обычного терминала от Segger через RTT. Редко, Ozone использовал от тех же немцев. Работает там правда через пень-колоду, но кое-какие баги помогло отловить.

Сейчас для Zephyr использую плагин VisualGDB для Visual Studio. По описанию нечто похожее там реализовано. Видимо стандартом отладки становится наличие "полного" отладчика.

Тут широкое поле для терминологического спора.

Тогда не станем вступать в лишнюю дискуссию.

Но если вы работаете с развитой RTOS типа Azure, то BSP не спасёт. Нужны именно драйвера и под конкретный API. И на гитхабе их не найти.

Этот момент понял, как раз сейчас zephyr вынужден использовать и старые решения туда переносятся плохо. Приходится весь путь заново проходить.

Сравнивал как-то Zephyr с Azure RTOS.

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

BLE в зефире более менее сносный, но косяк с не освобождением ACL буферов божественный. Исправить не могут его с полгода где-то.

В свое время я удержался от желания взять эту ось ради беспроводных стеков. И оказался прав. Тот же Cypress дает для своих чипов и Wi-Fi и BLE хостовые стеки в сорсах и под ту же Azure RTOS.

к сожалению для nrf5340 или зефир или апач. для первого хотя бы есть поддержка от вендора, что немного проще в работе. плюс опять же удобно наличие плагина для VS. так что плачем, но половину кактуса уже прожевали))

Насчет 10 мегабайт вы малость погорячились. В виде демо на NXP контроллере цифорки поскромнее были.

ROM 1529 kB, RAM 1872 kB.

Тоже не мало, но и демка там с анимациями, плавными переходами и т.д.

Думаю что можно и меньший объем получить.

Я судил по десктопу если честно, ибо опыта под встроенные системы нет. На Windows еще с 2010 года примерно сборка Qt в виде основных DLL (QtGUI, QtCore, etc.) занимала в сумме 10мб. Очень круто, что они смогли ужаться в пару, я впечатлен! Ссылочку на демо сюда или в личку не трудно будет дать?

Между тем в lvgl также как и в GUIX нет концепции частичного фреймбуфера.

Почему нет? Как раз-таки позволяет, иначе как бы цветной дисплей 800х480 влез в память обычной F4 стмки с 512К оперативкой? Двойного буфера хотя бы на 15 линий вполне достаточно для плавной работы дисплея, если, конечно, не крутить на нем видео. Прелесть lvgl в том, что она отрисовывает только изменяющиеся объекты. Сколько бы заняла отправка целого 800х480 фрейма при малейшем апдейте?

Про редактор для lvgl узнал только сейчас, что не помешало отрисовать несколько 800х480 экранов просто кодом по дизайну в фотошопе. Хотя соглашусь, что с редактором это могло быть быстрее

Ничего не мешает разместить буфер 800x480=384000 и палитру в 512000 байт оперативке.

Оправить по SPI весь такой буфер тоже займет не более 70 мс с 50 МГц шиной, которая обычно есть у SPI дисплеев.

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

Ну и наконец я не утверждал что писать программно невозможно или мучительно трудно. Сам так делаю иногда.

RGB565 это уже 2 байта на пиксел и 140 мс, что непозволительно долго.

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

Весьма интересно, но похоже на рассказ из другого — параллельного, профессионального — мира.


Пропасть между этой статьёй и нами, простыми ребятами с Platformio, Arduino IDE, Wiring / MicroPython и чипами ATMega, ESP32, RP2040.


Как так получилось и есть ли там мостики, вот с теми же GUI библиотеками, например?


То есть, я много раз слышал, что Wiring — неэффективная дрянь, ATMega — дилетантство, ESP чипы никто в здравом уме не потащит на продакшен и т.п., но интересно всё же поиспользовать что-то из этого кода. Пока что приходится использовать экранчики Nextion, а у них дизайнер UI только под Шindows и это очень неудобно

не хочу обидеть, просто рассказываю про устройство этого мира.
Атмега — отличный и прогрессивный чип (по сравнению с 8051) только он сдох в коммерческом плане в 2005 году после того как фирма Филипс (впоследствии NXP) первыми обрушили цены на ARM микроконтроллеры.
Приведенные в статьи примеры с графикой также являются устаревшей экзотикой, потому что дешевле, интереснее делать большим мальчикам на Cortex-A и linux.
Ардуино интересна в коммерческом плане только для продажи «простым ребятам» оверпрайснутых шылдов. Очень узкий сегмент. То есть пользуйтесь наздоровье, только не пытайтесь сэкономить или как-то конкурировать с профессиональными вещами.

Однако действительность нам говорит совершенно об обратном.
Не будем брать в расчёт игры перезрелых мальчиков с Cortex-A в качестве газоно-поливалок, а посмотрим на океан потребительской электроники.
Если я раньше в своём пылесосе, микроволновке, духовке встречал одни атмеги и пики, то нынче я уже вижу в роботах пылесосах, духовках, стиралках, самокатах, велосипедах, коптерах ... повально STM32 и прочие 32-х битные микроконтроллеры.
MMU-less микроконтроллеры множаться и развиваются. А с ними и всякие GUI. Этот рынок только растёт и конца росту не видно.

Wiring, ATMega, ESP  - это не архаика, а просто другая индустрия. Индустрия образования и самообразования. Не менее мощная, кстати, индустрия чем потребительская электроника. Сложные трудоёмкие процессы освоения и разработки GUI в образовании не востребованы, вот их там и нет. А так, тот же emWin появился поначалу именно для атмег и пиков, спокойно работает на 8-разрядниках.

лет 5 назад мне на работе поставили ip-телефон и я понял что не хочу уже втыкать в убогую монохромную графику. ipod, iphone и клоны его победили. С точки зрения бизнес-потребителей «интерфейс не требует обучения» это киллер фича. Это перебить никак нельзя.
Atmel быстро сжег себе карму еще и тем что резко задрал цены в нулевых годах и увеличил лидтайм. ST — похоже идут по тому же пути.
В абсолютных цифрах в мире на рынке микроконтроллеров рулят вообще японцы (Renesas) и немцы (Infineon) с 8051 и прочей никому не нужной экзотикой. Просто в каждом автомобиле их больше пяти десятков.
Следующая проблема микроконтроллеров — экзотическая память, когда А-процессоры могут работать с мейнстримовой NAND/DRAM.
Пользователи привыкают быстро к BLuetooth|WiFi/5G что также выбивает микроконтроллеры из конкурентной ниши.

Вобщем, думаю, ниши с графикой на микроконтроллерах еще остаются, но все они будут выбиты с рынка устройствами с тачовым андроидоподобным интерфейсом.

Все мной описанные GUI имеют поддержку жестов на тач-экранах. Жесты обрабатывает не хост процессор, а процессор ёмкостного тач-контроллера в экране, MMU-less кстати.

Модули BLuetooth|WiFi/5G имеют внутри все тот же ARM-Cortex M.
По сути хост контроллеру линукс уже не нужен. За него всю работу делает распределённая периферия.
Возьмём часы наручные, там обалденные интерфейс делают без всяких линуксов.
Линукс просто теряется в этом море, о нем потихоньку забывают.
Мейнстримовые в embedded не NAND/DRAM, а HyperRAM и HyperFlash.
Они идеально сочетаются с STM32H или c i.MX RT
 
В автомобилях количество микроконтроллеров идёт не на десятки, а на сотни, и подавляющая часть там MMU-less.
Гибкие экраны и печатаемая на поверхностях электроника только увеличит спрос на малые GUI.

Но ESP-то живы и здоровы. Как производители захотели Wi-Fi в каждом чайнике, стали ставить ESP везде. А кто сообразил, что можно всю прошивку целиком в него засунуть, не только wireless modem.


Есть куча устройств вокруг с Nordic NRF, если там Bluetooth, и ESP, если там WiFi.


Кажется, умение собирать из них что-то и запрограммировать стало полезнее, чем раньше. И вот тут хочется экран с GUI, и желательно не Nextion...

вот как раз только для "Wi-Fi чайников" ESP и применяют. в серьезные проекты мы их ставить пока не решаемся. как собственно и аппетитно выглядящий в нынешних реалиях RP2040. просто слишком мало опыта эксплуатации данных чипов в реальной жизни.

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

Спасибо за статью! Думаю сделать свой медиаплеер - с шахматами и поэтессами... в халатах с перламутровыми пуговицами, как раз возник вопрос о программировании экрана.

Почитал и как то расхотелось использовать GUI. Простенький интерфейс проще написать самому. В своё время купил дорогущую отладочную плату на двухъядерном микроконтроллере с интегрированной TFT панелью для освоения TouchGFX, но примеры меня не впечатлили. В результате так и забил на это, судя по тому сколько сил вы потратили - правильно сделал.

Спасибо за статью! Эх, а я уже целое предисловие в книжке Макса Шлее смог осилить. Хотя там всё же "полноценная" операционка должна на железе крутится. Для чистых МК будет очень полезно, ещё раз спасибо 👍👍👍

Я спрошу про реалтаймовость Azure RTOS - хочу ее засунуть в промышленный контроллер, а в последнем хотелось бы получить быстрый отклик на уровне единиц миллисекунд для работы с портами ввода/вывода и все это на фоне работы парсера и обработчика скрипт языка, GUI, и т.д.?

Тут недавно проект был у меня с реализацией хоста USB. У периферии в STM32H не было DMA, пришлось делать по прерываниям. Прерывания шли каждые 8 мкс и использовали передачу событий в RTOS. Так я сразу даже не заметил что идёт такая нагрузка. GUI, прикладная программа, обработка и фильтрация сигналов шли как обычно.
Т.е. я даже не пытаюсь замерить какое быстродействие у сервисов RTOS, настолько их влияние незначительно.

Гораздо важнее следить за приоритетами и частотой хардварных прерываний.

НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории