Jump to content

    

32F769IDISCOVERY + MIPI DSI 720p (1280x720)?

не, а такое прокатит ?

А что, кто-то запрещает?

 

и кто придумал этот must have ? если даже spi не гнушаются предлагать

Так требования рынка. 256 цветов могут долго существовать только в условиях плановой экономики.

SPI для всякой ерунды типа 128x64.

Share this post


Link to post
Share on other sites
А что, кто-то запрещает?

привычка, для тв-сигнала не приемлемо

 

256 цветов

я не говорил про 256 цветов, а про 24 бита говорил

прозрачность как бы не сильно нужна, но она требуется для выравнивания размера пикселя на 4 байта

 

Edited by Огурцов

Share this post


Link to post
Share on other sites
я не говорил про 256 цветов, а про 24 бита говорил

1280x1024 24bpp во времена первых пентиумов? Не было такого в массовом сегменте.

Share this post


Link to post
Share on other sites
1280x1024 24bpp во времена первых пентиумов? Не было такого в массовом сегменте.

правильно, но вы смешиваете разные посты - 480x272 в 10 раз меньше, чем 1280x1024

и даже если взять 640x480, всё равно остаётся запас

 

Share this post


Link to post
Share on other sites

Вот 480x272, пожалуй, еще как-то можно окучивать STM. А выше забираться я бы не стал.

Share this post


Link to post
Share on other sites
SPI для всякой ерунды типа 128x64.

Хм... у меня сейчас вполне себе нормально работает LCD по SPI на 320x240x16bpp. 3D-шутеры на нём показывать не надо.

Вся динамическая информация отображается вполне бодро: всякие счётчики (текстовые отображения меняющихся чисел) на экране бегут очень даже шустро.

Конечно, если бы в этом LCD (и МК) был quad-SPI (или LCD по интерфейсу поддерживал бы режимы с меньшей разрядностью цвета) - было бы вообще за глаза. На quad-SPI и в 2 раза больший экран нормально пойдёт.

 

Вот 480x272, пожалуй, еще как-то можно окучивать STM. А выше забираться я бы не стал.

По какому интерфейсу? Параллельному? По параллельному STM32 должен много больше нормально обслуживать. Ну если руки конечно прямые :rolleyes:

У меня сейчас работает проектик:

По SPI идёт 320x240x16bpp на SCLK=40МГц, параллельно этот же CPU декодирует MP3 на 320кб/c, парсит поток с ESP8266 (WiFi) и ещё много чего успевает. На экране в это время бегут несколько быстро меняющихся счётчиков, процедура отрисовки пока построена неоптимально - при каждом изменении видеобуфер стирается полностью, потом строится новый кадр заново (затем отправляется на LCD) - поэтому при любой модификации на экране контроллеру LCD отправляются все пикселы 320x240. При всём при этом загрузка процессора составляет ~55%. И частота МК не максимальная == 160МГц. И измерено это на исходнике скомпилённом с Low оптимизацией (IAR) выполняющемся из RAM/SDRAM.

 

Если-б этот МК (и контроллер ILI9341) имели dual- или quad-SPI была-бы вообще красота. B)

Share this post


Link to post
Share on other sites
В те блаженные времена никто особо не жаловался на отсутствие альфа-канала, скоростной анимации на весь экран и прочих современных must have плюшек.

Вот 480x272, пожалуй, еще как-то можно окучивать STM. А выше забираться я бы не стал.

У меня на экране 800х480х16бит крутится можно сказать анимация почти на весь экран с несколькими слоями прозрачности. Перерисовка всего кадра занимает от 10 до 30мс при одновременном выводе с частотой кадров около 29к/с. Загрузка процессора при этом от 5 до 14% (процессор параллельно занят разными своими делами - вычислениями БПФ, фильтрацией сигнала, обслуживанием подключенных к нему устройств, USB, запись/чтение с SD карты и т.д). Наверное я что-то делаю не так, но меня полностью устраивает в этом плане stm32 :laughing:

 

Как по мне, то 800х480х16бит без проблем вообще, 1024х600х16бит наверное рубеж, для большего нужно как минимум перейти на 32битную SDRAM либо на другую платформу.

 

можете привести пример ?

