Перейти к содержанию
    

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

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

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

 

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

256 цветов

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

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

 

Изменено пользователем Огурцов

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

DMA2D->OOR = s;

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

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

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

 

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

я тоже

 

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

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

 

 

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

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

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

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

Изменено пользователем Огурцов

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

 

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

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

Изменено пользователем Огурцов

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...