Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: LTDC + ChromART в STM
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > ARM
Страницы: 1, 2, 3
картошка
Делал на 429 . Запускал режим LUT8, дисплей 800x600. 40 мегабайт видеопотока, заметьте !!! однобайтовый, не перепутал ! Сожрал весь трафик к SDRAM. Осталось там для 3-4 мбайта в секунду, для программы (это из учета что частота SDRAM с максимально скоростной конфигурации получилась то-ли 75 то-ли 85 Мгц в 16-ти битном режиме памяти).
Как по мне - это медленно. Попутно запустил камеру на OV - чипе, настроил на внутреннюю оперативку, а так как ее мало было для полного растра пришлось весь кадр перегружать за 3-4 физических кадра + еще и каждую точку с 565 режима камеры в 8бит переделывал sm.gif .

729 - много не выправит. С такими потребностями и хваткой надо на ALLWINER-ы переходить. Но там одна только загвоздка и она ключевая, надо изучить команды MALI архитекруты sm.gif.
Шаманъ
Цитата(картошка @ Apr 7 2016, 18:20) *
Делал на 429 . Запускал режим LUT8, дисплей 800x600. 40 мегабайт видеопотока, заметьте !!! однобайтовый, не перепутал !

40*2^20/(800*600)=87.38 к/с - зачем столько?

Цитата(картошка @ Apr 7 2016, 18:20) *
729 - много не выправит.

479й с 32битной SDRAM будет намного полезнее в этом плане
SpyBot
Цитата(Шаманъ @ Apr 7 2016, 20:27) *
40*2^20/(800*600)=87.38 к/с - зачем столько?

Какие то дисплеи на небольшой частоте подмерцывают, что крайне отрицательно сказывается на усталости глаз.
Я пробовал разгонять правда 320х240 до 150 и более фпс, от этого восприятие картинки только улучшалось.
Но это мерцание не все видят. У меня вот какое то обостренное чувство к мерцанию подсветки и матрицы любых дисплеев. А коллеги замечают мерцание только наверное на 25 фпс sm.gif
Цитата(Шаманъ @ Apr 7 2016, 20:27) *
479й с 32битной SDRAM будет намного полезнее в этом плане

А при 1 байтном цвете, будет ли чтение одновременно 4 точек из сдрам?
Также и при например записи с ацп. Сможет ли он записывать в сдрам одновременно 4 отсчета?
niXto
Цитата(SpyBot @ Apr 11 2016, 19:47) *
Какие то дисплеи на небольшой частоте подмерцывают, что крайне отрицательно сказывается на усталости глаз.
Я пробовал разгонять правда 320х240 до 150 и более фпс, от этого восприятие картинки только улучшалось.


Почитайте про tearing effect и два способа минимизации последствий

Достаточно 25...30 кадров в секунду, но синхронизированных с развёрткой
Шаманъ
Цитата(SpyBot @ Apr 11 2016, 19:47) *
Какие то дисплеи на небольшой частоте подмерцывают, что крайне отрицательно сказывается на усталости глаз.

Очень часто мерцание возникает из-за ШИМ управления подсветкой. Если частоты неудачно выбраны, то может получаться форменная порнография. Потому у себя всегда управляю подсветкой регулировкой преобразователя, а не низкочастотным ШИМом.

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

Цитата
А при 1 байтном цвете, будет ли чтение одновременно 4 точек из сдрам?
Также и при например записи с ацп. Сможет ли он записывать в сдрам одновременно 4 отсчета?

Ну если память 32бита, то читать и записывать 4байта за раз это как бы ее прямое назначение sm.gif

LTDC тоже должен работать с памятью 32битными словами. К сожалению 479е у нас не продаются, потому что-то более определенное сказать не смогу.
SpyBot
Цитата(Шаманъ @ Apr 11 2016, 21:32) *
Очень часто мерцание возникает из-за ШИМ управления подсветкой. Если частоты неудачно выбраны, то может получаться форменная порнография. Потому у себя всегда управляю подсветкой регулировкой преобразователя, а не низкочастотным ШИМом.

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

Подсветка всегда питается постоянным напряжением, шим я категорически неприемлю.
Речь идет о полностью статической картинке.
Попробуйте постепенно снижать частоту LTDC и на каком то этапе станет видно, что картинка немного мерцает и к тому же сильно напрягаются глаза.
Еще один момент, что на углах обзора градусов так 45 видно, как особенно сильно мерцают горизонтальные темные линии.
У меня частота LTDC при которой картинка становится более менее комфортной - не менее 50 МГц для 320х240.
aaarrr
Цитата(SpyBot @ Apr 11 2016, 23:53) *
Еще один момент, что на углах обзора градусов так 45 видно, как особенно сильно мерцают горизонтальные темные линии.

Судя по описанию, это похоже на неправильно выставленный или шумный источник VCOM. Характерно для дешевых индикаторов.

Цитата(SpyBot @ Apr 11 2016, 23:53) *
У меня частота LTDC при которой картинка становится более менее комфортной - не менее 50 МГц для 320х240.