Все просто - в регистр смещения до следующей линии (OOR/BGOR) записываете смещение до следующей точки/штриха от окончания нарисованного элемента, размер по горизонтали устанавливаете равным длине штриха (или в 1 если точки рисуете), кол-во линий (размер по вертикали) равным кол-ву точек/штрихов в линии, вот собственно и все.

Например, линия 3 точки рисуем, потом 5 точек пропускаем, общая длина 80 точек:

   int m = 3; //Кол-во точек которые рисуем
   int s = 5; //Кол-во точек которые пропускаем
   int l = 80; //Длина линии
   
   DMA2D->OOR = s;
   DMA2D->NLR = DMA2D_NLR_PL_0 * m + DMA2D_NLR_NL_0 * (l/(m+s));

Остальное инициализируете, как обычно при рисовании, например, прямоугольника. Если нужна прозрачность, то регистр BGOR инициализируете так же, как OOR.

   DMA2D->BGOR = s;

 

или какое поле нужно заполнить в структуре DMA2D_InitTypeDef чтобы нарисовать горизонтальную линию точками ?

HALом не пользуюсь, поэтому что там в структурах надо инициализировать не подскажу.

Share this post


Link to post
Share on other sites
DMA2D->OOR = s;

DMA2D->NLR = DMA2D_NLR_PL_0 * m + DMA2D_NLR_NL_0 * (l/(m+s));

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

а почему так нельзя рисовать прямоугольники ? вроде самое оно, если ширина регистра позволяет

 

HALом не пользуюсь

я тоже

 

олл, почему дисплей подёргивается, когда dma2d работает ? т.е. картинка как бы сдвигается в сторону

это синхра слетает или что, или это нормально, куда копать ?

 

 

Вот 480x272, пожалуй, еще как-то можно окучивать STM. А выше забираться я бы не стал.

800x600 считается нормально, т.е. 2x640x480 обязано работать

а больше вроде бы как и не надо

т.е. надо, но уже как-то иначе и это будет уже совсем другая история

Edited by Огурцов

Share this post


Link to post
Share on other sites
По SPI идёт 320x240x16bpp на SCLK=40МГц...

320 * 240 * 16 / 40M = 30.72 мс = 32.55 к/с

 

Перерисовка всего кадра занимает от 10 до 30мс при одновременном выводе с частотой кадров около 29 к/с.

 

Ну вот, а у нормального UI перерисовка не должна занимать больше 16 мс (т.е. обеспечивать 60 к/с), иначе плавной анимации не будет по определению.

Да, TFT-экран, конечно, надо обслуживать с частотой 60, а не 30. Даташит позволяет, но пользователей тоже надо уважать.

Share this post


Link to post
Share on other sites
Например, можно нарисовать горизонтальную линию, но не прямоугольник.

Прямоугольник рисовать можно, Пример:

 

void LCD_DRV_DrawFillRectAlpha(uint32_t LayerAddr, uint16_t x0, uint16_t y0, uint16_t x1, uint16_t y1, uint32_t ColorRGB888, uint8_t Alpha)
{
if (y0 > y1)
{
	uint16_t bak;
	bak = y1;
	y1 = y0;
	y0 = bak;
}	
if (x0 > x1)
{
	uint16_t bak;
	bak = x1;
	x1 = x0;
	x0 = bak;
}	
 uint16_t Width = x1 - x0;
 uint16_t Height = y1 - y0;
 #if (LCD_PIXEL_BYTES == 2)
 uint32_t Xaddress = LayerAddr + 2*(LCD_DRV_GetXSize()*y0 + x0);
 #else
 uint32_t Xaddress = LayerAddr + 4*(LCD_DRV_GetXSize()*y0 + x0);
 #endif

 LCD_DRV_LL_DMA2D_FillBufferAlphaColor(Xaddress, Width, Height, (LCD_DRV_GetXSize() - Width), DMA2D_OUTPUT_RGB565, ColorRGB888, Alpha, true);
}
//=============== Заполнить область цветом с коэффициентом  прозрачности ========
void LCD_DRV_LL_DMA2D_FillBufferAlphaColor(uint32_t BufferAddr, uint32_t xSize, uint32_t ySize, uint32_t OffLine, uint32_t  OutputColorMode, uint32_t ColorRGB888, uint8_t Alpha, uint8_t wait)
{
 LCD_DRV_DMA2D_WaitEND();//Дождаться конца выполнения предыдущего вывода
 // Замешивание 
 MODIFY_REG(DMA2D->CR, DMA2D_CR_MODE, DMA2D_M2M_BLEND);

 //Конфигурация переднего плана
 DMA2D->FGPFCCR  = (DMA2D_FGPFCCR_CM & DMA2D_INPUT_A8)// Формат цвета
     |(DMA2D_FGPFCCR_AM & (1 << DMA2D_FGPFCCR_AM_Pos))//Замена альфа канала
     |(DMA2D_FGPFCCR_ALPHA & (Alpha << DMA2D_FGPFCCR_ALPHA_Pos));//Алфа канал

 DMA2D->FGCOLR = ColorRGB888;
 DMA2D->FGMAR = BufferAddr;
 DMA2D->FGOR = OffLine;

 //Конфигурация заднего плана
 DMA2D->BGPFCCR  = DMA2D_BGPFCCR_CM & OutputColorMode;// Формат цвета

 DMA2D->BGMAR = BufferAddr;
 DMA2D->BGOR = OffLine; 


 //Выходной буфер    
 // Формат цвета 
 DMA2D->OPFCCR = DMA2D_OPFCCR_CM & OutputColorMode;

 DMA2D->OMAR = BufferAddr;//адрес буфера для заполнения
 DMA2D->OOR = OffLine; // установка смещения (xSize + OffLine = LayerXSize) 

 // установка количества пикселей на линию и количество линий 
 DMA2D->NLR = (DMA2D_NLR_NL|DMA2D_NLR_PL) & (ySize| (xSize << DMA2D_NLR_PL_Pos)); 

 //Запуск
 DMA2D->CR |= DMA2D_CR_START;

 if(wait)LCD_DRV_DMA2D_WaitEND();
}

 

 

 

