STM32 LTDC 프레임버퍼 대역폭: 트래픽 및 FIFO 언더런

프레임버퍼는 RAM에 들어갈 수 있지만 STM32 LTDC 디스플레이는 여전히 픽셀 데이터가 부족할 수 있다. 용량은 얼마나 많은 바이트를 저장할 수 있는지를 답한다. 대역폭은 반복적인 트래픽을 설명한다. FIFO 언더런은 컨트롤러가 현재 예비량이 소진되기 전에 데이터를 수신하는지 여부에 관한 것이다. 설계는 이 세 가지를 모두 다루어야 한다.

이 분석은 선형의 비압축 프레임버퍼로부터의 연속 스캔아웃을 다룬다. 그 수치들은 교육적 가정이며, 패널 타이밍이나 STM32 성능 보장이 아니다. 목표는 메모리 인터페이스가 적절하다고 결정하기 전에 트래픽 계정과 서비스 지연 조사를 구축하는 것이다.

용량부터 시작한 다음, 시간을 계산에 넣어라

800 x 480 활성 이미지가 RGB565로 픽셀당 2바이트로 저장된다고 가정하자. 빡빡하게 할당된 프레임은 800 x 480 x 2 = 768,000바이트를 필요로 한다. 그러한 프레임버퍼 두 개는 1,536,000바이트를 필요로 한다. 실제 할당은 또한 그 레이아웃과 메모리 요구사항을 충족해야 한다.

그 수치들은 저장 용량을 확립할 뿐, 전송 속도를 확립하지 않는다. 동일한 저장된 프레임은 변경 없이 반복적으로 읽힐 수 있다. 반대로, 대체 프레임을 렌더링하는 것은 디스플레이 엔진이 그것을 읽기 전에도 트래픽을 추가한다.

TouchGFX 4.27은 더블 버퍼링의 저장 비용과 수명 주기를 설명한다: 하나의 버퍼가 연속적인 디스플레이 판독을 공급하는 동안 다른 하나가 렌더링되며, 제어된 스왑이 이루어진다.^[2] 두 개의 할당된 버퍼가 LTDC가 매 리프레시마다 두 개의 완전한 이미지를 읽는다는 것을 의미하지는 않는다.

버퍼는 이미지를 저장하고, 레이어는 구성된 합성 입력이다. 여러 활성 레이어는 별도의 읽기를 필요로 할 수 있다. 하나의 레이어를 더블 버퍼링하는 것은 연속 프레임 위치를 변경할 뿐, 함께 읽히는 레이어의 수를 변경하지 않는다.

프레임 평균 트래픽과 활성 소비를 구분하라

교육용 이미지를 800 x 480으로 유지하고 60 Hz 리프레시를 가정하자. 전체 1초에 걸쳐 읽히는 유용한 활성 픽셀 페이로드는:

800 x 480 x 60 x 2 = 46,080,000 바이트/초

이는 십진 메가바이트를 사용하여 46.08 MB/s이다. 이는 프레임 간격에 걸친 평균이며, 메모리가 그 간격 내에서 서비스를 임의로 지연시켜도 된다는 보장이 아니다.

이제 블랭킹을 포함한 총 타이밍 차원이 1056 x 525라고 가정하자. 해당 픽셀 클록은 1056 x 525 x 60 = 33.264 MHz이다. 그 클록에 2바이트를 곱하면 픽셀 클록 기반 활성 소비 스크리닝 속도로 66.528 MB/s가 된다.

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 MB/s가 된다. 이는 이상적인 페이로드 소계이다. 다른 작업과 트랜잭션 비용은 제외된다; 캐싱이나 중간 스테이징은 선택된 경계에서 트래픽을 변경할 수 있다. 각 읽기와 쓰기를 한 번씩 계산하라; 그런 다음 동일한 복사를 플러시 트래픽과 같은 두 번째 레이블 아래에 다시 추가하지 말라.

배치는 계정을 변경한다. 복사 소스가 다른 곳에 있다면, 그 읽기는 목적지 쓰기와 동일한 메모리 경계를 교차하지 않을 수 있다. 반대로, 목적지 픽셀을 읽은 후 쓰는 렌더링은 단순한 쓰기 전용 모델 이상의 트래픽을 추가한다. 모든 GUI 업데이트에 하나의 일반적인 비용을 할당하기보다는 작업을 정의하라.

GUI 렌더 모드는 생산자 측을 변경한다

LVGL 9.5는 PARTIAL, DIRECT, FULL 렌더링을 구분한다. PARTIAL은 변경된 영역에 대해 더 작은 그리기 버퍼를 사용한다. DIRECT는 전체 화면 크기의 버퍼를 사용한다; 두 개의 버퍼를 사용하면 플러시 후 렌더링된 영역을 다른 버퍼로 복사한다. FULL은 전체 화면을 다시 그린다.^[3]

이러한 구분은 워크로드 계정에 속한다. 모드 이름만으로는 결과적인 외부 메모리 트래픽을 확립할 수 없다. 렌더링이 어디서 발생하는지, 플러시 작업이 무엇을 복사하는지, 어떤 할당이 검토 중인 메모리를 공유하는지 추적하라.

부분 렌더링은 연속적인 LTDC 스캔아웃을 멈추지 않는다. 작은 버튼을 업데이트하면 컨트롤러가 디스플레이된 프레임을 계속 읽는 동안 생산자 작업을 줄일 수 있다. 아키텍처가 대신 디스플레이 로컬 이미지 메모리나 다른 리프레시 모델을 사용한다면, 여기서 사용된 것과 다른 계정이 필요하다.