А у индикатора какая максимальная допустимая частота PCLK?
SpyBot
Цитата(aaarrr @ Apr 12 2016, 00:04) *
А у индикатора какая максимальная допустимая частота PCLK?

30 MHz, но он на удивление работает и с гораздо большей частотой. Да, это очень дешевый дисплей sm.gif
При больших фпс начинают даже плыть цвета, но синхронизацию он не теряет.
SasaVitebsk
Цитата(SpyBot @ Apr 11 2016, 23:53) *
Подсветка всегда питается постоянным напряжением, шим я категорически неприемлю.

Почему? Поясните, пожалуйста.

Цитата(SpyBot @ Apr 11 2016, 19:47) *
А при 1 байтном цвете, будет ли чтение одновременно 4 точек из сдрам?
Также и при например записи с ацп. Сможет ли он записывать в сдрам одновременно 4 отсчета?

С точки зрения CPU, вы будете читать 32 бита. То есть 4 отсчёта/ точки. Как будет обеспечиваться ваше чтение, зависит от схемотехники.
На найболее распростанённых схемах, применена 16 битная SDRAM (дешёвая и легко разводится). В этом случае ваше обращение к 32-ух битному слову выльется в 2 обращения к ОЗУ. В каждом случае будут вставлены определённые такты ожидания. Иными словами, с точки зрения CPU обращение к внешней памяти осуществляется также как к внутренней, но операции чтения/ записи выполняются медленнее.
Есть ещё регенерация. Насколько прозрачно она выполняется я не смотрел. Думаю, что сейчас контроллеры динамической памяти уже вполне отработаны, и регенерация осуществляется прозрачно (то есть процессор значимо не тормозится, при выполнении регенерации).
Шаманъ
Цитата(SpyBot @ Apr 11 2016, 23:53) *
У меня частота LTDC при которой картинка становится более менее комфортной - не менее 50 МГц для 320х240.

Ого! У меня на 320х240 6.4МГц помнится и все абсолютно нормально. Притом вначале ошибся и он также нормально довольно долго работал на частоте в два раза меньше. Экран правда не из самых дешевых.

Цитата(SasaVitebsk @ Apr 12 2016, 09:18) *
Почему? Поясните, пожалуйста.

Мерцает подсветка, мерцает сам экран с разными частотами когда одно накладывается на другое могут быть очень прикольные эффекты, даже если ШИМ синхронизирован с экраном sm.gif Потому лучше управлять преобразователем питания подсветки без ШИМа, тем более почти все преобразователи отлично управляются путем корректировки напряжения ОС регулятора. Вот так:
Нажмите для просмотра прикрепленного файла
SasaVitebsk
Спасибо.
Но вроде как для светодиодов глубоко по барабану частота. Они от этого не умирают. То есть можно частоту ШИМ и 100 и 200 кГц применить. Таймер с такой ерундой вполне справится. В чём подвох?
aaarrr
Цитата(SasaVitebsk @ Apr 12 2016, 10:40) *
В чём подвох?

На EN источника такую частоту подать не получится.
SpyBot
Цитата(SasaVitebsk @ Apr 12 2016, 09:29) *
Почему? Поясните, пожалуйста.

У меня видимо какие то слабоватые глаза и я очень мучаюсь с разными мониторами. А со временем в мониторы ставят все более и более мощные диоды и ситуация становится просто невыносимой sm.gif Я как то купил ноут, несколько дней посмотрел в него на минимальной яркости и потом какое то время мог только читать электронную книгу.
Ну и по логике, даже если сознание человека этого почти не фиксирует, как то глупо пыхать в глаза с полностью открытым зрачком (вечером) всей дурью сверхярких светодиодов.

Цитата(SasaVitebsk @ Apr 12 2016, 09:29) *
С точки зрения CPU, вы будете читать 32 бита. То есть 4 отсчёта/ точки. Как будет обеспечиваться ваше чтение, зависит от схемотехники.
На найболее распростанённых схемах, применена 16 битная SDRAM (дешёвая и легко разводится). В этом случае ваше обращение к 32-ух битному слову выльется в 2 обращения к ОЗУ. В каждом случае будут вставлены определённые такты ожидания. Иными словами, с точки зрения CPU обращение к внешней памяти осуществляется также как к внутренней, но операции чтения/ записи выполняются медленнее.
Есть ещё регенерация. Насколько прозрачно она выполняется я не смотрел. Думаю, что сейчас контроллеры динамической памяти уже вполне отработаны, и регенерация осуществляется прозрачно (то есть процессор значимо не тормозится, при выполнении регенерации).

