Совместимость ЖК дисплея и STM32
Совместимость ЖК дисплея и STM32
Всем привет! Планирую купить на алиэкспресс микроконтроллер STM32F100RBT6B и 2 дисплея:
https://ru.aliexpress.com/item/High-Qua ... 23809ddacd
https://ru.aliexpress.com/item/2-4-inch ... 39.90158.0
На микроконтроллере нужно будет разработать 2 устройства. Из-за моей неопытности возникают сомнения, будет ли совместимо все между собой. Для дисплеев вроде как какие то специальные библиотеки нужны. Прокомментируйте пожалуйста.
https://ru.aliexpress.com/item/High-Qua ... 23809ddacd
https://ru.aliexpress.com/item/2-4-inch ... 39.90158.0
На микроконтроллере нужно будет разработать 2 устройства. Из-за моей неопытности возникают сомнения, будет ли совместимо все между собой. Для дисплеев вроде как какие то специальные библиотеки нужны. Прокомментируйте пожалуйста.
- Реклама
Re: Совместимость ЖК дисплея и STM32
Почему не STM32F103RBT6 или STM32F103RET6?201bazza писал(а):Планирую купить на алиэкспресс микроконтроллер STM32F100RBT6B
Библиотека это код, а его можно найти или написать свой.201bazza писал(а):Для дисплеев вроде как какие то специальные библиотеки нужны.
Например для Nokia 5110. http://purebasic.mybb.ru/viewtopic.php?id=574#p7266
Там немного другая модель МК, но можно адаптировать для F10x.
Re: Совместимость ЖК дисплея и STM32
Можно в принципе любой микроконтроллер.Почему не STM32F103RBT6 или STM32F103RET6?
Я так и думал. Можно запрогать свою библиотеку. Ну ладно, будем заказывать с алиэкспресс, разбираться.Библиотека это код, а его можно найти или написать свой.
Re: Совместимость ЖК дисплея и STM32
[uquote="201bazza",url="/forum/viewtopic.php?p=3534760#p3534760"]На микроконтроллере нужно будет разработать 2 устройства. Из-за моей неопытности возникают сомнения, будет ли совместимо все между собой. Для дисплеев вроде как какие то специальные библиотеки нужны. Прокомментируйте пожалуйста.[/uquote]
А что комментировать? Всё возможно. Зависит от задачи.
Тот который на 320x240 имеет минимум 16 бит цвета. Чтобы на нём что-то отобразить, нужно сперва нарисовать это что-то в памяти (МК), а после - отправить картинку по SPI на LCD.
Вот и посчитайте сколько нужно памяти для рисования. Отсюда и выбирайте МК. Можно конечно рисовать не целиком, а по-частям. Но это будет медленнее и сложнее. Да и если картинка меняется значительно и быстро, то и МК нужен помощнее. Иначе всё будет в артефактах.
Второй LCD, который маленький, там любого МК будет достаточно.
На 320x240 если нужно выводить только текст и редко меняющиеся картинки (или меняющиеся быстро, но мелкие), то хватит слабенького МК с малой ОЗУ как ваш. Если нужна динамика на большой площади (хотя-бы просто бегущие строки крупным шрифтом), то лучше брать МК с бОльшим ОЗУ.
А что комментировать? Всё возможно. Зависит от задачи.
Тот который на 320x240 имеет минимум 16 бит цвета. Чтобы на нём что-то отобразить, нужно сперва нарисовать это что-то в памяти (МК), а после - отправить картинку по SPI на LCD.
Вот и посчитайте сколько нужно памяти для рисования. Отсюда и выбирайте МК. Можно конечно рисовать не целиком, а по-частям. Но это будет медленнее и сложнее. Да и если картинка меняется значительно и быстро, то и МК нужен помощнее. Иначе всё будет в артефактах.
Второй LCD, который маленький, там любого МК будет достаточно.
На 320x240 если нужно выводить только текст и редко меняющиеся картинки (или меняющиеся быстро, но мелкие), то хватит слабенького МК с малой ОЗУ как ваш. Если нужна динамика на большой площади (хотя-бы просто бегущие строки крупным шрифтом), то лучше брать МК с бОльшим ОЗУ.
Последний раз редактировалось jcxz Вт дек 25, 2018 17:48:56, всего редактировалось 1 раз.
Re: Совместимость ЖК дисплея и STM32
[uquote="jcxz",url="/forum/viewtopic.php?p=3534802#p3534802"]Тот который на 320x240 имеет минимум 16 бит цвета. Чтобы на нём что-то отобразить, нужно сперва нарисовать это что-то в памяти (МК), а после - отправить картинку по SPI на LCD.[/uquote]
Там не SPI, а 8-ми битная шина. В любом случае в памяти рисовать обычно нет смысла, если нормально делать, то и напрямую все быстро выводится.
Там не SPI, а 8-ми битная шина. В любом случае в памяти рисовать обычно нет смысла, если нормально делать, то и напрямую все быстро выводится.
- Реклама
Re: Совместимость ЖК дисплея и STM32
[uquote="Reflector",url="/forum/viewtopic.php?p=3534812#p3534812"]Там не SPI, а 8-ми битная шина. В любом случае в памяти рисовать обычно нет смысла, если нормально делать, то и напрямую все быстро выводится.[/uquote]
В том который 320x240 есть и SPI и параллельная шина, если вы внимательно посмотрите на него.
А судя по тому, что второй LCD - имеет только SPI, то можно предположить что автор ищет LCD с подключением по SPI. Да и не имеет смысла тащить кучу проводов параллельного интерфейса если есть SPI.
И понятие "быстро выводится" у всех разные: кто-то не замечает моргание и прочие артефакты медленного обновления картинки по частям, а кому-то даже небольшие артефакты уже мешают. Если есть динамика в картинке - надо 100 раз подумать прежде чем быдлокодить ногодрыгом картинку по частям без видеобуфера. Тем более если МК должен ещё чем-то заниматься, кроме обновления экрана.
В том который 320x240 есть и SPI и параллельная шина, если вы внимательно посмотрите на него.
А судя по тому, что второй LCD - имеет только SPI, то можно предположить что автор ищет LCD с подключением по SPI. Да и не имеет смысла тащить кучу проводов параллельного интерфейса если есть SPI.
И понятие "быстро выводится" у всех разные: кто-то не замечает моргание и прочие артефакты медленного обновления картинки по частям, а кому-то даже небольшие артефакты уже мешают. Если есть динамика в картинке - надо 100 раз подумать прежде чем быдлокодить ногодрыгом картинку по частям без видеобуфера. Тем более если МК должен ещё чем-то заниматься, кроме обновления экрана.
Re: Совместимость ЖК дисплея и STM32
[uquote="jcxz",url="/forum/viewtopic.php?p=3534819#p3534819"]В том который 320x240 есть и SPI и параллельная шина, если вы внимательно посмотрите на него.[/uquote]
Там SPI на карту памяти идет.
Там SPI на карту памяти идет.
Понятно, что SPI во многих случаях лучше, но такие дисплеи дороже и выбор меньше. А на автора ориентироваться не стоит, он в этом мало что понимает.А судя по тому, что второй LCD - имеет только SPI, то можно предположить что автор ищет LCD с подключением по SPI. Да и не имеет смысла тащить кучу проводов параллельного интерфейса если есть SPI.
Скорость вывода картинки или текста напрямую мало отличается от простой заливки прямоугольника, а это основные задачи, помимо этого разве что рисование линий еще относительно востребовано, но и они рисуются очень быстро. С DMA такую отрисовку не очень удобно совмещать, но почти всегда без этого можно обойтись, по крайней мере в любительских проектах. У меня на разогнанном F103(без FSMC) работал на полной скорости спектрум подключенный как раз к такой 8-ми битной шине, при этом выдавал 50 фпс при нормальном звуке(бипер и AY). Или другой пример, неразогнанный F303 подключенный опять же через ногодрыг выводит каталог с sd карты на весь экран мелким шрифтом, с длинными именами, в среднем больше половины строки, предварительно очищая каждую строку целиком, 40 раз в сек и сюда включено время чтения с SD.И понятие "быстро выводится" у всех разные: кто-то не замечает моргание и прочие артефакты медленного обновления картинки по частям, а кому-то даже небольшие артефакты уже мешают. Если есть динамика в картинке - надо 100 раз подумать прежде чем быдлокодить ногодрыгом картинку по частям без видеобуфера. Тем более если МК должен ещё чем-то заниматься, кроме обновления экрана.
Re: Совместимость ЖК дисплея и STM32
[uquote="Reflector",url="/forum/viewtopic.php?p=3534844#p3534844"]Скорость вывода картинки или текста напрямую мало отличается от простой заливки прямоугольника, а это основные задачи, помимо этого разве что рисование линий еще относительно востребовано, но и они рисуются очень быстро.[/uquote]
Ну не знаю. Даже просто вывод текста выводу текста - рознь. Можно написать жёстко, без клиппинга по краям окна, без попиксельного позиционирования (позиционирование с дискретностью == байт), с только одной ориентацией текста (без поворота на 90 градусов) и т.д. А кому-то и поворот текста на произвольный угол подавай и сглаживание шрифта (встречал таких - без сглаживания никак, обязательно) и т.п.
Уже не говоря про разные заливки произвольных областей экрана и плавные фильтры для цвета.
И в этом случае желательно чтобы рисование шло параллельно выводу на экран.
[uquote="Reflector",url="/forum/viewtopic.php?p=3534844#p3534844"]С DMA такую отрисовку не очень удобно совмещать[/uquote]
Ничего сложного - пока рисуем в одну страницу, другая в этот момент выводится.
[uquote="Reflector",url="/forum/viewtopic.php?p=3534844#p3534844"]Или другой пример, неразогнанный F303 подключенный опять же через ногодрыг выводит каталог с sd карты на весь экран мелким шрифтом, с длинными именами, в среднем больше половины строки, предварительно очищая каждую строку целиком, 40 раз в сек и сюда включено время чтения с SD.[/uquote]
Вот именно "очищая". А не наложением. А если, например, нужна бегущая строка наложенная поверх сложного фона? Да не мелким шрифтом? Да ещё с эффектами. Да и к тому же очень многое зависит от разрешения. По пикселам и цвету.
А спектрумы тут вообще не при делах - там же только псевдографика была.
Если даже в любительском проекте захочется хотя-бы оконный интерфейс, с наложением на сложный фон (с сохранением его в буфер), то тут и операций рисования и ОЗУ ой как много потребуется.
В буфер сохранить, рамку окошка отрисовать (а может и тень), кнопочки отрисовать (и тени), надписи на кнопочках отрисовать, содержимое окна отрисовать - опухнет F100.
Если фон под окном в буфер не сохранять, а обновлять фон отрисовкой содержимого нижележащих окон с клиппингом - тут процессора нужно ещё больше (хотя ОЗУ - меньше).
Ну не знаю. Даже просто вывод текста выводу текста - рознь. Можно написать жёстко, без клиппинга по краям окна, без попиксельного позиционирования (позиционирование с дискретностью == байт), с только одной ориентацией текста (без поворота на 90 градусов) и т.д. А кому-то и поворот текста на произвольный угол подавай и сглаживание шрифта (встречал таких - без сглаживания никак, обязательно) и т.п.
Уже не говоря про разные заливки произвольных областей экрана и плавные фильтры для цвета.
И в этом случае желательно чтобы рисование шло параллельно выводу на экран.
[uquote="Reflector",url="/forum/viewtopic.php?p=3534844#p3534844"]С DMA такую отрисовку не очень удобно совмещать[/uquote]
Ничего сложного - пока рисуем в одну страницу, другая в этот момент выводится.
[uquote="Reflector",url="/forum/viewtopic.php?p=3534844#p3534844"]Или другой пример, неразогнанный F303 подключенный опять же через ногодрыг выводит каталог с sd карты на весь экран мелким шрифтом, с длинными именами, в среднем больше половины строки, предварительно очищая каждую строку целиком, 40 раз в сек и сюда включено время чтения с SD.[/uquote]
Вот именно "очищая". А не наложением. А если, например, нужна бегущая строка наложенная поверх сложного фона? Да не мелким шрифтом? Да ещё с эффектами. Да и к тому же очень многое зависит от разрешения. По пикселам и цвету.
А спектрумы тут вообще не при делах - там же только псевдографика была.
Если даже в любительском проекте захочется хотя-бы оконный интерфейс, с наложением на сложный фон (с сохранением его в буфер), то тут и операций рисования и ОЗУ ой как много потребуется.
В буфер сохранить, рамку окошка отрисовать (а может и тень), кнопочки отрисовать (и тени), надписи на кнопочках отрисовать, содержимое окна отрисовать - опухнет F100.
Если фон под окном в буфер не сохранять, а обновлять фон отрисовкой содержимого нижележащих окон с клиппингом - тут процессора нужно ещё больше (хотя ОЗУ - меньше).
Re: Совместимость ЖК дисплея и STM32
Jcxz, суть в том, что мк с относительно небольшой RAM позволяет быстро отрисовать большую часть из того, с чем обычно сталкиваются в любительских, и не очень, проектах. Без большого или вообще без никакого промежуточного буфера, с попиксельным позиционированием и возможностью выводить вертикальный текст так же просто, как горизонтальный, но речь не идет о сглаживании, полупрозрачности, произвольной заливке и прочим обычно ненужных излишествам. Я видел множество проектов где выводили текст или линии попиксельно и полностью убивали производительность, на днях даже видел как выводят в порт дисплея байт побитно, но полупрозрачность помню только в одном проекте где ради нее вместо F4 со встроенной памятью взяли F7 с внешней...
[uquote="Reflector",url="/forum/viewtopic.php?p=3534844#p3534844"]Ничего сложного - пока рисуем в одну страницу, другая в этот момент выводится.[/uquote]
Я говорил про случаи когда вывод идет напрямую.
[uquote="Reflector",url="/forum/viewtopic.php?p=3534844#p3534844"]Вот именно "очищая". А не наложением. Да ещё с эффектами. Да и к тому же очень многое зависит от разрешения. По пикселам и цвету.[/uquote]
Дисплей был почти такой-же, цветной 320x240. Очистка там только добавляла тормозов, т.е. потенциально код можно было заставить работать еще быстрее. Естественно без наложений и эффектов.