Share this post


Link to post
Share on other sites
Ну вот, а у нормального UI перерисовка не должна занимать больше 16 мс (т.е. обеспечивать 60 к/с), иначе плавной анимации не будет по определению.

Да, TFT-экран, конечно, надо обслуживать с частотой 60, а не 30. Даташит позволяет, но пользователей тоже надо уважать.

У меня в UI есть бегущие строки - на глаз бегут вполне плавно. Так что FPS==30Гц - вполне ок. Тащить 8+ проводов только на LCD - сильно накладно.

В планах есть модификация всего алгоритма отрисовки UI (чтобы при изменении одного элемента только он перерисовывался, а не весь экран).

Это позволит пересылать на LCD не весь экран, а только минимальный прямоугольник, охватывающий изменения (ILI9341 позволяет и моя граф.либа позволяет) и поднять средний FPS.

Но потребуется сильно усложнить весь алгоритм отрисовки UI. Не уверен, что это усложнение реально нужно.

Share this post


Link to post
Share on other sites
олл, почему дисплей подёргивается, когда dma2d работает ? т.е. картинка как бы сдвигается в сторону

это синхра слетает или что, или это нормально, куда копать ?

Причин может быть 2:

Либо у Вас высокая частота вывода, медленная память, 16 бит память. Или Вы выводите картинку и рисуете её в одном буфере.

 

На 32 битной памяти (в 32F769IDISCOVERY) без проблем выводится разрешение 1280х800 RGB565 1 слой 42 гц. С помощью DMA2d вывожу анимацию частотой 42 гц.

После того как разобрался с DMA2d, во втором слое не вижу необходимости.

Share this post


Link to post
Share on other sites
У меня в UI есть бегущие строки - на глаз бегут вполне плавно. Так что FPS==30Гц - вполне ок.

Так-таки и ок?

 

ИМХО, когда дело касается UI, нельзя идти на компромиссы. Производительности должно не просто хватать, она должна в разы перекрывать потребности. Тогда можно работать.

Share this post


Link to post
Share on other sites
Или Вы выводите картинку и рисуете её в одном буфере.

да, в одном, а какая разница, где я её рисую ? если бы она просто мерцала на месте перерисовки, я бы даже не спрашивал, но она куда-то улетает - каков механизм этого ?

 

 

ИМХО, когда дело касается UI, нельзя идти на компромиссы

вся электроника - это сплошные компромиссы

Edited by Огурцов

Share this post


Link to post
Share on other sites
да, в одном, а какая разница, где я её рисую ? если бы она просто мерцала, я бы даже не спрашивал, но она куда-то улетает - каков механизм этого ?

Попробуйте понизить частоту вывода.

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this