В теории это все понятно, но вот как будет работать конкретный МК, пока не ясно. В идеале конечно же хотелось бы, чтобы МК умел использовать burst как для чтения так и для записи. Даже если изначальный поток например с ацп идет 8 бит...
AVI-crak
Вся разница в 16 и 32 бита шины sdram на st чипе - буквально 2 тика.
Латетность совершенно одинаковая, и составляет в лучших вариантах 10 тик + 2 тика первое чтение. Попав на потоковое чтение выбранной страницы - чтение/запись будет без выборки адреса.
У ускорителя st производится непрерывная предвыборка в половину буфера - это 8/16 32d слов. По сему разница в скорости от ширины памяти не столь заметна.
Максимальная скорость достигается при использовании внешней sram памяти, очень желательно на 10nc.
У st есть макетки с использованием такой памяти, но чего-то они не прижились - ценник ломовой.
Шаманъ
Цитата(AVI-crak @ Apr 14 2016, 11:46) *
У ускорителя st производится непрерывная предвыборка в половину буфера - это 8/16 32d слов. По сему разница в скорости от ширины памяти не столь заметна.

По сему как раз разница между 16 и 32 битными шинами будет очень приличной sm.gif Или Вы про что-то другое?

Передача адреса со всеми "попутными" расходами времени будет производится один раз на блок, затем данные в пределах блока будут вычитываться каждый такт SDRAM. Соответственно если вариант с 16битной SDRAM требует t1+t2 времени, где t1 - время требуемое для выборки, t2 собственно для чтения данных, то в случае с 32бит SDRAM потребуется t1+t2/2. Как по мне это весьма существенно.

Цитата(SpyBot @ Apr 14 2016, 03:43) *
как то глупо пыхать в глаза с полностью открытым зрачком (вечером) всей дурью сверхярких светодиодов.

Да, поддерживаю Вас в этом плане, но в данном случае все намного проще. С высокой частотой ШИМа импульсный стабилизатор тока светодиодов просто не будет успевать нормально стартовать sm.gif
SpyBot
Цитата(AVI-crak @ Apr 14 2016, 11:46) *
У st есть макетки с использованием такой памяти, но чего-то они не прижились - ценник ломовой.

Это и понятно. Грубо говоря, быстрая малопотребляющая (относительно других) SRAM нормального объема стоит как дискавери с 4-5" экранчиком...
AVI-crak
Цитата(Шаманъ @ Apr 14 2016, 15:56) *
По сему как раз разница между 16 и 32 битными шинами будет очень приличной sm.gif Или Вы про что-то другое?

Сухие цифры: самый не оптимальный режим - 2 слоя, запись в буфер, и его-же отображение на rgb выхлопе - пред выборка по 8 32b слов.
8 бит: адрес 10 тиков + 64 тика на чтение = 72 тика на заполнение буфера.
16 бит: адрес 10 тиков + 32 тика на чтение = 42 тика на заполнение буфера.
32бит: адрес 10 тиков + 16 тиков на чтение = 26 тика на заполнение буфера.
32бит sram 10nc: 2 тика на чтение = 16 тиков на буфер из восьми выборок.

Разница в скорости между 16b и 32b - 1,6, до двойки не дотягивает - зато освобождает сражу 16 линий мк.
А вот для sram уже не жалко все 32b выделить, и даже махнуть рукой на прожорливость системы. Потому как скорость чтения/записи практически равна скорости выборки из внутренней sram (необходимость каждый раз качать права на шине арбитра - 1 такт).

Но вот из всего многообразия современной и быстрой sram памяти 10nc - самая дешёвая на 8 метров имеет ценник в 3 бакса, и не совсем гуманный бга корпус.
А ценник на 64 метра - просто улетают в космос, получается в сто раз дешевле поставить 8 восмиметровых чипов.
mantech
Цитата(AVI-crak @ Apr 14 2016, 19:50) *
Сухие цифры: самый не оптимальный режим - 2 слоя, запись в буфер, и его-же отображение на rgb выхлопе - пред выборка по 8 32b слов.
8 бит: адрес 10 тиков + 64 тика на чтение = 72 тика на заполнение буфера.
16 бит: адрес 10 тиков + 32 тика на чтение = 42 тика на заполнение буфера.
32бит: адрес 10 тиков + 16 тиков на чтение = 26 тика на заполнение буфера.
32бит sram 10nc: 2 тика на чтение = 16 тиков на буфер из восьми выборок.
овых чипов.


Вы какое хоть разрешение экрана используете? Проверял на 2х ядерном LPC(не помню номер его) до 640х480 все работало без тормозов, а выше при использовании сд-рам - это все равно, что эзернет программный делать biggrin.gif
AVI-crak
Цитата(mantech @ Apr 15 2016, 01:02) *
Вы какое хоть разрешение экрана используете? Проверял на 2х ядерном LPC(не помню номер его) ...


Внешняя sdram с безграничным презрением смотрит на любой чип рядом с собой - она не будет работать быстрее чем записано в её доке.
Для описания скорости "работы" nad памяти - у меня не хватит ругательных слов.

