Jump to content

    
Sign in to follow this  
zheka

STM32F429-Disco, CubeMX и TouchGFX Designer. Тема будет долгой....

Recommended Posts

2 часа назад, Xenia сказал:

Именно поэтому я сразу заявила, что демо-программу обсуждать не хочу. И вообще всё, где торчит хедер


 "stm32f429i_discovery.h"

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

Вы изначально хотели "Hello, world" вывести. Исходя из этого я и писал ответные посты.

 

2 часа назад, Xenia сказал:

Тогда как вы, вероятно, дальше main() не заглядывали, а потому


  LCD_Init();
  LCD_LayerInit();

кажется вам легким и простым, т.к. вы не видели всего того дерьма, которое за этой простотой стоит.

Видел. И даже видя, что стоит за этими функциями, не вижу в них ничего сложного.

 

Ну тогда надо было хоть сказать, что экран надо запустить без SDRAM, по SPI. Думаю, для Ваших целей там памяти примерно 0 потребуется.

Share this post


Link to post
Share on other sites
1 час назад, Arlleex сказал:

Вы изначально хотели "Hello, world" вывести. Исходя из этого я и писал ответные посты.

Я только за тем в эту тему пришла, чтобы выяснить, способен ли этот хваленый "TouchGFX Designer"  работать без SDRAM. Ведь не на всех же платах микросхема SDRAM припаяна.

Об этом я интересовалась, как в своем первом сообщении:

В 15.03.2020 в 12:42, Xenia сказал:

Скажите, а та микросхема SDRAM памяти IS42S16400J, что на плате снизу прикручена, обязательно ли должна быть использована под дисплей? Что по этому поводу думает ваш TouchGFX Designer? Он без этой дополнительной SDRAM сможет работать с этим дисплеем хотя бы в текстовом режиме? 

Так и в последующем:

В 15.03.2020 в 13:39, Xenia сказал:

Если создавать буфер под все пиксели этого дисплея, то у STM32F429 внутренней SRAM для этого точно не хватит. Отсюда и мой вопрос - обязательно ли нужно создавать такой большой буфер, чтобы с этим дисплеем работать? А можно спросить и так, как спросила я - можно ли с этим дисплеем работать, не задействуя внешнюю память  IS42S16400J ?

И на счет фабричной демо-программы уже несколько раз говорила - не надо мне ее, не надо! Неужели вы думаете , что я  дура такая тупая, что в демо-программе мне могу их текст на свой "Hello, world" заменить? Тем не менее, несмотря на мои протесты, именно ее мне в нос настойчиво пихают.

 

А про тестовый вывод я вынуждена повторять по другой причине. Потому, что если я этого не скажу, то сразу же заработаю ответ: "Как же вы без буфера на экране будете мультики показывать? Вам без буфера не обойтись! Иначе движения будут прерывистыми". Потому я подчеркиваю, что динамика мне не нужна - если потребуется, то буду хоть целую минуту ждать, пока дисплей мою строку теста выведет, только чтобы только не строить графический образ этой строки (или вместе с ней всего экрана) в SDRAM. Соответственно этому, я и от графических библиотек ожидаю примитивов, которые бы именно на дисплее могли что-то рисовать, а не в памяти SDRAM. Ну, а если дисплей собственных шрифтов не имеет, то хотя бы примитив, позволяющий вывести иконку 8х8 с изображением символа в любое заданное место экрана.

image.png

Share this post


Link to post
Share on other sites
1 hour ago, Xenia said:

Соответственно этому, я и от графических библиотек ожидаю примитивов, которые бы именно на дисплее могли что-то рисовать, а не в памяти SDRAM.

Рисовать в буфере, да ещё и в нескольких слоях - намного приятнее чем перерисовывать все слои программно на самом дисплее. Тем-более что чтение с дисплея за всегда тормозное.

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

Share this post


Link to post
Share on other sites
11 минут назад, AVI-crak сказал:

Тем-более что чтение с дисплея за всегда тормозное.

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

А возможен ли компромиссный вариант: буфер завести, но маленький - только на одну строку текста. И не в SDRAM , а в оперативной памяти (на одну строку текста в ней место найдется). А дальше выводить текст построчно, как раньше DOS в консольном режиме делала :). А если бы этот дисплей умел бы и ранее напечатанный текст вверх сдвигать (чтобы освободить на странице нижнюю строку), то вообще было бы полное счастье :).

Share this post


Link to post
Share on other sites
2 часа назад, Xenia сказал:

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

 

