GUI для встраиваемых систем

Предыстория

Техника не стоит на месте, пользователей не впечатляют 7-сегменные и текстовые индикаторы, в двух проектах понадобились простенькие экраны цветные 320х240. Время было ограничено, основная плата сделана, отлажена, а для пользовательского интерфейса в первый десяток устройств пошли китайские demoboard ebay. В качестве GUI — либа от STM.
Изделие удачно прошло промышленное тестирование, но вот пользовательский интерфейс вызывал некоторые нарекания, ибо топорен и жрал ресурсы. Кроме того — избыточность демоплаты, непредсказуемость качества самой платы, экранов, времени жизни, проблемы с белой закупкой, гарантией и т.д. Т.е. то что годится для дома, никак в промустановке. Соответственно, была разработана плата с экраном, под проект.
На самом деле проекта два, несколько отличающихся по обвязке, на фото платы от обоих. Не все элементы распаяны, так как проекты гибко конфигурируемые, к тому же, первая плата — вообще отладочный макет для GUI, вторая — тоже пока отладка, но другие узлы.
Плата 1. Обратная сторона
Рисунок 1 — Плата 1. Обратная сторона.

Плата 2. Обратная сторона
Рисунок 2 — Плата 2. Обратная сторона.
Передняя сторона с экраном будет ниже, чтоб не дублировать фото.

GUI

Если с железом все понятно, то с интерфейсом возникли проблемы — есть кучка драйверов, с низкоуровневым выводом все понятно, а вот сам пользовательский интерфейс — тут есть проблемы. Точнее:
ucGUI — отличные интерфейс, но если кто видел цену — улыбнулись :) На просторах инета есть исходники, но есть случаи, когда лицензионная чистота имеет значение.
emWin — тоже хорошо, но без исходников — не наш метод.
ST GUI — ну на попробовать пойдет, а вообще — индусы писали.
NanoX — показалась тяжелой и трудной для понимания.
После изучения этих либ, появилось понимание, что GUI — не так уж и сложно. Поэтому потратив недели 3 вечернего времени, была сделана своя библиотека GUI. Понимание приходило во время написания, поэтому структура переписывалась раза 4, последний раз благодаря обсуждению на сахаре. Хотя, возможно не последний.
Библиотека задумывалась как универсальная, поэтому от С++ отказался, написано на чистом Си.
Итак, что получилось следующее:
Вывод элементов на экран
Рисунок 3 — Элементы.

Фичи

Библиотека позволяет выводить стандартные элементы пользовательского интерфейса, типа
1. Текстовая метка
2. Чек-бокс
3. Кнопка с текстом (кликабельная).
4. График
5. Текст (обычный и прозрачный) с пропорциональными шрифтами
6. Примитивы, типа окружность, круг, линия, полилиния и т.д.

Структура проекта в целом следующая —
mkDriver.c — самый нижний уровень, типа определения ножек ввода вывода, записи в память индикатора и т.п.
lcdHAL.c — второй уровень касающийся самого индикатора — инициализация, вывод примитивов линия, putPixel, DrawChar — в общем минимум, зависимый от индикатора и поддающийся оптимизации, так как выводить в потоке гораздо быстрее чем через putPixel — раз в 5.
guiPrimitives.c — относительно сложные примитивы, использующие функции из lcdHAL, т.е. уже аппаратно независимые, и/или неоптимизируемые.
Все остальное реализовано через виджеты. есть низкоуровневые структуры, типа wmObj, wmText, которые, как правило, идентичны для всех виджетов, индивидуальные свойства пишутся в структуру виджета. Основные функции для всех виджетов — функции инициализации и отрисовки и функция выравнивания положения текста — там где есть текст.

Все основные элементы приведены на рисунке 3, текстовые метки в черной рамке наверху и в зеленой внизу — на самом деле одно и то же, просто заданы разные свойства для ширины и цвета рамки, фона, текста.
Красные буквы поверх слова «МЕТКА» — проверка вывода прозрачного текста — т.е. фон под буквой не заливается цветом бэкфона текста.

На самом деле с текстом пришлось немало повозиться — после опробования моноширные шрифты не впечатлили, под пропорциональные пришлось изобретать велосипед. Возникли проблемы с конвертацией, в итоге, немножко допилил программу оттуда The Dot Factory. «Допил» выразился в добавлении символов codepage-1251 и сжатии структур lookup — для ascii таблицы. Пока не выкладываю, т.к. сделано коряво, на скорую руку.

