Совместимость ЖК дисплея и STM32

[201bazza]

Всем привет! Планирую купить на алиэкспресс микроконтроллер STM32F100RBT6B и 2 дисплея:

https://ru.aliexpress.com/item/High-Qua ... 23809ddacd

https://ru.aliexpress.com/item/2-4-inch ... 39.90158.0

На микроконтроллере нужно будет разработать 2 устройства. Из-за моей неопытности возникают сомнения, будет ли совместимо все между собой. Для дисплеев вроде как какие то специальные библиотеки нужны. Прокомментируйте пожалуйста.

[Мурик]

Планирую купить на алиэкспресс микроконтроллер STM32F100RBT6B

Почему не STM32F103RBT6 или STM32F103RET6?

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

Библиотека это код, а его можно найти или написать свой.
Например для Nokia 5110. http://purebasic.mybb.ru/viewtopic.php?id=574#p7266
Там немного другая модель МК, но можно адаптировать для F10x.

[201bazza]

Почему не STM32F103RBT6 или STM32F103RET6?

Можно в принципе любой микроконтроллер.

Библиотека это код, а его можно найти или написать свой.

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

[jcxz]

201bazza писал(а):

На микроконтроллере нужно будет разработать 2 устройства. Из-за моей неопытности возникают сомнения, будет ли совместимо все между собой. Для дисплеев вроде как какие то специальные библиотеки нужны. Прокомментируйте пожалуйста.

А что комментировать? Всё возможно. Зависит от задачи.
Тот который на 320x240 имеет минимум 16 бит цвета. Чтобы на нём что-то отобразить, нужно сперва нарисовать это что-то в памяти (МК), а после - отправить картинку по SPI на LCD.
Вот и посчитайте сколько нужно памяти для рисования. Отсюда и выбирайте МК. Можно конечно рисовать не целиком, а по-частям. Но это будет медленнее и сложнее. Да и если картинка меняется значительно и быстро, то и МК нужен помощнее. Иначе всё будет в артефактах.
Второй LCD, который маленький, там любого МК будет достаточно.

На 320x240 если нужно выводить только текст и редко меняющиеся картинки (или меняющиеся быстро, но мелкие), то хватит слабенького МК с малой ОЗУ как ваш. Если нужна динамика на большой площади (хотя-бы просто бегущие строки крупным шрифтом), то лучше брать МК с бОльшим ОЗУ.

Последний раз редактировалось jcxz Вт дек 25, 2018 17:48:56, всего редактировалось 1 раз.

[Reflector]

jcxz писал(а):

Тот который на 320x240 имеет минимум 16 бит цвета. Чтобы на нём что-то отобразить, нужно сперва нарисовать это что-то в памяти (МК), а после - отправить картинку по SPI на LCD.

Там не SPI, а 8-ми битная шина. В любом случае в памяти рисовать обычно нет смысла, если нормально делать, то и напрямую все быстро выводится.

[jcxz]

Reflector писал(а):

Там не SPI, а 8-ми битная шина. В любом случае в памяти рисовать обычно нет смысла, если нормально делать, то и напрямую все быстро выводится.

В том который 320x240 есть и SPI и параллельная шина, если вы внимательно посмотрите на него.
А судя по тому, что второй LCD - имеет только SPI, то можно предположить что автор ищет LCD с подключением по SPI. Да и не имеет смысла тащить кучу проводов параллельного интерфейса если есть SPI.
И понятие "быстро выводится" у всех разные: кто-то не замечает моргание и прочие артефакты медленного обновления картинки по частям, а кому-то даже небольшие артефакты уже мешают. Если есть динамика в картинке - надо 100 раз подумать прежде чем быдлокодить ногодрыгом картинку по частям без видеобуфера. Тем более если МК должен ещё чем-то заниматься, кроме обновления экрана.

[Reflector]

jcxz писал(а):

В том который 320x240 есть и SPI и параллельная шина, если вы внимательно посмотрите на него.

Там SPI на карту памяти идет.

А судя по тому, что второй LCD - имеет только SPI, то можно предположить что автор ищет LCD с подключением по SPI. Да и не имеет смысла тащить кучу проводов параллельного интерфейса если есть SPI.

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

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