Лично я жду доступную оптическую память на кристаллах. Уже наверное скоро изобретут.
Огурцов
какой интерес считывать из внешнего озу в мк, чтобы тут же выдавать обратно наружу
память уже добавили - добавьте ещё и защёлку-другую для данных и гоните их сразу на дисплей
Шаманъ
Цитата(Огурцов @ Apr 14 2016, 23:52) *
какой интерес считывать из внешнего озу в мк, чтобы тут же выдавать обратно наружу
память уже добавили - добавьте ещё и защёлку-другую для данных и гоните их сразу на дисплей

Какой смысл что-то ставить снаружи и как-то это синхронизировать с записью/чтением данных от МК (типа арбитр городить), если все уже изобретено и есть в МК?

Цитата(AVI-crak @ Apr 14 2016, 19:50) *
Разница в скорости между 16b и 32b - 1,6, до двойки не дотягивает - зато освобождает сражу 16 линий мк.

469й позволяет подключать дисплей по последовательной шине - там столько пинов освобождается, что можно и память до 32х бит нарастить и еще останется sm.gif А в 1.6раза согласитесь, это не мало.

Цитата
А вот для sram уже не жалко все 32b выделить, и даже махнуть рукой на прожорливость системы.

Кто б спорил, но цена/потребление, да и доступность больших чипов SRAM сразу делает такое решение неприемлемым, ну или как минимум не привлекательным...
mantech
Цитата(Огурцов @ Apr 14 2016, 23:52) *
какой интерес считывать из внешнего озу в мк, чтобы тут же выдавать обратно наружу
память уже добавили - добавьте ещё и защёлку-другую для данных и гоните их сразу на дисплей


Если считаете, что там все так просто - берите ПЛИСу и делайте biggrin.gif
Огурцов
не надо плиску, с плиской может и стм не потребоваться


Цитата(Шаманъ @ Apr 15 2016, 07:53) *
469й позволяет подключать дисплей по последовательной шине

а вот это мегаинтересно
SpyBot
Цитата(Шаманъ @ Apr 15 2016, 10:53) *
Кто б спорил, но цена/потребление, да и доступность больших чипов SRAM сразу делает такое решение неприемлемым, ну или как минимум не привлекательным...

Мне кажется, что пока требуется просто использовать память под видеобуфер, SDRAM будет лучшим решением. Но как только появляется необходимость в обработке, допустим, второй картинки, здесь уже нужно брать SRAM.
Огурцов
а сколько надо ? внутренней уже вполне хватает на кое-что
SpyBot
Нет, ну внутренней... Внутренней хватает всего на 320х240. А хочется Размаха! sm.gif 1024х768 и несколько буферов.
Огурцов
на 720*575 хватает
Шаманъ
Цитата(Огурцов @ Apr 16 2016, 10:14) *
а сколько надо ? внутренней уже вполне хватает на кое-что

Мне нужно 1.5МБ на фреймбуффер минимум. Если поиграться с прозрачностью, то еще столько же sm.gif

Цитата(Огурцов @ Apr 16 2016, 17:47) *
на 720*575 хватает

Это в каком STM есть 400кБ памяти? Да и то при восьмибитном цвете и если в памяти больше ничего кроме видеобуфера нет.
Огурцов
семисотые посмотрите
более 800*600 на встраиваемых, зачем ?
на писюках как-то вполне 640*480*4 перебивались, а 800*600*8 появились - вообще праздник, так что не жадничайте
Шаманъ
Цитата(Огурцов @ Apr 16 2016, 22:02) *
семисотые посмотрите

Те, что реально доступны имеют 320кБ на борту.

Цитата
более 800*600 на встраиваемых, зачем ?

Нет, не более, а 800х480х16бит + двойная буферизация. А если еще в два слоя то 3МБ и набегает, правда последнее в общем-то не самая нужная вещь, но кое-что в интерфейсе позволяет сделать красиво без лишних усилий.

Цитата
на писюках как-то вполне 640*480*4 перебивались, а 800*600*8 появились - вообще праздник, так что не жадничайте

Во-первых у меня задача требует минимум 8битного цвета, но лучше выглядит в 16битном. Некоторую информацию удобно/необходимо отображать в виде двух координат X-Y, а третья координата это цвет (думаю я не уникален в этом).
Во-вторых эффективно использовать DMA2D можно только с 16битным фреймбуффером.
AVI-crak
Кстати, у чипов st их ускоритель имеет всего две полезные функции: заливка цветом и копирование памяти с прозрачностью. Именно для последней функции требуется огромное количество памяти, иначе теряется смысл dma2d.
Тут встроенной памятью не обойтись.
Шаманъ
Цитата(AVI-crak @ Apr 17 2016, 10:06) *
Кстати, у чипов st их ускоритель имеет всего две полезные функции: заливка цветом и копирование памяти с прозрачностью.

Та не, больше функций - есть еще копирование с преобразованием цвета. Оно позволяет выводить шрифты и хранить картинки в сжатом (в смысле индексированный цвет) виде. Я прикидывал - все, что мне нужно могу делать через DMA2D. Если бы оно еще умело разворачивать монохромные битмапы было бы просто супер, а с другой стороны потратить на шрифты в четыре раза больше флэша не есть глобальная проблема.
Огурцов
Цитата(Шаманъ @ Apr 17 2016, 04:38) *
двойная буферизация