Немного повозился с тачскрином, оказывается, если не делать подтяжку на TP_IRQ ads7843, то считываемые данные скачут в пределах поля видимости, и сложно отследить — реальное нажатие или глюк.

Проект обновляется, баги устраняются, иногда меняется структура. Можете пользоваться в коммерческих целях :)

В дальнейших планах:

— драйвер для SSDxxxx, ILI9320
— возможность автоматического определения контроллера дисплея и переопределение функций lcdHAL
— определиться с форматом bmp
— вывод bmp произвольного размера и формата (прямой и с палитрой)
— вывод однобитового bmp произвольного размера и формата (прямой и с палитрой)
— кнопка с иконкой
— иерархическое меню
— калибровку тач-скрина (в принципе есть, надо вытащить из другого проекта и придумать,
куда лучше сохранять, флэш или i2c eeprom, spi flash).
— для chart — масштабирование данных, подписи и т.д.
— градиентная заливка

Планы большие, реализовывать буду постепенно.
Проект на GitHub
  • +26
  • 13 января 2013, 13:25
  • AVF

Комментарии (120)

RSS свернуть / развернуть
О! Здорово! Сам занимаюсь таким дисплеем, с калибровкой разобрался, нашел как через STMую прогу гуй делать, но немного не доделал. Отличный блог!
0
Счас все дружно начнуть говорить чтобы cut поставил.
Молодца, хорошее дело затеял!
+1
Говорю: ТС, поставьте cut в угловых скобках. Надоело листать в рссридере пост.
0
Архивчик можно))??
0
ссылка внизу статьи. сам проект выложить не могу, тестирую на коммерческом проекте, может попозже. сам либа с гитхаба Your text to link...
0
Спасибо!
0
Отдельное спасибо за универсальность и за Си. Крайне актуальная либа. Плюсанул бы, да рейтинга не хватает.
0
а emWin?
0
  • avatar
  • x893
  • 13 января 2013, 15:42
см в тексте. Без исходников неинтересна во первых, во вторых цены на нее видели, не для LPC?
0
В Keil 4.6 он входит, я использую для STM32 — удобно — хоть и без и исходников. Конечно если время есть, то можно и своё писать.
0
не все используют кейл
0
Молодцом! Задач таких нет, но код погляжу, интересно как он устроен.
0
  • avatar
  • Ozze
  • 13 января 2013, 15:54
а нельзя ли написать еще пару статей о теории гуя
как это все делается и рисуется? с картинками для альтернативно мыслящих
0
ну чесное слово, некогда. даже этот проект нормально задокументировать не успеваю
0
Делается это кому как взбрендит. Обычно гуй — дерево объектов, при обработке произошедшее событие (клик, например) передается корневому объекту, тот разбирается к кому из его ветвей это событие относится и передает ему, либо обрабатывает сам, если ни к одной из ветвей событие не относится. Получивший событие объект-ветвь поступает с ним точно так же. В результате в итоге событие получает тот объект, по которому кликнули и обрабатывает его — кнопка, например, рисует нажатие себя и вызывает привязанную к ней функцию, которая должна выполниться при клике (обработчик клика).
Рисуется аналогично. Пинаем корень, тот рисует себя, затем пинает отрисовку каждой ветви, и так далее. Обычно перед отрисовкой ветви ставится обрезка по ее размерам, чтобы случайно не нарисовать за пределами контрола.
Это основы, а дальше кто во что горазд. Для скинов, например, приходится выносить отрисовку контролов из самих контролов в скин, либо брать данные для отрисовки (битмап, например) из скина. Еще веселухи добавляет анимация. Ну и само выделение событий тоже по разному реализуется.
0
Библиотека задумывалась как универсальная, поэтому от С++ отказался, написано на чистом Си.
Вот этого пассажа я не понял. Чем плюсы менее универсальны чем С?
0
  • avatar
  • evsi
  • 13 января 2013, 18:46