Скорость вывода картинки или текста напрямую мало отличается от простой заливки прямоугольника, а это основные задачи, помимо этого разве что рисование линий еще относительно востребовано, но и они рисуются очень быстро. С DMA такую отрисовку не очень удобно совмещать, но почти всегда без этого можно обойтись, по крайней мере в любительских проектах. У меня на разогнанном F103(без FSMC) работал на полной скорости спектрум подключенный как раз к такой 8-ми битной шине, при этом выдавал 50 фпс при нормальном звуке(бипер и AY). Или другой пример, неразогнанный F303 подключенный опять же через ногодрыг выводит каталог с sd карты на весь экран мелким шрифтом, с длинными именами, в среднем больше половины строки, предварительно очищая каждую строку целиком, 40 раз в сек и сюда включено время чтения с SD.

[jcxz]

Reflector писал(а):

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

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

Reflector писал(а):

С DMA такую отрисовку не очень удобно совмещать

Ничего сложного - пока рисуем в одну страницу, другая в этот момент выводится.

Reflector писал(а):

Или другой пример, неразогнанный F303 подключенный опять же через ногодрыг выводит каталог с sd карты на весь экран мелким шрифтом, с длинными именами, в среднем больше половины строки, предварительно очищая каждую строку целиком, 40 раз в сек и сюда включено время чтения с SD.

Вот именно "очищая". А не наложением. А если, например, нужна бегущая строка наложенная поверх сложного фона? Да не мелким шрифтом? Да ещё с эффектами. Да и к тому же очень многое зависит от разрешения. По пикселам и цвету.
А спектрумы тут вообще не при делах - там же только псевдографика была.
Если даже в любительском проекте захочется хотя-бы оконный интерфейс, с наложением на сложный фон (с сохранением его в буфер), то тут и операций рисования и ОЗУ ой как много потребуется.
В буфер сохранить, рамку окошка отрисовать (а может и тень), кнопочки отрисовать (и тени), надписи на кнопочках отрисовать, содержимое окна отрисовать - опухнет F100.
Если фон под окном в буфер не сохранять, а обновлять фон отрисовкой содержимого нижележащих окон с клиппингом - тут процессора нужно ещё больше (хотя ОЗУ - меньше).

[240265]

Ну прям Windows

[Reflector]

Jcxz, суть в том, что мк с относительно небольшой RAM позволяет быстро отрисовать большую часть из того, с чем обычно сталкиваются в любительских, и не очень, проектах. Без большого или вообще без никакого промежуточного буфера, с попиксельным позиционированием и возможностью выводить вертикальный текст так же просто, как горизонтальный, но речь не идет о сглаживании, полупрозрачности, произвольной заливке и прочим обычно ненужных излишествам. Я видел множество проектов где выводили текст или линии попиксельно и полностью убивали производительность, на днях даже видел как выводят в порт дисплея байт побитно, но полупрозрачность помню только в одном проекте где ради нее вместо F4 со встроенной памятью взяли F7 с внешней...

Reflector писал(а):

Ничего сложного - пока рисуем в одну страницу, другая в этот момент выводится.

Я говорил про случаи когда вывод идет напрямую.

Reflector писал(а):

Вот именно "очищая". А не наложением. Да ещё с эффектами. Да и к тому же очень многое зависит от разрешения. По пикселам и цвету.

Дисплей был почти такой-же, цветной 320x240. Очистка там только добавляла тормозов, т.е. потенциально код можно было заставить работать еще быстрее. Естественно без наложений и эффектов.

А спектрумы тут вообще не при делах - там же только псевдографика была.

Там не псевдографика, но в принципе это не важно, все равно каждую точку перед выводом на дисплей нужно на ходу преобразовать в 2 байт цвета, где каждый байт в идеале выводится с частотой 14MHz. Конкретно в этом варианте спектрума у меня была пара буферов на одну строку, всего 1КБ, а полный буфер, даже без бордюра, занял бы 100КБ.

Если даже в любительском проекте захочется хотя-бы оконный интерфейс, с наложением на сложный фон (с сохранением его в буфер), то тут и операций рисования и ОЗУ ой как много потребуется.
В буфер сохранить, рамку окошка отрисовать (а может и тень), кнопочки отрисовать (и тени), надписи на кнопочках отрисовать, содержимое окна отрисовать - опухнет F100.

Да с этим никто не спорит, но начиналось все с того, что сперва нужно нарисовать что-то в памяти, которой должно быть много, потом отправить это на дисплей, а теперь речь идет о случаях когда, как тут правильно заметили, захочется написать Windows

