Пропускная способность фреймбуфера STM32 LTDC: трафик и недозаполнение FIFO

Буфер кадра может помещаться в RAM, в то время как дисплей STM32 LTDC всё ещё испытывает нехватку пиксельных данных. Ёмкость отвечает на вопрос, сколько байт может быть сохранено. Пропускная способность описывает повторяющийся трафик. Недостаточное заполнение FIFO касается того, получает ли контроллер данные до того, как его текущий резерв опустеет. Проект должен учитывать все три аспекта.

Данный анализ охватывает непрерывное сканирование из линейного несжатого буфера кадра. Приведённые числа являются учебными допущениями, а не таймингами панели или гарантиями производительности STM32. Цель — построить учёт трафика и исследование задержки обслуживания, прежде чем делать вывод о достаточности интерфейса памяти.

Начните с ёмкости, затем включите время в расчёт

Предположим, что активное изображение 800 x 480 хранится в формате RGB565 по два байта на пиксель. Плотно выделенный кадр требует 800 x 480 x 2 = 768 000 байт. Два таких буфера кадра требуют 1 536 000 байт. Любое фактическое выделение также должно удовлетворять требованиям к компоновке и памяти.

Эти цифры определяют объём хранения, а не скорость передачи. Один и тот же сохранённый кадр может считываться повторно без изменений. С другой стороны, рендеринг замещающего кадра добавляет трафик ещё до того, как движок дисплея его прочитает.

TouchGFX 4.27 описывает затраты на хранение и жизненный цикл двойной буферизации: один буфер может обеспечивать непрерывное считывание для дисплея, пока другой рендерится, с управляемым переключением.^[2] Два выделенных буфера не означают, что LTDC считывает два полных изображения при каждом обновлении.

Буферы хранят изображения; слои являются настроенными входами композиции. Несколько активных слоёв могут требовать отдельных считываний. Двойная буферизация одного слоя изменяет расположение последовательных кадров, а не количество слоёв, считываемых одновременно.

Различайте средний трафик за кадр и активное потребление

Оставим учебное изображение 800 x 480 и предположим частоту обновления 60 Гц. Полезная нагрузка активных пикселей, считываемая за целую секунду, составляет:

800 x 480 x 60 x 2 = 46 080 000 байт/с

Это 46,08 МБ/с в десятичных мегабайтах. Это среднее значение за интервал кадра, а не гарантия того, что память может произвольно задерживать обслуживание в пределах этого интервала.

Теперь предположим общие размеры тайминга 1056 x 525, включая гашение. Соответствующая тактовая частота пикселей составляет 1056 x 525 x 60 = 33,264 МГц. Умножение этой частоты на два байта даёт 66,528 МБ/с как оценочную скорость активного потребления на основе тактовой частоты пикселей.

ST AN4861, редакция 7, связывает тактовую частоту пикселей с общими размерами тайминга и частотой обновления, а также представляет оценку пропускной способности на основе тактовой частоты пикселей и байтов хранения слоя на пиксель. В ней также рассматриваются конкурирующие ведущие устройства шины и проводится различие между голоданием FIFO и ошибкой передачи.^[1]

Эта оценочная скорость описывает темп активных пикселей, а не дополнительные пиксели RAM для погашающих интервалов или постоянную скорость RAM во время гашения. Буферизованные выборки могут происходить во время гашения. Не добавляйте эту скорость к среднему за кадр.

Реальные обращения к памяти могут быть неравномерными и буферизованными. Эти расчёты не описывают точную картину пополнения, накладные расходы транзакций или гарантированное обслуживание памяти. Они помогают отделить объём полезной нагрузки от скоростных и временных ограничений, которые её обеспечивают.

Добавляйте трафик производителя один раз, на оцениваемой памяти

Читатель дисплея — лишь один из участников. Рендеринг на CPU, декодирование изображений, операции DMA2D и копирование буферов могут создавать дополнительные чтения и записи. Учитывайте их на заданной границе: например, внешняя память, которая содержит как источник, так и назначение копирования.

Предположим, что полный кадр RGB565 копируется 30 раз в секунду. Предположим, что обе стороны используют учитываемую память и каждая полезная нагрузка пересекает границу один раз. Тогда каждое копирование читает 768 000 байт и записывает ещё 768 000 байт:

(768 000 чтение + 768 000 запись) x 30 = 46 080 000 байт/с

Добавление этого копирования к среднему сканированию одного слоя за кадр даёт 46,08 + 46,08 = 92,16 МБ/с. Это идеальный промежуточный итог полезной нагрузки. Он исключает другую работу и затраты на транзакции; кэширование или промежуточная буферизация могут изменить трафик на выбранной границе. Учитывайте каждое чтение и запись один раз; не добавляйте затем то же копирование снова под другим ярлыком, например «трафик сброса».

Размещение изменяет учёт. Если источник копирования находится в другом месте, его чтения могут не пересекать ту же границу памяти, что и записи назначения. С другой стороны, рендеринг, который читает пиксели назначения перед их записью, добавляет трафик сверх простой модели только записи. Определяйте операцию, а не назначайте каждому обновлению GUI одну общую стоимость.

Режимы рендеринга GUI изменяют сторону производителя