Ну поддержка С на МК пошире, чем С++. Даже CooCox по неясным причинам не поддерживает его, хотя и тулчейн, и IDE поддерживают.
0
Что ж тут неясного — типичные фобии, предрассудки и криворукость. Они до сих пор не допилили свою IDE под линух, хотя эклипс, на котором все это построено, линух поддерживает с незапамятных времен.
0
уже для всех мк есть плюсовый компилятор?
0
для тех, в которых имеет смысл гуй — да.
0
pic24 и прочая мелочь? кто сказал что эту либу надо обязательно использовать для TFT?
есть мнение, что GUI не под осью (линукс, wce, android etc) вообще не имеет смысла. причем, мнение аргументированное, и теоретичкски я с ним согласен, только вот реальность вносит свои коррективы. поэтому убеждать не собираюсь, надо — берите как есть, не надо — пишите свое или правьте, исходники для того и выложены. впрочем, даже линукс и вроде как гном написаны без плюсов, хотя им там самое место. и еще — сделать на с++ действительно красиво и эффективно с точки зрения иерархии и стркутуры проекта займет времени существенно больше. понятность кода пострадает, и в открытый доступ уже вряд ли выложу :) да и там уже есть Qt.
+1
и еще — сделать на с++ действительно красиво и эффективно
если на плюсах написать так же как на С (структуры и методы работы с ними) будет ровно то же по эффективности и более читабельно.
0
Будет офигенно читабельно. А если и шаблончики попользовать, то будет зйфория и щасте.
0
Будет офигенно читабельно.
Да, подобные вещи часто удивляют тех, у кого фобия на плюсы.
А если и шаблончики попользовать, то будет зйфория и щасте.
Вам стоит сходить в блог камрада neiver и убедиться, что шаблоны это не больно.
0
Это метапрограммирование на шаблонах не больно? Ну-ну)
0
Для пользователя — не больно.
0
Пока он не попытается это понять или, того хуже, подправить)
0
Если поймет, то тоже не будет больно. Ну а без понимания и в С можно делов наворотить (точнее, именно в голом С делов и можно наворотить).
0
Будет. Хотя бы потому, что метапрограммирование на шаблонах — удаление гланд через задницу. От того, что прямого пути нет, этот прямее не станет.
0
Не согласен. Шаблоны дают более качественный и многократно используемый код, чем наследование и использование #define-ов. Да, ошибки отлавливать сложнее, но это уже проблема разработчика.
Те, кто говорят, что С++ очень сложный и непонятный, обычно его знают хуже, чем С. Те же, кто хорошо владеет и С и С++ обычно предпочитают С++ там, где это возможно.
0
Это если шаблоны использовать по назначению — как средство обобщенного программирования. А если для метапрограммирования — то это круто, мощно, но write only плюс вывих мозга.
0
Будет офигенно читабельно.
Да, подобные вещи часто удивляют тех, у кого фобия на плюсы.
А если и шаблончики попользовать, то будет зйфория и щасте.
Вам стоит сходить в блог камрада neiver и убедиться, что шаблоны это не больно.
Это не сарказм, это утверждение. Т.е я стреляю в ту же сторону. Именно комраду neiver у, пользуясь случаем, выражаю как нынче принято — «респект и уважуху». И всем рекомендую его статьи по шаблонному метапрограммированию, для встроенных систем. А по поводу поддержки… В любой системе нетрудно разобраться, если присутствует СИСТЕМА, любой безграмотный код сложен для понимания, и неудобен в поддержке. Учите грамоту, уважайте окружающих!
0
Для всех он бесплатный? Для всех он доступный?
Про гуй тоже повнимательнее пожалуйста. Банальный граффик напряжения на дисплее от Nokia 3310 выведенный с какой-нибудь ATtiny13 уже является частью GUI, поскольку «графический пользовательский интерфейс».
0
И что, gcc для авр-ок (в том числе тиньки) стал платным или исчез?
0
STM8
0
А что, для них вообще есть бесплатные компиляторы? И IAR вроде ж поддерживает С++?
0
загрузка изображений поддерживается?
0
условно :)
т.е. низкоуровневая функция LCD_WriteBMP(uint32_t BmpAddress) есть и даже работает, но
1. пока еще не понял, какой заголовок лучше использовать, склоняюсь к BITMAPV4HEADER
причина в следующем, заложенный индикатор имеет 18 битный цвет, который в целях экономии урезан до 16-битного, но маска RGB плучается 664. если испльзовать полный цвет, то картинка будет занимать много места, конвертация на лету — время. в общем
если индикатор с цветом RGB 565 все работает, для цвета 664 нужен конвертор, RGB 666 или 888 не поддерживаются.
2. соответсвенно вывод изображения в произвольном месте произвольного размера — пока нет. Мне сейчас не нужен, но в первоочередных планах, задача тривиальная.
0
поэтому структура переписывалась раза 4, последний раз благодаря обсуждению на сахаре
а можно ссылку на обсуждение?
0
0
А ГДЕ ЖЕ «cut» ?!!!
0
да поставил уже, ну ни разу не писал блоги :)
0
Спасибо огромное! Потрясающе, как вовремя.
0
Спасибо за статью. Пытаюсь привести в порядок свои разрозненные знания по GUI. Я могу рисовать примитивы, выводить картинки, тексты. Думаю теперь смогу уже добавить и красивостей. А потом может и анимацию простенькую добавлю.
0
У китайцев все проще делается: вывод картинок на весь экран плюс прямоугольные зоны тача. Для серьезных проектов не юзабельно, зато время разработки существенно сокращается.
0
Я думаю не стоит ограничиваться поддержкой только BMP. Понятно, что это самый простой формат. Но поддержка PNG, JPG, GIF тоже должна быть в серьезной GUI.
0
Интересно, зачем? Я бы вообще поддерживал только свой специализированный формат графики.
0
Затем, что это ведет к универсальности. Как пример. Имеем некий интерфейс пользователя с разными там прогрессбарами, кнопками, иконками. Файлы изображений хранятся на карте памяти в качестве PNG файлов. Кто-то захотел поменять интерфейс. Ему достаточно заменить соответствующие файлы на карте памяти, код остается неизменным.
0
Всегда можно конвертировать PNG в свой формат и точно так же заменить. А тащить в МК полновесный PNG или JPEG без реальной надобности — не лучшая идея. Не для того они разрабатывались, так что и требования к системе у них немалые.
0
С этим не поспоришь… Но данный вариант опять же требует наличия конвертера PNG в свой формат. Его тоже нужно писать. При достаточно большом количестве файлов интерфейса процедура конвертирования становится весьма утомительной. Из личного опыта, так сказать, мнение… А свой формат опять таки нужно придумать таким образом, чтобы конечный файл занимал мало места на карте памяти.
0
Но данный вариант опять же требует наличия конвертера PNG в свой формат. Его тоже нужно писать.
Тоже мне проблема.
При достаточно большом количестве файлов интерфейса процедура конвертирования становится весьма утомительной.
for %i in (*.png) convert %i outdir\%~ni.myfmt

