Search the Community
Showing results for tags 'ltdc'.
-
Аналог. камера -> STM32 -> LTDC -> дисплей
LAS9891 posted a topic in ARM, 32bit
Здравствуйте! Имеется задача. С аналоговой камеры видеосигнал поступает в STM32 через встроенный АЦП. Необходимо вывести изображение на дисплей. В качестве видеобуфера используется RAM контроллера. Изображение размером 160x120, поэтому встроенной RAM достаточно. Изображение буду выводить через LTDC. Вот тут вычитал, что руководить этим должен LTDC. В смысле, если используется несколько видеобуферов, то LTDC должен формировать прерывание в конце кадра и в прерывании менять адреса видеобуфера. Запуск камеры, я так понимаю, тоже должен быть в этом прерывании. Но какими должны быть частоты работы камеры и вывода изображения на дисплей в этом случае? В смысле, кто быстрее должен работать? или нужно подобрать одинаковые частоты? Действительно ли требуется минимум 3 видеобуфера или при определенных соотношениях частот достаточно 2? -
STM32, LTDC и дисплей UG-6028GDEBF02
LAS9891 posted a topic in ARM, 32bit
Я пытаюсь выводить картинку на дисплей через LTDC. Контроллер STM32H743IIT6, дисплей UG-6028GDEBF02. Дисплей имеет разрешение 160x128. Цвет каждого пикселя определяется данными, которые поступают за три такта пиксельной частоты — по такту на цвет (R, G, B). Я хочу выводить Ч/Б изображение используя пиксельный формат L8. Для этого каждый пиксель буду определять тремя одинаковыми значениями по цветам (R=G=B). Раз каждый пиксель определяется тремя тактами пиксельной частоты, то в одной строке должно быть 160х3 = 480 тактов — или 480 пикселей. Таким образом для LTDC мое изображение преобразуется в 480х128. Дисплей можно настроить на режим работы 160х120 (с помощью встроенного в дисплей контроллера), что я и сделал. Попробовал вывести на дисплей изображение формата 160х120 с помощью встроенного в дисплей контроллера — все получилось как и должно быть.Теперь пытаюсь выводить на дисплей картинку по интерфейсу RGB используя LTDC. Настроил все на регистрах и по ДШ. Сформировал массив на 57600 пикселей (160х120х3). В массиве закрасил первый пиксель в первой строке (нулевой пиксель в нулевой строке), первый пиксель в третьей строке (нулевой пиксель во второй строке) и последний пиксель в кадре 57600 (57599). Вывожу на дисплей — вижу картинку как на картинке. Первый пиксель в первой строке горит не в начале дисплея, он смещен вправо, также как и первый пиксель в третьей строке. Последний горит слева от первого. Картинка отобразилась не до конца, почему то LTDC не отобразил весь буфер, а не дождавшись конца начал отображать первый пиксель, хотя адрес для нового кадра взял не первый в буфере, а тот с которого он прекратил отображать.Пробовал поиграться с настройками — проблему не победил. Не подскажите что-нибудь дельное? С какими регистрами поиграть и как? Возможно я косячу с параметрами синхронизации. Вот все что относится к RGB интерфейсу дисплея: Если я косячу с параметрами синхронизации, то что тут принять за них? Я принял следующие: #define HSYNC_WIDTH ((uint16_t)3) #define VSYNC_WIDTH ((uint16_t)1) #define HBP ((uint16_t)0) #define VBP ((uint16_t)0) #define ACTIVE_WIDTH ((uint16_t)480) #define ACTIVE_HEIGHT ((uint16_t)120) #define HFP ((uint16_t)0) #define VFP ((uint16_t)0) Полный код прилагаю: lar_ltdc.h lar_ltdc.c -
STM32H743 LTDC - Frame buffer line length and pitch
AleksBak posted a topic in ARM, 32bit
Добрый день. Разбираюсь с работой LTDC - без использования CubeMX кода. Заработало нормально - использую только 2-ой слой (самый верхний) и т.д. Показывает. Просто решил спросить по поводу настройки регистра CFBLR слоя. В RM по поводу его настройки написано следующее: Я тогда пишу так: /* Frame buffer line length and pitch: * В RM0385 (на стр. 537) указано, что тут младшее слово должны такое содержать: * Bits 12:0 CFBLL[12:0]: color frame buffer line length * These bits define the length of one line of pixels in bytes + 3. * The line length is computed as follows: * active high width * number of bytes per pixel + 3. */ LTDC_Layer2->CFBLR &= ~(LTDC_LxCFBLR_CFBLL | LTDC_LxCFBLR_CFBP); LTDC_Layer2->CFBLR |= (((PIXEL_SIZE * DISPLAY_WIDTH) << 16) | (PIXEL_SIZE * DISPLAY_WIDTH + 3U)); Т.е. добавляю '3' в конце. Здесь 'PIXEL_SIZE' == 4U т.к. формат у меня ARGB8888, а вначале обнуляю регистр CFBLR, а потом пишу указанное в RM значение. Однако в CubeMX HAL, при настройке этого регистра, пишется другое значение: if (pLayerCfg->PixelFormat == LTDC_PIXEL_FORMAT_ARGB8888) { tmp = 4U; } else if (pLayerCfg->PixelFormat == LTDC_PIXEL_FORMAT_RGB888) { tmp = 3U; } else if ((pLayerCfg->PixelFormat == LTDC_PIXEL_FORMAT_ARGB4444) || (pLayerCfg->PixelFormat == LTDC_PIXEL_FORMAT_RGB565) || (pLayerCfg->PixelFormat == LTDC_PIXEL_FORMAT_ARGB1555) || (pLayerCfg->PixelFormat == LTDC_PIXEL_FORMAT_AL88)) { tmp = 2U; } else { tmp = 1U; } /* Configure the color frame buffer pitch in byte */ LTDC_LAYER(hltdc, LayerIdx)->CFBLR &= ~(LTDC_LxCFBLR_CFBLL | LTDC_LxCFBLR_CFBP); LTDC_LAYER(hltdc, LayerIdx)->CFBLR = (((pLayerCfg->ImageWidth * tmp) << 16U) | (((pLayerCfg->WindowX1 - pLayerCfg->WindowX0) * tmp) + 7U)); т.е. тут прибавляется '7' в конце. Здесь 'tmp' как видите, это PIXEL_SIZE, что выше. А (pLayerCfg->WindowX1 - pLayerCfg->WindowX0) это просто (DISPLAY_WIDTH - 0). Т.е. так в итоге если привести к 1-му куску кода: LTDC_Layer2->CFBLR = ((DISPLAY_WIDTH * PIXEL_SIZE) << 16U) | ((DISPLAY_WIDTH * PIXEL_SIZE) + 7U); Если это я применю у себя (вместо '3' напишу '7'), то тоже показывает совершенно одинаково, что и до этого. (а если ничего сюда не писать, то не покажет изображение). Поэтому решил спросить, что это за настройка и почему в CubeMX так делают.