ну поставьте два процыка
или подождите пару лет, до какой-нибудь 9xx
Шаманъ
Цитата(Огурцов @ Apr 17 2016, 11:33) *
ну поставьте два процыка
или подождите пару лет, до какой-нибудь 9xx

Зачем? Два процессора для двойной буферизации вывода графики maniac.gif У Вас какие-то нездоровые идеи, то от LTDC отказаться, то от SDRAM... Если полосы SDRAM хватает, то пусть себе стоИт - стОит копейки, памяти много...
Огурцов
у меня разные идеи - а вы выбираете
Шаманъ
Цитата(Огурцов @ Apr 17 2016, 21:13) *
у меня разные идеи - а вы выбираете

Не, спасибо, у меня своих достаточно...
adrvyho
Добрый день, дорогие форумчане.
Тоже решил идти в ногу со временем и пересесть с AVR на STM32.
Подключил сенсорный дисплей 800х480 по интерфейсу RGB24 к STM32F429IIT.
Но от того, что поспешил и не предусмотрел в своей схеме SDRAM, теперь мучаюсь.
Настроил тайминги, залил задний фон, активировал слой и окно на нём, но никак не выходит корректно залить область внутри окна.
Получается примерно следующее:



Заливать пробую через DMA2D Register to memory.
Краями, конечно, понимаю, что что-то неверно с адресом заливаемой области, но от неграмотности не могу совладать с DMA2D
Прошу помощи у тех, кто может совладать с DMA2D без SDRAM
Вот кусок кода для заливки

Код
static void _DMA_Fill(void * pDst, int xSize, int ySize, int OffLine, uint32_t ColorIndex) {

  DMA2D->CR      = 0x00030000UL | (1 << 9);         // Register to memory and TCIE
  DMA2D->OCOLR   = ColorIndex;                      // Color to be used
  DMA2D->OMAR    = (uint32_t)pDst;                       // Destination address
  DMA2D->OOR     = OffLine;                         // Destination line offset
  DMA2D->OPFCCR  = 4;                     // Defines the number of pixels to be transfered
  DMA2D->NLR     = ((uint32_t)xSize << 16) | ySize; // Size configuration of area to be transfered
  DMA2D->CR     |= 1;                               // Start operation
  //
  // Wait until transfer is done
  //
  while (DMA2D->CR & DMA2D_CR_START) {}
}
uint32_t aBufferResult[5000];

int main (void)
    

{
          SystemInit();
      HAL_Init();
          SystemClock_Config();
      DMA2D_Config();
      Screen_Init();
          _DMA_Fill(aBufferResult+10, 50, 1, 0, 0x1F0A);
          _DMA_Fill(aBufferResult+150, 30, 2, 0, 0x1C01);
      _DMA_Fill(aBufferResult+300, 5, 20, 0, 0xF0F0);
          while(1) {}
}

Шаманъ
Цитата(adrvyho @ Aug 22 2016, 17:39) *
Подключил сенсорный дисплей 800х480 по интерфейсу RGB24 к STM32F429IIT.
Но от того, что поспешил и не предусмотрел в своей схеме SDRAM, теперь мучаюсь.

Так а видеобуфер где поместился?

Цитата
Заливать пробую через DMA2D Register to memory.