Вот и вся утомительность.
0
Хорошо. Предлагайте тогда уж и свой вариант формата.
0
А вот с этим уже пусть автор сам разбирается, исходя из потребностей. Проще всего, по видимому, разновидность RAW-битмапа с поддержкой требуемых моделей цвета (RGB664/RGB666, например) и возможно других требуемых фич, в том числе ненапряжного для МК сжатия.
0
Можно использовать старый добрый PCX, для изображений без плавых цветовых переходов — самое оно.
0
Отсутствие плавных цветовых переходов — это прошлый век.
0
поддержка по крайней мере jpg опционально планируется, для всяких иконок велосипед изобретать не стоит, есть *.ico. для того и создавался. для bmp поддержка RLE тоже наверное будет
0
Не вижу смысла прикручивать стандартные форматы, если не требуется показывать произвольные картинки в оных форматах (как в фоторамке, например), учитывая что для задачи они обычно подходят не очень (в том же BMP придется конвертировать цвет из RGB888 или RGB565 в требуемый). Ну и .ico — ЕМНИП практически тот же BMP, только позволяет положить в один файл несколько битмапов.
0
картинки выводить в принципе может понадобиться, а ничего проще вариаций bmp не придумали
0
Ну, BMP — разновидность битмапа с заголовком. Чуть усложненная наличием сжатия. Ну и еще одна мелкая подлянка — выравнивание данных, каждая строка начинается по выровненному на 4 байта относительно начала битмапа адресу. Только чтобы поддерживать цвет 664 или 666 придется делать нестандартный битмап, который все равно никто кроме гуя не поймет.
0
неверно.
сначала туда, потом читаете спецификацию
0
Что именно неверно?
Алсо забавно, когда я изучал спеки, про поддержку JPEG и PNG в BMP ничего не говорилось. Да и более чем 24-битные битмапы считались нестандартными. Хотя было это не так уж давно.
0
все неверно.
1. BMP и есть BitMap Picture
2. сжатие опция и есть не всегда. если есть, используется RLE, дешифровка — обсолютно безпроблемна грубо — вместо putpixel пишем DrawLine
3. откуда Вы взяли выравнивание в bmp? или я чего не понял в спецификации?
4. все современные системы поймут (читаем вики или msdn)
если под bitmap Вы подразумеваете тупо массив данных — ну так какая религия запрещадет добавить заголовок — очень полезная фича и много места не занимает
0
1. BMP и есть BitMap Picture
Вообще-то, битмап — это те данные, что там лежат после заголовка и палитры, если BMP без сжатия. Просто MS задействовали то же самое название для своего формата файлов. И, в принципе, не только они — есть несколько форматов вида «битмап с заголовком» имеющих название «битмап».
сжатие опция и есть не всегда.
Опциональность сжатия подразумевалась. Но сам битмап — это именно несжатые данные, насколько я помню.
3. откуда Вы взяли выравнивание в bmp? или я чего не понял в спецификации?
Из опыта. Впрочем, возможно, выравнивание относится не ко всем глубинам цвета, подробности я уже не помню. Ну и разумеется не относится к вариантам, когда вместо битмапа в BMP-файл засунут PNG или JPG.
4. все современные системы поймут (читаем вики или msdn)
Этот вопрос я не исследовал, 32-битные BMP меня не особо интересовали в связи со спецификой задачи.
ну так какая религия запрещадет добавить заголовок — очень полезная фича и много места не занимает
Никакая. Но не обязательно добавлять именно стандартный заголовок, особенно если он не очень-то соответсвует желаемому. Можно добавить заголовок своего формата.
0
ок. теримнология принята.
по следующим 3 пунктам ссылку уже давал
по п.5 — считаю, что надо придерживаться стандартов — позволяет избежать многих проблем и лишней работы. Тем более, что стандартов сейчас — немеряно, если не устраивают bmp заголовки, есть ico, и т.п.
0
Ну, когда картинка загрузится наискосок — вспомни про выравнивание.
Против стандартов в общем-то ничего не имею, но иногда это лишние накладные расходы и/или прокрустово ложе. Нужность стандартных картиночных форматов в эмбеддед-гуе достаточно сомнительна. BMP еще относительно немного ресурсов на себя требует (в вариантах без сжатия и с RLE), а вот JPG/PNG уже повеселей. Можно еще сформировать BMP с битмапом в RGB664 при помощи варианта сжатия BITFIELDS, но поддерживатсья будет далеко не везде (особенно учитывая, что далеко не все грузят BMP средствами винды, например стандартный декодер BMP в Delphi начинает глючить просто из-за нетипичного выравнивания заголовков).
0
скорее всего проблемы реализации, которую Вы использовали, даже примерно понятно, где там могут быть такие грабли.