[uquote="Reflector",url="/forum/viewtopic.php?p=3534844#p3534844"]Ничего сложного - пока рисуем в одну страницу, другая в этот момент выводится.[/uquote]
Я говорил про случаи когда вывод идет напрямую.
[uquote="Reflector",url="/forum/viewtopic.php?p=3534844#p3534844"]Вот именно "очищая". А не наложением. Да ещё с эффектами. Да и к тому же очень многое зависит от разрешения. По пикселам и цвету.[/uquote]
Дисплей был почти такой-же, цветной 320x240. Очистка там только добавляла тормозов, т.е. потенциально код можно было заставить работать еще быстрее. Естественно без наложений и эффектов.
Там не псевдографика, но в принципе это не важно, все равно каждую точку перед выводом на дисплей нужно на ходу преобразовать в 2 байт цвета, где каждый байт в идеале выводится с частотой 14MHz. Конкретно в этом варианте спектрума у меня была пара буферов на одну строку, всего 1КБ, а полный буфер, даже без бордюра, занял бы 100КБ.А спектрумы тут вообще не при делах - там же только псевдографика была.
Да с этим никто не спорит, но начиналось все с того, что сперва нужно нарисовать что-то в памяти, которой должно быть много, потом отправить это на дисплей, а теперь речь идет о случаях когда, как тут правильно заметили, захочется написать WindowsЕсли даже в любительском проекте захочется хотя-бы оконный интерфейс, с наложением на сложный фон (с сохранением его в буфер), то тут и операций рисования и ОЗУ ой как много потребуется.
В буфер сохранить, рамку окошка отрисовать (а может и тень), кнопочки отрисовать (и тени), надписи на кнопочках отрисовать, содержимое окна отрисовать - опухнет F100.
Re: Совместимость ЖК дисплея и STM32
Делал как-то оконный интерфейс на подобие EGA. В F207 хватало сохранить текстовую инфу под окном до 50х30 знакомест с атрибутами (3 кбайта). Плата так и лежит невостребованная.
Re: Совместимость ЖК дисплея и STM32
[uquote="Reflector",url="/forum/viewtopic.php?p=3534928#p3534928"]Я видел множество проектов где выводили текст или линии попиксельно и полностью убивали производительность, на днях даже видел как выводят в порт дисплея байт побитно, но полупрозрачность помню только в одном проекте где ради нее вместо F4 со встроенной памятью взяли F7 с внешней...[/uquote]
А мне только на днях один товарищ доказывал, что "сейчас нафиг никому не нужны шрифты без сглаживания". И на все мои возражения что на таком экране как 320x240 2.2" дискретность краёв букв заметна только в упор, он отвечал, что "всё это отстой и в современных условиях любой пользователь будет блевать от такого устройства где шрифты рисуются без сглаживания и выкинет его на помойку".
Так что у всех критерии разные. И мы не знаем какие критерии качества картинки у автора топика.
[uquote="Reflector",url="/forum/viewtopic.php?p=3534928#p3534928"]
Насколько я знаю, в спектруме цвет задавался не для всей точки, а только для знакоместа. Так что по цветовой компоненте - псевдографика.
И какие там 100КБ? Там пиксельный буфер наверное на 8КБ + пара КБ на массив цветов знакомест.
[uquote="Reflector",url="/forum/viewtopic.php?p=3534928#p3534928"]Да с этим никто не спорит, но начиналось все с того, что сперва нужно нарисовать что-то в памяти, которой должно быть много, потом отправить это на дисплей, а теперь речь идет о случаях когда, как тут правильно заметили, захочется написать Windows
[/uquote]
Ну я сразу в первом сообщении сказал, что всё зависит от задачи. И в простейших случаях хватит простого МК.
Это Вы видимо начинали со спектрумов и будете довольны белым текстом на чёрном экране. А нонче всё модно окошками делать.
А я вот уже и для своего хобби-проекта подумываю систему менюшек в оконный вид переделать. Чтоб не ретроградно выглядело
У меня и на моём древнем Векторе (что-то типа уровня Спектрума) в стародавние времена в одной моей программе, уже были окошки, с наложением на произвольный фон. И с тенью под окном. Да, тормозило, но выглядело круто по тем временам!