[Sergi]

Делал как-то оконный интерфейс на подобие EGA. В F207 хватало сохранить текстовую инфу под окном до 50х30 знакомест с атрибутами (3 кбайта). Плата так и лежит невостребованная.

[jcxz]

Reflector писал(а):

Я видел множество проектов где выводили текст или линии попиксельно и полностью убивали производительность, на днях даже видел как выводят в порт дисплея байт побитно, но полупрозрачность помню только в одном проекте где ради нее вместо F4 со встроенной памятью взяли F7 с внешней...

А мне только на днях один товарищ доказывал, что "сейчас нафиг никому не нужны шрифты без сглаживания". И на все мои возражения что на таком экране как 320x240 2.2" дискретность краёв букв заметна только в упор, он отвечал, что "всё это отстой и в современных условиях любой пользователь будет блевать от такого устройства где шрифты рисуются без сглаживания и выкинет его на помойку".
Так что у всех критерии разные. И мы не знаем какие критерии качества картинки у автора топика.

Reflector писал(а):

А спектрумы тут вообще не при делах - там же только псевдографика была.

Там не псевдографика, но в принципе это не важно, все равно каждую точку перед выводом на дисплей нужно на ходу преобразовать в 2 байт цвета, где каждый байт в идеале выводится с частотой 14MHz. Конкретно в этом варианте спектрума у меня была пара буферов на одну строку, всего 1КБ, а полный буфер, даже без бордюра, занял бы 100КБ.

Насколько я знаю, в спектруме цвет задавался не для всей точки, а только для знакоместа. Так что по цветовой компоненте - псевдографика.
И какие там 100КБ? Там пиксельный буфер наверное на 8КБ + пара КБ на массив цветов знакомест.

Reflector писал(а):

Да с этим никто не спорит, но начиналось все с того, что сперва нужно нарисовать что-то в памяти, которой должно быть много, потом отправить это на дисплей, а теперь речь идет о случаях когда, как тут правильно заметили, захочется написать Windows

Ну я сразу в первом сообщении сказал, что всё зависит от задачи. И в простейших случаях хватит простого МК.
Это Вы видимо начинали со спектрумов и будете довольны белым текстом на чёрном экране. А нонче всё модно окошками делать.
А я вот уже и для своего хобби-проекта подумываю систему менюшек в оконный вид переделать. Чтоб не ретроградно выглядело
У меня и на моём древнем Векторе (что-то типа уровня Спектрума) в стародавние времена в одной моей программе, уже были окошки, с наложением на произвольный фон. И с тенью под окном. Да, тормозило, но выглядело круто по тем временам!

[201bazza]

Благодарю всех за ответы! После внимательного изучения интернета решил пока остановиться на дисплее https://ru.aliexpress.com/item/High-Qua ... 23809ddacd. Даташит даже к нему нашел.

Теперь с микроконтроллером. Думаю, может взять на первое время вот такую отладочную плату https://ru.aliexpress.com/item/STM32F10 ... 501826d0c0.

Нигде не могу найти грамотного описания к такой плате. Вопросов только два: 1) для чего нужен USB разъем? Программатор ST-Link подключается к 4-ем выводам, как я понял; 2) Хотелось бы использовать софт для прошивки, рекомендуемый производителем STMicroelectronics. Везде разговор за Arduino IDE (тут какой то колхоз идет. Заливка спецзагрузчиков, библиотеки и прочая непонятная мне хрень). Подойдет программа Keil μvision для написания кода и прошивки?

[Мурик]

Думаю, может взять на первое время вот такую отладочную плату

Ее можно купить дешевле. https://ru.aliexpress.com/item/STM32F10 ... 17171.html

для чего нужен USB разъем?

Микроконтроллер позволяет создавать USB устройства. http://purebasic.mybb.ru/viewtopic.php?id=592

Везде разговор за Arduino IDE

Не везде. Вот для начала. http://purebasic.mybb.ru/viewtopic.php?id=575
http://purebasic.mybb.ru/viewtopic.php?id=564
Если нужно заливать прошивку используя программу рекомендуемую производителем, нужно добавить инструмент в IDE. http://forum.easyelectronics.ru/viewtop ... 66#p463866
Для этого необходимо скачать и установить программу STM32 ST-LINK Utility от производителя МК. https://www.st.com/en/development-tools ... nk004.html

[240265]

Keil μvision отлично подходит.