А возможен ли компромиссный вариант: буфер завести, но маленький - только на одну строку текста. И не в SDRAM , а в оперативной памяти (на одну строку текста в ней место найдется). А дальше выводить текст построчно, как раньше DOS в консольном режиме делала :). А если бы этот дисплей умел бы и ранее напечатанный текст вверх сдвигать (чтобы освободить на странице нижнюю строку), то вообще было бы полное счастье :).

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

Глянул на ваш STM32F429I-DISCO - там стоит дисплей с контроллером ILI9341, у него уже есть видеобуфер на всю матрицу, так что рисуйте прямо в него. Внешнее ОЗУ можно не применять.

По поводу маленького буфера только на объект (текст, виджет) - в STemWin есть такие возможности, они их назвали "Memory Devices". Про TouchGFX не знаю, не работал с ним.

Share this post


Link to post
Share on other sites
2 hours ago, Xenia said:

А возможен ли

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

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

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

Share this post


Link to post
Share on other sites
10 часов назад, Baser сказал:

Глянул на ваш STM32F429I-DISCO - там стоит дисплей с контроллером ILI9341, у него уже есть видеобуфер на всю матрицу, так что рисуйте прямо в него. Внешнее ОЗУ можно не применять.

Вот я бы и хотела такую библиотеку, чтобы с ILI9341 не кодами разговаривать, а сразу функциями готовых примитивов. А то микроконтроллеры слушаются меня, а дисплеи нет :). Потому и в эту тему заглянула, что в ней моя плата  STM32F429I-DISCO упоминается и графика для нее обсуждается.

 

 

10 часов назад, AVI-crak сказал:

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

Да, именно режим терминала мне и нужен. Так есть для него что-то готовое или с нуля начинать - даташит на ILI9341 курить? :)

Share this post


Link to post
Share on other sites
В 27.03.2020 в 16:53, mantech сказал:

Так может сербы не для емвина ее делали, а для статических картинок?)))

ЗЫ Хотя пишут -  "represents a perfect solution for any type of multimedia application.

Смешно...

Конечно, сербы плату делали для своих проприетарных библиотек. Там у них много чего есть, и даже работает. Но ни на что не дают исходных кодов, только библиотеки. Я несколько дней убил на разбирательство с их софтом, мне хватило. Глючная IDE с полной завязкой только на фирменные библиотеки. Везде торчат уши пионерско-ардуинского подхода. Ну их нафиг. Еще годится для обучения, для универов и любителей, или для проектов "быстро сляпал лишь бы что - сдал и забыл". Для профессиональной работы - нет.

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

 

Цитата

А чем бы оно тут помогло?

Все-таки так и не понял, как это будет работать без внешней памяти? Дисплей, как понял по иниту - просто матрица без ОЗУ, т.е. если его использовать, то ОЗУ размером X*Y*байты цвета все равно нужно, причем не важно с какой частотой там текст рисовать, раз в сек или 10 раз...

 

Дисплей там подключен через SSD1963. У ней есть видеобуфер на 1.2 МБайта для всей матрицы.
А дополнительного ОЗУ нет, поэтому при перерисовке мигание.
Простейшие кнопки для работы с сенсорным экраном при изменении состояния (при нажимании) мигают.
А какой-нибудь виджет типа вращающегося колеса с цифрами при прокрутке мигает ужасно.
Да и сербский "ногодрыг" привел к тому, что скорость перерисовки экрана только 1-2 раза в секунду.
Для STM32F746ZG  на 200 МГц - это забивание гвоздей микроскопом.
 

12 часов назад, Xenia сказал:

Вот я бы и хотела такую библиотеку, чтобы с ILI9341 не кодами разговаривать, а сразу функциями готовых примитивов. А то микроконтроллеры слушаются меня, а дисплеи нет :). Потому и в эту тему заглянула, что в ней моя плата  STM32F429I-DISCO упоминается и графика для нее обсуждается.

Все-таки я не понял, почему, если у вас уже есть плата с ОЗУ, вы не хотите его использовать. И почему не хотите применить CubeMX, HAL и STemWin.
Там все не так страшно, и все что нужно для работы, есть в виде библиотек. Как вы и хотите. Писать это самостоятельно - вам столько времени начальство не даст.
:acute:

Share this post


Link to post
Share on other sites
12 часов назад, Baser сказал:

И почему не хотите применить CubeMX, HAL и STemWin.

