[aaarrr 25]

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

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

 

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

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

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

[VCucumber 0]

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

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

 

256 цветов

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

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

 

Edited October 26, 2017 by Огурцов

[aaarrr 25]

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

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

[VCucumber 0]

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

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

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

 

[aaarrr 25]

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

[jcxz 51]

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)

[Шаманъ 0]

В те блаженные времена никто особо не жаловался на отсутствие альфа-канала, скоростной анимации на весь экран и прочих современных 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ом не пользуюсь, поэтому что там в структурах надо инициализировать не подскажу.

[VCucumber 0]

DMA2D->OOR = s;

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

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

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

 

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

я тоже

 

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

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

 

 

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

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

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

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

Edited October 26, 2017 by Огурцов

[aaarrr 25]

По SPI идёт 320x240x16bpp на SCLK=40МГц...

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

 

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

 

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

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

[Sanya_kv 0]

Например, можно нарисовать горизонтальную линию, но не прямоугольник.

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

 

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();
}

 

 

 

[jcxz 51]

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

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

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

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

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

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

[Sanya_kv 0]

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

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

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

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

 

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

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

[aaarrr 25]

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

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

 

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

[VCucumber 0]

Или Вы выводите картинку и рисуете её в одном буфере.

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

 

 

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

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

Edited October 26, 2017 by Огурцов

[Sanya_kv 0]

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

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