А мне только на днях один товарищ доказывал, что "сейчас нафиг никому не нужны шрифты без сглаживания". И на все мои возражения что на таком экране как 320x240 2.2" дискретность краёв букв заметна только в упор, он отвечал, что "всё это отстой и в современных условиях любой пользователь будет блевать от такого устройства где шрифты рисуются без сглаживания и выкинет его на помойку".
Так что у всех критерии разные. И мы не знаем какие критерии качества картинки у автора топика.
[uquote="Reflector",url="/forum/viewtopic.php?p=3534928#p3534928"]
Там не псевдографика, но в принципе это не важно, все равно каждую точку перед выводом на дисплей нужно на ходу преобразовать в 2 байт цвета, где каждый байт в идеале выводится с частотой 14MHz. Конкретно в этом варианте спектрума у меня была пара буферов на одну строку, всего 1КБ, а полный буфер, даже без бордюра, занял бы 100КБ.[/uquote]А спектрумы тут вообще не при делах - там же только псевдографика была.
Насколько я знаю, в спектруме цвет задавался не для всей точки, а только для знакоместа. Так что по цветовой компоненте - псевдографика.
И какие там 100КБ? Там пиксельный буфер наверное на 8КБ + пара КБ на массив цветов знакомест.
[uquote="Reflector",url="/forum/viewtopic.php?p=3534928#p3534928"]Да с этим никто не спорит, но начиналось все с того, что сперва нужно нарисовать что-то в памяти, которой должно быть много, потом отправить это на дисплей, а теперь речь идет о случаях когда, как тут правильно заметили, захочется написать Windows
Ну я сразу в первом сообщении сказал, что всё зависит от задачи. И в простейших случаях хватит простого МК.
Это Вы видимо начинали со спектрумов и будете довольны белым текстом на чёрном экране. А нонче всё модно окошками делать.
А я вот уже и для своего хобби-проекта подумываю систему менюшек в оконный вид переделать. Чтоб не ретроградно выглядело
У меня и на моём древнем Векторе (что-то типа уровня Спектрума) в стародавние времена в одной моей программе, уже были окошки, с наложением на произвольный фон. И с тенью под окном. Да, тормозило, но выглядело круто по тем временам!
Re: Совместимость ЖК дисплея и STM32
Благодарю всех за ответы! После внимательного изучения интернета решил пока остановиться на дисплее 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 ... 501826d0c0.
Нигде не могу найти грамотного описания к такой плате. Вопросов только два: 1) для чего нужен USB разъем? Программатор ST-Link подключается к 4-ем выводам, как я понял; 2) Хотелось бы использовать софт для прошивки, рекомендуемый производителем STMicroelectronics. Везде разговор за Arduino IDE (тут какой то колхоз идет. Заливка спецзагрузчиков, библиотеки и прочая непонятная мне хрень). Подойдет программа Keil μvision для написания кода и прошивки?
Re: Совместимость ЖК дисплея и STM32
Ее можно купить дешевле. https://ru.aliexpress.com/item/STM32F10 ... 17171.html201bazza писал(а):Думаю, может взять на первое время вот такую отладочную плату
Микроконтроллер позволяет создавать USB устройства. http://purebasic.mybb.ru/viewtopic.php?id=592201bazza писал(а):для чего нужен USB разъем?
Не везде. Вот для начала. http://purebasic.mybb.ru/viewtopic.php?id=575201bazza писал(а):Везде разговор за Arduino IDE
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