Я бы вначале убедился, что без DMA2D все работает правильно, а потом уже подключал DMA2D.
adrvyho
В видеобуфере, так подозреваю, моя проблема и кроется, только от того, что я самоучка и много не знаю, пока не могу понять, где именно.
Я так понял, что адрес буфера, при отсутствии внешней ОЗУ - адрес массива aBufferResult, но это только мои мутные догадки.
Без DMA2D я менял цвет заднего фона, поигрался со слоями, залил на слое 1 окно нужного размера - предположил, что экран рабочий и подключен правильно biggrin.gif
Активировал DMA2D (проверил в отладчике регистры), нашёл удобоваримый пример для режима Register-To_memory, пытаюсь вывести три разных прямоугольника, а получается то, что видим на фотографии ((
Шаманъ
Цитата(adrvyho @ Aug 22 2016, 19:05) *
Я так понял, что адрес буфера, при отсутствии внешней ОЗУ - адрес массива aBufferResult, но это только мои мутные догадки.

Ищите где производится инициализация LTDC и смотрите где находится видеобуфер - для меня из Вашего куска кода совсем не очевидно, что aBufferResult это видеобуфер (его размер как бы должен быть побольше раз в двадцать как минимум), короче "Use the source luke" wink.gif
Rash
без SDRAM или SRAM нужного размера под видео буфер не имеет практического смысла запускать
adrvyho
Цитата
без SDRAM или SRAM нужного размера под видео буфер не имеет практического смысла запускать

Необходимо выводить только примитивы в виде кнопок и текст. Хотя убийственная мысль, что на каждый пиксель экрана необходимо минимум два байта постоянно перезаписываемой памяти, всё больше проникает в мозг. Может есть какие-то уловки с FLASH или SD картой, или ещё какие-то заклинания?!

Цитата
Ищите где производится инициализация LTDC и смотрите где находится видеобуфер


Единственное указание на видеобуфер находится в инициализации слоя 1, пока что-то делать с ним боюсь, только расширил массив до 45000,но это - мёртвому припарки.
Код
   displayLayer1.WindowX0 = 10;
   displayLayer1.WindowX1 = 790;
   displayLayer1.WindowY0 = 10;
   displayLayer1.WindowY1 = 470;
   displayLayer1.PixelFormat = LTDC_PIXEL_FORMAT_ARGB4444;
   displayLayer1.Alpha = 255;
   displayLayer1.Alpha0 = 250;
   displayLayer1.BlendingFactor1 = LTDC_BLENDING_FACTOR1_CA;
   displayLayer1.BlendingFactor2 = LTDC_BLENDING_FACTOR2_CA;
   displayLayer1.FBStartAdress = (uint32_t)&aBufferResult;
   displayLayer1.ImageWidth = 0;
   displayLayer1.ImageHeight = 0;
   displayLayer1.Backcolor.Blue = 250;
   displayLayer1.Backcolor.Green = 0;
   displayLayer1.Backcolor.Red = 200;

   HAL_LTDC_ConfigLayer(&displayTypeDef, &displayLayer1, 0);


Rash
под ваш LCD нужен видео буфер 800*480*2 иначе просто нет смысла возится (ИМХО). Или переходите на маленький экран, что бы разместить видео буфер во внутреннем ОЗУ. Самый менее затратный вариант взять 429Disco, отпаять родной LCD и сделать переходную плату под нужный LCD, а потом уже разводить свою, при рабочем программе (или готовый DevKit).
SasaVitebsk
Цитата(adrvyho @ Aug 22 2016, 23:51) *
Необходимо выводить только примитивы в виде кнопок и текст. Хотя убийственная мысль, что на каждый пиксель экрана необходимо минимум два байта постоянно перезаписываемой памяти, всё больше проникает в мозг. Может есть какие-то уловки с FLASH или SD картой, или ещё какие-то заклинания?!

Вы бы почитали мой пост предварительно. Тогда бы поняли что DMA2D целесообразен только в режиме 16 или 24-битного цвета.
...
Давайте поясню на пальцах. В МК есть 2 совершенно независимых узла: LTDC (контроллер дисплея) и DMA2D (ускоритель, но фактически контроллер прямого доступа к памяти позволяющий работать с прямоугольными областями памяти).
LTDC фактически отображает область памяти (видеобуфер) на экран. А с помощью DMA2D вы можете модифицировать ваш видеобуфер. То есть сам DMA2D к дисплею никакого отношения не имеет. Поскольку в экране у вас ничего не хранится, то видеобуфер должен быть обязательно. Там находится то, что отображается на дисплее.
Самый экономный режим для вашего МК - 8 бит (L8 - 256 цветов из палитры 16 бит или аналогичный AL44 - палитра 16 цветов с 16 градациями яркости). Для реализации потребуется 800*480 = 384 кб. У Вашего контроллера лишь 256.
Выхода 3.
1) Добавить память внешнюю. Но на проводах не запаяешь. Работать не будет. Придётся переразводить плату.
2) Применить дисплей с меньшим разрешением. Например 4.3" 480*272 = 130кб. Качество картинки будет описанное выше. DMA2D будет использоваться ограниченно (только копирование и заливка).
3) Применить дисплей с собственным контроллером типа 1963 или другим. Там память находится на самом дисплее. DMA2D в этом случае теряет смысл.
adrvyho
Всем спасибо большое за ответ!!!
Понял всю фатальность ситуации, что запуск моей платы снова отодвинут на этап создания паттернов в PCAD.
Для себя на пальцах представил ОЗУ, как участок земли определённой площади, которым я обладаю (в моём случае - 256 кв. м).
Видеобуфер - это полотно, которое я могу расстелить в пределах моего участка. Полотно, зараза, большое.
Пиксели - это кубики с площадью основания >= 2 кв.м.
И чтобы мне расстелить полотно, нужно купить участок побольше, можно и в другом районе, дабы курьерская служба DMA2D может доставить кубики-пиксели куда угодно)
Уважаемый SasaVitebsk, я ведь в случае варианта 2 могу не брать другой экран, а на своём задать область размером, допустим 400х300 на слое 1? Или нужно вначале инициализировать экран конкретно под это разрешение?
Пока не выходит, хотя создал uint16_t aBufferResult[95000] (больше не создаётся). Может нужно как-то по-другому задавать видеобуфер? Тут мои знания уже конкретно плывут(

SasaVitebsk
В доке на МК имеется достаточно детальное описание как программируется дисплей.
Вы сможете слегка уменьшить отображаемое поле. Но в целом, TFT дисплей это всё же не телевизор и поля с краёв будут небольшими.
То есть я думаю вас это не спасёт. Хотя я не пробовал, честно скажу.
adnega
Цитата(adrvyho @ Aug 24 2016, 19:43) *
а на своём задать область размером, допустим 400х300 на слое 1? Или нужно вначале инициализировать экран конкретно под это разрешение?

Нужно проинициализировать экран со всеми таймингами под полное разрешение,
но при инициализации слоев (а именно они используют видеопамять) можно указать буфера меньшего размера.
Границы будут залиты цветом фона, который можно выбрать.
Можно один из слоев натравить на ПЗУ, тогда будет выводится статический логотип к примеру.
Можно попробовать анимировать этот логотип, перезависывая адрес начала видеобуфера синхронно с ходом луча sm.gif

PS. Я так делал - работает, но при определенных соотношениях размеров.
adrvyho
Цитата(adnega @ Aug 25 2016, 09:27) *
Нужно проинициализировать экран со всеми таймингами под полное разрешение,
но при инициализации слоев (а именно они используют видеопамять) можно указать буфера меньшего размера.
Границы будут залиты цветом фона, который можно выбрать.


Именно так и сделал - задал массив aBufferResult при инициализации слоя 1, сделал заполнение 2х областей. Дык, всё равно заливаются линии, а не области!


Видимо, прокладка между рулём и сиденьем износилась)
Подскажите, пожалуйста, как корректно задать видеобуфер - видимо я это совсем через пень-колоду делаю.