самое интересное, что Ваши аргументы только подтверждают необходимость использования стандартов :)
Вы прямо убедили меня использовать стандарт и при необходимости конвертировать «на лету».
Спасибо за интересное обсуждение :)
0
скорее всего проблемы реализации, которую Вы использовали
Нет, на выравнивание я сам напоролся, когда лоадер BMP писал. Данные там явно выровнены построчно.
0
вот интересно, в msdn о выравнивании ни слова, а еще в одной статье про выравнивание есть. Буду разбриаться, в любом случае спасибо за указание на «грабли» :)
0
кому интересно, ссылка на статью
0
Вы прямо убедили меня использовать стандарт и при необходимости конвертировать «на лету».
Ну удачи. Спеки только читай повнимательней.
0
При использовании ARM Cortex с дисплеем, подключаемым через интерфейс FSMC, можно воспользоваться одним забавным трюком, позволяющим буквально в разы ускорить заливку цветом прямоугольников, вывод битмапов, рисование вертикальных и горизонтальных линий и т.п. (Всё это при использовании window function дисплея для автоинкремента адреса). Рецепт в том, что за одну команду можно выводить сразу два пикселя и избежать лишних задержек между ними.
Если записывать два раза по 16 бит, то между записями будет значительная задержка (обычно шесть циклов, и даже больше). А если записывать сразу 32-битное число, контроллер FSMC сам разбивает такую запись на две 16-битные по последовательным адресам и не вставляет между ними задержку. Если FSMC_A0 не используется (никуда не подключен) — обе записи попадают в одну и ту же ячейку дисплея и выводятся как два последовательных пикселя. Профит! Крайне рекомендую.