마찬가지로, 더블 버퍼링은 리프레시에 의해 소비되는 바이트를 줄이지 않으면서 생산자와 리더 소유권을 분리할 수 있다. 또한 프레임워크에 따라 동기화 복사를 도입할 수 있다. 추가 버퍼가 대역폭 최적화라고 가정하기보다는 실제 작업을 비교하라.

평균 대역폭은 모든 서비스 갭에 대해 보호할 수 없다

FIFO는 유한한 예비량을 보유한다. 메모리가 긴 간격에 걸쳐 충분한 바이트를 전달하더라도, 서비스가 없는 기간은 활성 소비 동안 그 예비량을 소진시킬 수 있다. 이것이 평균 대역폭 결과가 언더런에 대한 면역을 확립할 수 없는 이유이다.

의도적으로 이상화된 모델을 고려하자: 256바이트 FIFO가 가득 찬 상태로 시작하여 일정한 96 MB/s로 배출되고, 4마이크로초 동안 리필을 받지 않는다. 이들은 독립적인 예시를 위한 가상의 파라미터이며, STM32 FIFO 사양이나 앞선 RGB565 워크로드에서 도출된 값이 아니다.

갭 동안 요구되는 바이트 = 96,000,000 x 0.000004 = 384

갭은 가정된 전체 예비량이 보유한 것보다 더 많은 데이터를 필요로 한다. 이후의 더 빠른 서비스는 마감 시간이 이미 지난 픽셀을 공급할 수 없다. 따라서 적절한 장기 처리량은 모든 서비스 중단을 보상할 수 없다. 이 예시는 지연 제약을 보여주며, 실제 LTDC에 대한 스케줄링 한계를 규정하지 않는다.

실제 평가에는 대상 FIFO 조직, 갭 시작 시점의 점유율, 페치 동작, 메모리 서비스 타이밍이 필요하다. 부분적으로 채워진 상태에서 시작하는 FIFO는 이 모델보다 여유가 적다. 소비 중 리필은 궤적을 다시 바꾼다. 산술은 가정이 가시적으로 유지될 때만 유용하다.

대표적인 워크로드로 경합을 조사하라

피크 인터페이스 속도는 LTDC에 대한 지속적인 유용한 전달과 같지 않다. 대상의 메모리 타이밍, 트랜잭션 패턴, 리프레시 동작, 중재, 경쟁 접근이 수신하는 서비스를 결정한다. 가정된 효율 백분율을 삽입하고 그 결과를 검증된 한계로 취급하지 마라.

정적 스캔아웃을 추가 렌더링, 복사, 기타 메모리 사용자와 분리하는 워크로드 기록을 작성하라. 그런 다음 작업 버스트를 생성하는 전환을 포함하여 현실적인 조합을 실행하라. 조용한 정적 화면은 이미지를 디코딩하고 업데이트된 영역을 복사하는 시스템을 대표할 수 없다.

모든 장치가 동일한 카운터를 노출한다고 가정하지 말고 대상의 문서화된 상태 또는 드라이버 기록을 수집하라. 모니터링이 활성화되어 있고 관심 이벤트를 기록하는지 확인하라. 문서화된 처리 의미를 따르라. 기록된 언더런이 없는 기간은 해당 조건에 대한 유용한 증거이지만, 완전한 패널 호환성을 입증하거나 모든 향후 워크로드를 포괄하지는 않는다.

가능한 변경에는 불필요한 복사 감소, 활성 레이어 재검토, 메모리 배치 및 스케줄링 수정이 포함된다. 각각은 계정의 특정 부분을 변경하며 대상에서 확인해야 한다. 리프레시 변경은 패널이 지원하는 타이밍 내에 있어야 하며, 보편적으로 안전한 감소는 없다.

대역폭을 다른 통합 결함과 분리하라

잘못된 픽셀 레이아웃과 오래된 CPU 작성 데이터는 자체적인 증거가 필요하다. 대역폭 계산은 올바른 캐시 게시 또는 버퍼 소유권을 입증할 수 없다. 반대로 메모리 가시성을 수정한다고 해서 바쁜 메모리 시스템이 스캔아웃 데드라인을 충족한다고 보장할 수 없다.

터치 아키텍처가 주요 프로젝트 결정 사항일 때 LCD 픽셀 클럭 및 타이밍 가이드 타이밍 맥락 및 LCD 디스플레이 모듈 인터페이스 인터페이스 맥락을 위한 가이드. 트래픽 계정을 실제 연속 스캔아웃 경로에 연결하라.

프로젝트별 검토를 위해서는, RJY Display에 문의하십시오 패널 데이터시트 및 타이밍, MCU, 메모리 토폴로지 및 클록, 버스 폭, 레이어 및 포맷, 렌더/복사 일정, 결함 기록, 대표적인 동시 워크로드와 함께. 이러한 세부 사항은 범위가 정해진 통합 논의를 뒷받침하며, 계산된 수치는 호환 보드나 보장된 수정을 입증하지 않는다.

참고문헌

1. ST AN4861, 개정 7: LTDC로 그래픽 애플리케이션 생성; 동일한 애플리케이션 노트의 레이어 논의. 2026년 2월.
2. TouchGFX 4.27: 프레임버퍼, 2026년 10월 22일 확인.
3. LVGL 9.5: 디스플레이 설정 및 드로우 버퍼.