adnega
Цитата(adrvyho @ Aug 25 2016, 18:00) *
Именно так и сделал

Кусок кода покажете?
adrvyho
Цитата(adnega @ Aug 25 2016, 15:27) *
Кусок кода покажете?

CODE
#define PIXELWIDHT 2

#define LCD_WIDTH 800
#define LCD_HEIGHT 480

#define HFP 40
#define HSYNC 48
#define HBP 40

#define VFP 13
#define VSYNC 3
#define VBP 29



#define ACTIVE_W (HSYNC + LCD_WIDTH + HBP - 1)
#define ACTIVE_H (VSYNC + LCD_HEIGHT + VBP - 1)
#define DISP_ACCUM_HORIZ_BACKPORCH (HSYNC + HBP - 1)
#define DISP_ACCUM_VERT_BACKPORCH (VSYNC + VBP - 1)
#define TOTAL_WIDTH (HSYNC + HBP + LCD_WIDTH + HFP - 1)
#define TOTAL_HEIGHT (VSYNC + VBP + LCD_HEIGHT + VFP - 1)

uint16_t aBufferResult[95000];

void Screen_Init(void)
{
LTDC_HandleTypeDef displayTypeDef;
LTDC_LayerCfgTypeDef displayLayer1;
LTDC_LayerCfgTypeDef displayLayer2;

GPIO_InitStruct.Pin = GPIO_PIN_4|GPIO_PIN_5| GPIO_PIN_6|GPIO_PIN_12|GPIO_PIN_13|GPIO_PIN_14|GPIO_PIN_15;
GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
GPIO_InitStruct.Pull = GPIO_NOPULL;
GPIO_InitStruct.Speed = GPIO_SPEED_HIGH;
GPIO_InitStruct.Alternate = 14;

HAL_GPIO_Init(GPIOE, &GPIO_InitStruct);

GPIO_InitStruct.Pin = GPIO_PIN_10| GPIO_PIN_11;

HAL_GPIO_Init(GPIOG, &GPIO_InitStruct);

GPIO_InitStruct.Pin = GPIO_PIN_0|GPIO_PIN_1| GPIO_PIN_2|GPIO_PIN_4|GPIO_PIN_5|GPIO_PIN_6|GPIO_PIN_7|GPIO_PIN_9|GPIO_PIN_10;

HAL_GPIO_Init(GPIOI, &GPIO_InitStruct);

GPIO_InitStruct.Pin = GPIO_PIN_2|GPIO_PIN_3| GPIO_PIN_8|GPIO_PIN_9|GPIO_PIN_10|GPIO_PIN_11|GPIO_PIN_12|GPIO_PIN_13|GPIO_PIN_1
4|GPIO_PIN_15;

HAL_GPIO_Init(GPIOH, &GPIO_InitStruct);

GPIO_InitStruct.Pin = GPIO_PIN_12;
GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP;
GPIO_InitStruct.Pull = GPIO_NOPULL;
GPIO_InitStruct.Speed = GPIO_SPEED_HIGH;

HAL_GPIO_Init(GPIOE, &GPIO_InitStruct);

HAL_GPIO_WritePin(GPIOE, GPIO_PIN_12, 1);

__LTDC_CLK_ENABLE();

// PLL

/* LCD clock configuration */
/* PLLSAI_VCO Input = HSE_VALUE/PLL_M = 1 MHz */
/* PLLSAI_VCO Output = PLLSAI_VCO Input * PLLSAIN = 192 MHz */
/* PLLLCDCLK = PLLSAI_VCO Output/PLLSAIR = 192/5 = 38.4 MHz */
/* LTDC clock frequency = PLLLCDCLK / LTDC_PLLSAI_DIVR_4 = 38.4/4 = 9.6MHz */
PeriphClkInitStruct.PeriphClockSelection = RCC_PERIPHCLK_LTDC;
PeriphClkInitStruct.PLLSAI.PLLSAIN = 192;
PeriphClkInitStruct.PLLSAI.PLLSAIR = 5;
PeriphClkInitStruct.PLLSAIDivR = RCC_PLLSAIDIVR_4;
HAL_RCCEx_PeriphCLKConfig(&PeriphClkInitStruct);

// enable clock for LTDC
RCC->APB2ENR |= RCC_APB2ENR_LTDCEN;

// LTDC
HAL_LTDC_Init(&displayTypeDef);
displayTypeDef.Instance = LTDC;
displayTypeDef.Init.HSPolarity = LTDC_HSPOLARITY_AL;
displayTypeDef.Init.VSPolarity = LTDC_VSPOLARITY_AL;
displayTypeDef.Init.DEPolarity = LTDC_DEPOLARITY_AL;
displayTypeDef.Init.PCPolarity = LTDC_PCPOLARITY_IPC;
displayTypeDef.Init.HorizontalSync = HSYNC-1;
displayTypeDef.Init.VerticalSync = VSYNC-1;
displayTypeDef.Init.AccumulatedHBP = DISP_ACCUM_HORIZ_BACKPORCH;
displayTypeDef.Init.AccumulatedVBP = DISP_ACCUM_VERT_BACKPORCH;
displayTypeDef.Init.AccumulatedActiveW = ACTIVE_W;
displayTypeDef.Init.AccumulatedActiveH = ACTIVE_H;
displayTypeDef.Init.TotalWidth = TOTAL_WIDTH;
displayTypeDef.Init.TotalHeigh = TOTAL_HEIGHT;
displayTypeDef.Init.Backcolor.Blue = 200;
displayTypeDef.Init.Backcolor.Green = 0;
displayTypeDef.Init.Backcolor.Red = 200;

HAL_LTDC_Init(&displayTypeDef);

// Layer 1
displayLayer1.WindowX0 = 210;
displayLayer1.WindowX1 = 590;
displayLayer1.WindowY0 = 100;
displayLayer1.WindowY1 = 380;
displayLayer1.PixelFormat = LTDC_PIXEL_FORMAT_ARGB4444;
displayLayer1.Alpha = 255;
displayLayer1.Alpha0 = 250;
displayLayer1.BlendingFactor1 = LTDC_BLENDING_FACTOR1_CA;
displayLayer1.BlendingFactor2 = LTDC_BLENDING_FACTOR2_CA;
displayLayer1.FBStartAdress = (uint32_t)&aBufferResult;
displayLayer1.ImageWidth = 0;
displayLayer1.ImageHeight = 0;
displayLayer1.Backcolor.Blue = 250;
displayLayer1.Backcolor.Green = 0;
displayLayer1.Backcolor.Red = 200;

HAL_LTDC_ConfigLayer(&displayTypeDef, &displayLayer1, 0);

}