LVGL 9.5 различает рендеринг PARTIAL, DIRECT и FULL. PARTIAL использует меньшие буферы отрисовки для изменённых областей. DIRECT использует буферы размером с полный экран; с двумя буферами он копирует отрисованные области в другой буфер после сброса. FULL перерисовывает весь экран.^[3]

Эти различия относятся к учёту рабочей нагрузки. Одно название режима не может установить результирующий трафик внешней памяти. Отслеживайте, где происходит рендеринг, что копирует операция сброса и какие выделения используют рассматриваемую память.

Частичный рендеринг не останавливает непрерывное сканирование LTDC. Обновление небольшой кнопки может уменьшить работу производителя, пока контроллер продолжает считывать отображаемый кадр. Если архитектура вместо этого использует локальную память изображения дисплея или другую модель обновления, ей требуется иной учёт, отличный от используемого здесь.

Аналогично, двойная буферизация может разделить владение производителя и читателя без уменьшения байтов, потребляемых при обновлении. Она также может вносить синхронизационные копирования в зависимости от фреймворка. Сравнивайте фактические операции, а не предполагайте, что дополнительный буфер является оптимизацией пропускной способности.

Средняя пропускная способность не может защитить от каждого разрыва обслуживания

FIFO содержит конечный резерв. Даже если память доставляет достаточно байтов за длительный интервал, период без обслуживания может исчерпать этот резерв во время активного потребления. Именно поэтому результат средней пропускной способности не может установить невосприимчивость к недостаточному заполнению.

Рассмотрим намеренно идеализированную модель: FIFO на 256 байт начинается заполненным, опустошается с постоянной скоростью 96 МБ/с и не получает пополнения в течение четырёх микросекунд. Это вымышленные параметры для независимого примера, а не спецификация FIFO STM32 или значения, производные от более ранней рабочей нагрузки RGB565.

Байты, требуемые за время разрыва = 96 000 000 x 0,000004 = 384

Разрыв требует больше данных, чем вмещает полный предполагаемый резерв. Более быстрый сервис после этого не может поставить пиксели, срок которых уже прошёл. Таким образом, достаточная долгосрочная пропускная способность не может компенсировать каждое прерывание обслуживания. Этот пример демонстрирует ограничение задержки; он не предписывает предел планирования для какого-либо фактического LTDC.

Реальная оценка требует целевой организации FIFO, заполнения на начало разрыва, поведения выборки и таймингов обслуживания памяти. FIFO, начинающийся частично заполненным, имеет меньший резерв, чем эта модель. Пополнение во время потребления снова изменяет траекторию. Арифметика остаётся полезной только тогда, когда её допущения остаются видимыми.

Исследуйте конкуренцию с репрезентативной рабочей нагрузкой

Пиковая скорость интерфейса не совпадает с устойчивой полезной доставкой в LTDC. Тайминги памяти целевого устройства, шаблон транзакций, поведение обновления, арбитраж и конкурирующие обращения определяют получаемое им обслуживание. Не вставляйте предполагаемый процент эффективности и не рассматривайте результат как проверенный предел.

Составьте запись рабочей нагрузки, отделяющую статическое сканирование от добавленного рендеринга, копирования и других потребителей памяти. Затем протестируйте реалистичные комбинации, включая переходы, порождающие всплески работы. Тихий статический экран не может представлять систему, которая также декодирует изображения и копирует обновлённые области.

Собирайте документированные целевым устройством записи состояния или драйвера, не предполагая, что каждое устройство предоставляет один и тот же счётчик. Убедитесь, что мониторинг включён и регистрирует интересующие события. Следуйте его документированной семантике обработки. Период без зарегистрированного недозаполнения является полезным доказательством для этих условий; он не доказывает полную совместимость с панелью и не охватывает все будущие рабочие нагрузки.

Возможные изменения включают сокращение ненужных копирований, пересмотр активных слоёв или пересмотр размещения в памяти и планирования. Каждое изменяет конкретную часть расчёта и должно быть проверено на целевом устройстве. Изменения обновления должны оставаться в пределах поддерживаемых таймингов панели; универсального безопасного сокращения не существует.

Держите пропускную способность отдельно от других интеграционных неисправностей

Неправильная раскладка пикселей и устаревшие данные, записанные CPU, требуют собственных доказательств. Расчёт пропускной способности не может доказать корректную публикацию кэша или владение буфером. И наоборот, исправление видимости памяти не может гарантировать, что занятая система памяти уложится в сроки сканирования.

Используйте руководство по пиксельной тактовой частоте и timing ЖК-дисплея для контекста таймингов и Интерфейсы модуля LCD-дисплея руководство для контекста интерфейса. Держите учёт трафика привязанным к фактическому пути непрерывного сканирования.

Для обзора в рамках конкретного проекта, в RJY Display с даташитом и таймингами панели, MCU, топологией памяти и тактированием, шириной шины, слоями и форматами, расписанием рендеринга/копирования, записями о неисправностях и репрезентативной конкурентной рабочей нагрузкой. Эти детали поддерживают обсуждение интеграции в рамках области действия; приведённые числа не устанавливают совместимую плату или гарантированное исправление.

Ссылки

1. ST AN4861, редакция 7: Создание графического приложения с LTDC; обсуждение слоёв в той же заметке по применению. Февраль 2026.
2. TouchGFX 4.27: Framebuffer, по состоянию на 22 октября 2026.
3. LVGL 9.5: Настройка дисплея и буферы отрисовки.