Почему не хочу? Хочу! Вот только SDRAM не хочу использовать. Отсюда и мой вопрос о том, является ли обязательной жертва SDRAM, чтобы пользоваться этим дисплеем. Или в упрощенном/терминальном режиме есть возможность этой жертвы избежать? Вижу, что STemWin требует этой жертвы, потому и тот вопрос, есть ли ей замена под тем же CubeMX/HAL, если требования к графике снизить до минимума.

Share this post


Link to post
Share on other sites
10 часов назад, Baser сказал:

Конечно, сербы плату делали для своих проприетарных библиотек. Там у них много чего есть, и даже работает. Но ни на что не дают исходных кодов, только библиотеки. Я несколько дней убил на разбирательство с их софтом, мне хватило. Глючная IDE с полной завязкой только на фирменные библиотеки.

М..м т.е. с их либами работает нормально... Значит есть какой-то метод, как избежать ногодрыга или бесполезной перерисовки всего экрана. На счет закрытых либ - тут вопрос простой, если они работают правильно, не виснут или тупят по поводу и без - так почему б их не использовать? Емвин-то ведь тоже подобного типа... 

10 часов назад, Baser сказал:

Дисплей там подключен через SSD1963. У ней есть видеобуфер на 1.2 МБайта для всей матрицы.

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

Share this post


Link to post
Share on other sites
15 hours ago, Baser said:

Да и сербский "ногодрыг" привел к тому, что скорость перерисовки экрана только 1-2 раза в секунду.

Да что там за код такой, что так туго работает?

Ногодрыг на stm32f107 - 60 кадров 320*240 : с песнями и танцами.

Ногодрыг для stm32f746 - 60 кадров 480*320 : с песнями, танцами, цыганами и конями.

Если в коде есть лишние слои абстракции, а сам код не имеет чёткого разделения на уровни - то получится аналог швейцарского ножа, у которого есть 100500 лезвий. Такой нож в условиях реального боя просто кидают во врага, он как кирпич лучше работает.

Share this post


Link to post
Share on other sites
9 минут назад, AVI-crak сказал:

Ногодрыг для stm32f746 - 60 кадров 480*320

Дык наверно кроме этого ничего больше не делает прога, да и цвет только 8 бит походу...

Share this post


Link to post
Share on other sites

mantech - В моём понимании ногодрыгом считается всё что не является аппаратным параллельным RGB интерфейсом, или последовательным DSI. В том плане что появляются дополнительные обращения к внешним регистрам девайсов - для управления места, типа операции и данных для изменения. Даже на stm32f107, данные буфера подготовленные для заполнения области экрана - прекрасно переносятся с помощью dma и одного таймера. Кстати без таймера получается лажа - dma работает быстрее возможностей интерфейса экрана.

Не ногодрыг - когда слои графики целиком и полностью находятся в линейной области памяти: с полным аппаратным доступом со стороны процессора, dma, dma2d, и ltdc интерфейса. Линейной области памяти - это значит что не требуется дополнительных программных операций по чтению из внешних накопителей данных, всё имеет свой прямой адрес без взаимного перекрытия.

Share this post


Link to post
Share on other sites
В 28.03.2020 в 02:12, Xenia сказал:

А возможен ли компромиссный вариант: буфер завести, но маленький - только на одну строку текста. И не в SDRAM , а в оперативной памяти (на одну строку текста в ней место найдется). А дальше выводить текст построчно, как раньше DOS в консольном режиме делала :).

Вроде уже и говорили и советовали Вам такое: рисовать в буфере во внутренней ОЗУ по частям и выводить. Но почему то продолжаете перетирать одно и то же. В чём проблема нарисовать строку текста в ОЗУ и вывести её через SPI в этот самый ILI9341? За прошедшее время уже можно было успеть так сделать. Не понимаю проблемы... :unknw:

Share this post


Link to post
Share on other sites
1 час назад, AVI-crak сказал:

В моём понимании ногодрыгом

Это не совсем ногодрыг, тут почти все аппаратно делается, ДМА-передача параллельных данных - это аппаратная передача, а ногодрыг - это программный цикл по которому откуда-нибудь данные перекидываются в порт и программно формируется защелкивание и т.д.

8 минут назад, jcxz сказал:

В чём проблема нарисовать строку текста в ОЗУ и вывести её через SPI

"Так есть для него что-то готовое или с нуля начинать - даташит на ILI9341 курить? :)"

 

А так понимаю, дама хотела все готовое и чтоб сразу работало...:dirol:

Edited by mantech

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this