static void DMA2D_Config(void)
{
__HAL_RCC_DMA2D_CLK_ENABLE();
/* Register to memory mode with ARGB4444 as colorMode */
Dma2dHandle.Init.Mode = DMA2D_R2M;
Dma2dHandle.Init.ColorMode = DMA2D_ARGB4444;
Dma2dHandle.Init.OutputOffset = 0x0;

Dma2dHandle.XferCpltCallback = TransferComplete;
Dma2dHandle.XferErrorCallback = TransferError;
Dma2dHandle.Instance = DMA2D;

/* DMA2D Initialization */
if(HAL_DMA2D_Init(&Dma2dHandle) != HAL_OK)
{

}
}

static void _DMA_Fill(void * pDst, int xSize, int ySize, int OffLine, uint32_t ColorIndex) {

DMA2D->CR = 0x00030000UL | (1 << 9); // Register to memory and TCIE
DMA2D->OCOLR = ColorIndex; // Color to be used
DMA2D->OMAR = (uint32_t)pDst; // Destination address
DMA2D->OOR = OffLine; // Destination line offset
DMA2D->OPFCCR = 4; // Defines the number of pixels to be transfered
DMA2D->NLR = ((uint32_t)xSize << 16) | ySize; // Size configuration of area to be transfered
DMA2D->CR |= 1; // Start operation
//
// Wait until transfer is done
//
while (DMA2D->CR & DMA2D_CR_START) {
//__WFI(); // Sleep until next interrupt
}


Код
_DMA_Fill(aBufferResult+10, 10, 10, 0, 0x1F0A);
_DMA_Fill(aBufferResult+200, 20, 2, 0, 0x1C01);
_DMA_Fill(aBufferResult+300, 50, 20, 0, 0xF0F0);
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.