К сожалению, бывают схемы, в которых линия RS дисплея подключена к FSMC_A0. В таком случае этот хак не будет работать и придётся выводить пиксели по-одному.
+2
Спасибо!
не знал, надо подумать, у меня в любом случае засада — 18битный цвет и приходиться просто второе слово 0 закидывать. а RS у меня болтается на A19, буду смотреть
0
Я обычно использую дисплей в 16-битном режиме (RGB 565). Для GUI этого более, чем достаточно, при этом скорость отрисовки намного выше. Ну, не фотки же показывать на дисплее прибора? :)
0
да это контроллер дисплея такой, ничего нельзя сделать :( кроме как взять другой дисплей. точнее я использую 16-битный цвет, два младших бита от синего просто откидываю, но на шину данные все равно бросать приходится
0
А что за контроллер? Я работал с SSD1289 и ILI9325 — оба могут работать в 16-битном режиме, никаких проблем.
0
hx8347a. выбор интерфейса определяется ножками, эти ножки наружу не выведены. конфигурируются производителем дисплея. так производитель запаял их как 18битный с передачей данных по 16 бит за два слова:
RRRR RRGG GGGG BBBB
BB00 0000 0000 0000
более поздние версии контроллера, например hx8347b, позволяют программно переключать режим, а этот нет :(
0
Сочувствую.
Тем не менее, эти два последовательных вывода можно и нужно ускорить, раз у вас RS подключен на A19.
0
… если у вас распаян 18-разрядный интерфейс, но вам достаточно 16-разрядного, то почему бы два разряда не посадить на землю вместо
я использую 16-битный цвет, два младших бита от синего просто откидываю, но на шину данные все равно бросать приходится
0
0
… значит у вас 16-разрядный интерфейс, но с 18-бит на цвет
0
спасибо, кэп :)
0
А разве бывают схемы, в которых линия RS дисплея не подключена к FSMC_A0?
0
Да. На A16 его подключают, например. Удобно!
0
Идея отличная! Опробовал ее на своем девайсе. Количество транзакций уменьшилось вдвое. Единственное, если нужно выести нечетное количество 16 битных слов (читай, пикселей), то приходится досылать последнее уже в 16 битном режиме. Поскольку у меня заливка сделана через DMA, то приходися досылать последнюю порцию уже в самом обработчике прерывания окончания DMA.

Еще хочу уточнить про FSMC_A0 и RS. Я верно понимаю, что при записи второго полуслова происходит смена адреса на FSMC_A0? Получается, что RS может быть подключен на любую, отличную от FSMC_A0 линию адреса? А если у меня эти линии шарятся с внешней памятью, висящей на другом банке? Тут адресация к разным банкам не нарушит взаимодействия?
0
Да. При записи второго полуслова адрес инкрементируется на 1, так что FSMC_A0 меняется точно. Остальные МОГУТ измениться за счёт переноса. Поэтому RS должен быть подключен на любую линию, которая точно не изменится (должна лежать как минимум через 1 бит от старшего бита, который может измениться при инкременте адреса).
У другого банка FSMC отдельный chip select, так что проблем никаких не должно быть.
0
А что это за тема с переносом? Вот, пишу я например таким образом

*((__IO unsigned short *)LCD_REG_ADDR) = CMD_16;
*((__IO unsigned short *)LCD_DAT_ADDR) = DAT_32_1;
*((__IO unsigned short *)LCD_DAT_ADDR) = DAT_32_2;
...

На шине адреса ведь всегда выставляется LCD_DAT_ADDR при первой транзакции, LCD_DAT_ADDR +1 при второй.

Даже через DMA, если делать запись без автоинкремента DST адреса, то значения будут те же, при условии, что адрес DST равен LCD_DAT_ADDR. Верно?

У меня просто достаточно мало свободных GPIO от проца осталось. За оптимизацию борюсь.
0
Для работы с PNG файлами можно использовать готовую библиотеку www.libpng.org/pub/png/libpng.html
0
0
спасибо!
0
А чё там с гифом? лицензия кончилась у них?
0
Не в курсе
0
Нашел ответ на свой вопрос. и более того
патент не распространяется на устройства, которые могут лишь разжимать LZW-данные, но не сжимать их
Оказывается давно неактуально.
0
Полновесные libpng и zlib на МК? Не слишком ли жирно? Тожет, еще и libjpeg подтянуть вместо tinyjpg от Элм Чана?
0
У меня в проекте уже используются и libpng, и libungif, и tjpgd того самого чана.
0
А разве нет замены libpng полегче? Для того же zlib есть оптимизированная под минимальный вес альтернатива — tinf, порядка 2.5кб скомпилированного кода на х86. Видел, ЕМНИП, и легковесные библиотеки для PNG, правда, ориентированные на ПК, а не эмбед.
libungif не смотрел, но он в принципе довольно легковесный. Декодер LZW весьма прост. Правда, в стандартной реализации хочет 4кб ОЗУ под словарь.
0
Наверное есть что-то альтернативное, давайте ссылки, если есть, посмотрим.
0
Кое что посмотрел, появились мысли и вопросы:
1. Нужен ли пример проекта? GCC или Keil? Могу под Win или Qt сделать эмулятор, но сильно позже.
2. Дока нужна? Начал разбираться с доксигеном, соотв. дока планируется в стиле StdPeripherialLibrary от ST.
3. При использовании 16 цветной палитры рельно сделать фрейм-буфер для RGB (38кБ для qvga).
0
  • avatar
  • AVF
  • 18 января 2013, 18:53
Как раз решил освоить GUI, разбираюсь с Вашей. Адаптировал под свой SSD1289. Очень не хватает примеров. Так, что проект под Keil и дока очень бы пригодилась.
0
Андрей, под какой лицензией распостраняется проект?
Не могли бы Вы добавить файл LICENSE в проект, чтобы не было разночтений.
0
сейчас некогда, добавлю со следующим обновлением
0
первую строку невнимательно прочитал
под свободной для любого применения, включая коммерческое. если подскажите как правильно называется буду благодарен
0
Тогда Вам больше всего подходит лицензия BSD 3
отсюда:
opensource.org/licenses/BSD-3-Clause
Можно взять заготовку

Спасибо большое за проект.
0
Кое что посмотрел, появились мысли и вопросы:
1. Нужен ли пример проекта? GCC или Keil?
Конечно нужен. Я бы очень хотел посмотреть на пример проекта в Keil.
0
И дока конечно же не помешает. Заранее спасибо.
0
По мере освоения данной gui. Появилось небольшое дополнение. Если используется кнопка с текстом, то можно добавить реалистичности при нажатии. В функции void TextButtonDraw(TEXT_BUTTON * button) добавить условие для прорисовки нажатой кнопки :

if (button->wmTouch.Pressed)							// если кнопка нажата
    {
	LCD_DrawString(button->wmTxt.Text, button->wmTxt.TextLen, button->wmTxt.TextPosX + 1, button->wmTxt.TextPosY + 1);	// эффект сдвига текста на кнопке
    }
    else
	{
            LCD_DrawString(button->wmTxt.Text, button->wmTxt.TextLen, button->wmTxt.TextPosX, button->wmTxt.TextPosY);
	}				
<code>
И еще, можно было бы в структуре WM_TOUCH добавить поле - счетчик нажатий на кнопку. Бывает такое, что нужно знать сколько раз нажималась кнопка.
0
Есть еще простой способ без гемороя или велосипедов заиметь хорошее GUI в поделие с ARM Cortex-M любителю или мелкому барыге:
Берем у TI библиотеку grlib(Stellaris Graphics Library), она лежит отдельно или идет в составе StellarisWare(сборник библиотек для ARM Cortex-M чипов TI). Она предоставляется в исходных кодах для GCC,IAR,Keil,TI CCS. В составе основные граф.примитивы и виджеты(Canvas,Checkbox,Image Button,Push Button,Radio Button,ListBox,Slider,Container), куча готовых фонтов от 12-48 points(и утилита ftrasterize для их генерации в формате библиотеки из TrueType,OpenType,PostScript), Regular/Bold/Italic, поддержка ASCII(include ISO8859 — Cyr) и UTF-8/16.

Для взаимодействия с хардвеа надо самому написать модуль драйвера на Си(работает через Display/Input Device Driver API). В составе StellarisWare есть готовые исходники драйверов для TFT дисплеев 320x240 16-bit — можно использовать их как шаблон для своего дисплея.

P.S. Если вы используете чипы TI(Cortex-M3 LM3x или Cortex-M4 LM4Fx), использование данной библиотеки полностью легально. grlib royalty free при использовании чипов TI.

Для MSP430 есть облегченный вариант grlib(без виджетов).
0
Нарыл Microchip Graphics Display Designer.
The Microchip Graphics Display Designer (GDD) is a visual design tool that provides customers with a quick and easy way of creating graphical user interface (GUI) screens for graphical interface applications on Microchip MCUs.
Кто-нибудь пробовал?
0
Автор, спасибо за библиотеку, как раз нужно что-то без наворотов, но продвинутое.

Нет ли примерчика проекта для KEIL?
Я добавил в проект файлы — кучу ошибок выдает.
Какой из файлов хотя бы главный? В смысле, что писать в #include в моем собственном проекте?
0
блин… в архиве вообще все криво.
Ругается на отсутствие объявления COLOR_RED_MASK
ПОюзал поиск — есть только COLOR_RED_MASK_565 COLOR_RED_MASK_666
Что править, как править?
Автор, можете выложить библиотеку где концы сведены с концами?
0
Подозреваю, что нужно нужный из этих вариантов переименовать в COLOR_RED_MASK (или задефайнить нечто вроде -DCOLOR_RED_MASK=COLOR_RED_MASK_565).
0
в проекте все нормально было, по крайней мере 003 и 004 точно работают. проблема скорее всего ы том, что лишние файлы драйверов включены в проект надо или lcdHAL или universalHAL + файлы от соотв. контроллеров
0
погодите… в скачанном архиве нат файла проекта. Я пытался подключить к своему. У Вас есть проект для KEIL?
0
ну и подождите недельку, заканчиваю демо-проект, там будут примеры испльзования, ну и целиком проект
0
  • avatar
  • AVF
  • 11 мая 2013, 18:18
мне бы незаконченный демопроект — чтобы компилировался инициализировался и точку на экран выводил. evg_cimb@mail.ru
0
Как запустить скачанное по этому адресу github.com/AndreyFursov/AFGUI?
какие из файлов .h (список) нужно прописать в main.c?
Как добиться чтобы не было ошибок типа
0
FSMC_GUI\GUICore\src\widget.c(52): error: #132: expression must have pointer-to-struct-or-union type
FSMC_GUI\GUICore\src\widget.c(52): error: #20: identifier «DIR_LEFT_TO_RIGHT» is undefined
.\LCD_FSMC\GUIType.h(73): error: #20: identifier «U16» is undefined
FSMC_GUI\driver\src\lcdHAL.c(16): error: #20: identifier «COLOR_RED_MASK» is undefined
FSMC_GUI\driver\src\lcdHAL.c(121): warning: #223-D: function «LCD_WriteRAM» declared implicitly
0
Пардон… не до конца вычистил ранее использовавшуюся библиотеку. Сейчас это исправил и ошибок всего 3 типа:
1. .\FSMC_GUI\GUICore\inc\guiColor.h(14): error: #40: expected an identifier
Эта ошибка вылазит для конструкции
typedef struct
{
	unsigned BLUE	: 4;
	unsigned GREEN	: 6;
	unsigned RED	: 6;
} GUI_COLOR;


2. Следующий тип — злосчастные COLOR_RED_MASK, COLOR_RED_OFFSET и им подобные.
Они не определены.
3. FSMC_GUI\driver\src\lcdHAL.c(13): error: #29: expected an expression
Выдается для строк
const uint16_t std16Palette[] = 
{
			//					  R G B
	((0x000000>>24)&COLOR_RED_MASK)<<COLOR_RED_OFFSET | ((0x000000>>16)&COLOR_GREEN_MASK)<<COLOR_GREEN_OFFSET | ((0x000000 )&COLOR_BLUE_MASK)<<COLOR_BLUE_OFFSET,	//!< White			0x000000
0
А какая функция выводит прозрачный текст? Для обычного использую guiDrawString из файла guiText.c
0
функцию не делал, надо сделать guiDrawTransparentString аналогичную guiDrawString, в ней заменить функцию LCD_DrawChar на LCD_DrawTransparentChar
0
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.