Доброго дня! Вопрос больше теоретический, наверное. В плане хобби собираю много разнообразных девайсов. С недавних пор перешёл с AVR на STM32. Традиционно возникает вопрос, как организовывать взаимодействие с пользователем. Традиционно делал это с помощью LCD (скажем 16x04) и энкодера. Удавалось сделать какое ни какое меню. Ну и собственно возник вопрос более продвинутого способа взаимодействия с пользователем, благо TFT дисплеев с touch screen сейчас масса. Вот только вопрос как интерфейс на этом дисплее организовывать? Не рисовать же все кнопочки и менюшки самостоятельно. STM и google подсказали что можно использовать touchGFX. Купил отладочную плату stm32f469i-disco попробовал красиво и нарядно, но….
1. Работает только с достаточно продвинутыми чипами, которые в основном BGA и в домашних условиях плату на такие не сделаешь 2. Софт touchGFX designer только под винду…. А мне уж очень не хотелось ещё и её в хозяйстве заводить.
В связи с этим вопрос, а кто как делает пользовательский интерфейс на TFT дисплеях? В какую сторону копать?
Нет, как раз-таки единственный правильный путь — рисовать все самостоятельно. Потому что даже такие совсем вроде оптимизированные библиотеки, как nuklear, все равно сожрут прилично флеша. А свой родной код, который заточен строго под одну задачу, вряд ли больше пяти килобайт съест. P.S. Я уже больше 10 лет под МК что-то разрабатываю. Единственный раз, когда нужен был "интерфейс" — когда я сваял простую железяку для измерения температуры, прислюнил экранчик по SPI и выводил себе буковки. Еще делал отображение данных старт/финиш на светодиодной панели. Но чтобы рисовать "окошки" и "менюшки"… Ну, не знаю, зачем это. Можно же всегда по терминалу подключиться (хоть блютус сделать) и все нужные параметры настроить.
_________________ Linux rules! Windows must die. Здравомыслящий человек добровольно будет пользоваться мастдаем лишь в двух случаях: под дулом автомата или под влиянием анального зонда. Я на гитхабе, в ЖЖ
Ну спорный вопрос.... Последнее поделка - блок управляющий ванной для травления печатных плат. Управляет подогревом и компрессором для подачи воздуха. Соответственно через интерфейс можно управлять температурой, которая поддерживается и интенсивностью подачи воздуха. Управляется все с помощью одного энкодера.
Наверное такой интерфейс можно самому нарисовать, но только времени на это уйдёт уйма. Поэтому я за какие ни будь библиотеки. Вот только какие?
Для блока управления ванной достаточно четырехразрядного семисегментного индикатора. Зачем там TFT?
_________________ Linux rules! Windows must die. Здравомыслящий человек добровольно будет пользоваться мастдаем лишь в двух случаях: под дулом автомата или под влиянием анального зонда. Я на гитхабе, в ЖЖ
Качественное и безопасное устройство, работающее от аккумулятора, должно учитывать его физические и химические свойства, профили заряда и разряда, их изменение во времени и под влиянием различных условий, таких как температура и ток нагрузки. Мы расскажем о литий-ионных аккумуляторных батареях EVE и нескольких решениях от различных китайских компаний, рекомендуемых для разработок приложений с использованием этих АКБ. Представленные в статье китайские аналоги помогут заменить продукцию западных брендов с оптимизацией цены без потери качества.
А зачем для такой задачи навороченный интерфейс? Судя по описанию там пары семисегментников хватит. Ну и переменные резисторы наверное вместо энкодера. Хотя если делать на продажу, где нужна не функциональность, а дешевизна и внешний вид. Там и блютус с управлением с телефона замутить можно, и подсветку ванночки снизу (никого не волнует что хлорное железо почти непрозрачное) мерзкими синими диодами. Или нет, ЛГБТ-подсветкой! Все как маркетологи любят.
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
А зачем для такой задачи навороченный интерфейс? Судя по описанию там пары семисегментников хватит. Ну и переменные резисторы наверное вместо энкодера.
Не в этом сейчас вопрос. В моем понимание сейчас реализован минимально убогий интерфейс. 1 строка: Средняя текущая температура раствора. Выбрав строку энкодером можно посмотреть температуру с каждого датчика 2 строка: Целевая температура (к которой стремимся), опять же выбрав строку экодером ее можно поменять 3 строка: Текущая мощность компрессора. Опять же экодером ее можно поменять 4 строка: Пункт меню стар/стоп и время работы если устройство запущено.
Итого один дисплей и один эккодер. В случае с TFT touch screen можно было бы просто обойтись дисплеем.
Дисплей к сожалению плохо видно, но если будет интересно, то вечером сфоткаю нормально.
И повторюсь вопрос не в том нужен или нет TFT дисплей. Тут я для себя уже все решил. Нужен. Нет смысла отрицать прогресс.
Вопрос в том как с минимальными усилиями делать интерфейсы. Что бы можно было сосредоточиться на прикладной части устройства, а не на борьбе с низкоуровневым рисованием на дисплее.
Вот только вопрос как интерфейс на этом дисплее организовывать? Не рисовать же все кнопочки и менюшки самостоятельно.
Да как угодно - как удобнее. Хоть в VisualStudio. Рисуете в VS диалог со всеми кнопочками и пр. требухой. А потом забираете от него .rc-файл (описывающий нарисованное) к себе в проект. И в программе рисуете по этому файлу.
1. Работает только с достаточно продвинутыми чипами, которые в основном BGA и в домашних условиях плату на такие не сделаешь
"Смешались в кучу люди кони..." Никакой связи рисования GUI-интерфейса и мощности чипа нет. А тем более с типом корпуса. Да хоть на самом дохлом МК можно рисовать. 1. Разработчик рисует интерфейс на ПК, сохраняя результат (.rc-файл с координатами контролов). 2. А уже программа на МК рисует этот интерфейс по данным из этого .rc-файла с помощью своего графического API либо в видеопамять напрямую либо в ОЗУ МК с последующей отсылкой массива пикселей в видеопамять (либо ещё как). Графическое API в МК должно уметь отрисовывать графические примитивы: прямые, прямоугольники (закрашенные и незакрашенные), эллипсы, иногда - треугольники, шрифты разного размера и стиля. Обычно этого набора достаточно. Из этих примитивов уже строится любой контрол GUI.
Ваш вопрос непонятно о чём? О 1-м или о 2-м? Если 1-е - любой инструмент типа VS и т.п. Если 2-е - лучше написать свою реализацию графической библиотеки и с помощью её рисовать контролы GUI. Хотя и готовых их полно, но тут уже возможно будет привязка к чипу и к конкретной структуре видеосистемы.
Последний раз редактировалось jcxz Пт апр 02, 2021 13:13:37, всего редактировалось 1 раз.
Вот сам написал однажды объект "кнопка" на подобие виндовой и не заморачиваюсь с низкоуровневым рисованием на дисплее .
Так не ужели нет более менее внятных библиотек? Ведь это же не просто кнопку нарисовать. А реакция на нажатие? И нажатие анимировать наверное можно.... Не самому же все это писать???
Неужто элементарное рисование прямоугольников и горизонтальных/вертикальных прямых вызывает такие затруднения??? Посмотрите под лупой на любую виндовую кнопку - там кроме указанных графических примитивов ничего больше не нужно чтобы её нарисовать. В любом положении.
Неужто элементарное рисование прямоугольников и горизонтальных/вертикальных прямых вызывает такие затруднения???
Ну не скажите.... Почему бы не воспользоваться тем, что люди уже один раз сделали хорошо? Например что ни будь подобное
Это точно не один вечер делать...
В общем возвращаюсь к вопросу про библиотеки... Кто ни будь что ни будь использует? Или может покажете свои интерфейсы написаyные руками? Может я и правда масштаб бедствия преувеличиваю?
Конечно. Для этого не нужен целый вечер - гораздо меньше. ...при наличии всех необходимых примитивов. На этой картинке имеются только те примитивы, которые я выше перечислил (кроме фоновой картинки). А полупрозрачные наложения - это всё есть в DMA2D тех же STM32: рисуются 2 картинки в двух разных буферах, а потом с помощью DMA2D комбинируются.
Конечно. Для этого не нужен целый вечер - гораздо меньше. ...при наличии всех необходимых примитивов. На этой картинке имеются только те примитивы, которые я выше перечислил (кроме фоновой картинки). А полупрозрачные наложения - это всё есть в DMA2D тех же STM32: рисуются 2 картинки в двух разных буферах, а потом с помощью DMA2D комбинируются.
Вот.... Уже ближе к конструктиву.... Наверняка есть библиотеки с этими примитивами. Кто ни будь чем ни будь пользуется? Я пока попробовал только touchGFX все хорошо, но ему как раз нужен пресловутый DMA2D, а он есть только в более менее серьезных чипах.
их примитивов уже строится любой контрол GUI. Если 2-е - лучше написать свою реализацию графической библиотеки и с помощью её рисовать контролы GUI. Хотя и готовых их полно, но тут уже возможно будет привязка к чипу и к конкретной структуре видеосистемы.
Ну я точно не сторонник писать что то свое там, где есть что то готовое. Если их полно, то можно годные примеры?
В случае с TFT touch screen можно было бы просто обойтись дисплеем.
Не забывайте, что в удобстве физические элементы управления всегда выигрывают у виртуальных. Рисовать кнопки и все остальное имеет смысл только для совсем развесистого функционала, либо удовлетворения маркетологов - дешево, красиво, неудобно.
Цитата:
Нет смысла отрицать прогресс.
Не имеет смысла жертвовать эргономикой ради моды. Даже не прогресса.
Цитата:
Вопрос в том как с минимальными усилиями делать интерфейсы.
Тот же Nuklear попробуйте. Насколько я понимаю, он для этого и предназначен.
Цитата:
всё есть в DMA2D тех же STM32: рисуются 2 картинки в двух разных буферах
Угу. Учитывая, что в контроллере физически не хватит памяти даже на пол-картинки.
А можно подробнее что с этим делать? Как, так сказать, технологический процесс устроен?
Откройте VS, создайте проект GUI-приложения, добавьте в него диалог, на диалог поместите различные контролы (кнопки, едит-боксы и т.п.), сохраните проект. Далее - в любом текстовом редакторе откройте .rc-файл этого проекта. Увидите что-то типа:
Это (между BEGIN и END) вставляете в свой проект и в программе с помощью граф.библиотеки граф.примитивами рисуете по этим координатам указанные контролы.
Кроме редактора VS можно пользоваться и другими. Они делают что-то подобное.
Это (между BEGIN и END) вставляете в свой проект и в программе с помощью граф.библиотеки граф.примитивами рисуете по этим координатам указанные контролы.
Угу. Учитывая, что в контроллере физически не хватит памяти даже на пол-картинки.
Странно.... а у меня почему-то хватает... и хватило всего каких-то 4096 байт (при необходимости - нетрудно ещё кратно ужать). Открою вам страшную тайну: картинку можно обрабатывать частями. Необязательно целиком в память затаскивать. Кроме того - не обязательно на каждый пиксел тратить 32 бита. Можно экономнее. Для GUI (без полупрозрачностей!) достаточно 4 бит на пиксел - и на весь видеобуфер вполне хватит внутренней памяти многих нежирных МК.
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 21
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения