개요¶

그래픽 아키텍처 계획¶

이 가이드는 SF32 디바이스에서 반응성이 좋은 그래픽 사용자 인터페이스를 구축하는 방법을 설명합니다. 디스플레이 선택, 프레임버퍼 전략, LVGL 통합, ePicasso 하드웨어 가속, 메모리 배치, 디스플레이 리프레시 동작 등 실제 제품에 영향을 주는 실무적인 결정에 초점을 맞춥니다.

SF32 디바이스는 소형 AIoT 및 웨어러블 제품을 위해 설계되었으며, 이러한 제품에서는 엄격한 전력, 메모리, PCB 면적 목표를 충족하면서도 UI가 부드럽게 느껴져야 합니다. 그래픽 경로는 리소스 처리, 픽셀 합성, 선택적 프레임버퍼 압축, 패널 출력의 역할로 나뉩니다. 이 역할을 서로 구분해 두는 것이 알맞은 최적화를 선택하는 핵심입니다.

이 페이지는 되돌리기 비용이 큰 초기 UI 아키텍처 결정, 즉 패널과 인터페이스, 프레임버퍼 전략, 색 깊이, 투명도, 에셋 배치, 리프레시 정책을 정할 때 활용하십시오. 이어지는 그래픽 문서에서는 그 흐름의 특정 블록에 대한 구현 세부 사항을 제공합니다.

SF32 그래픽 흐름¶

일반적인 디스플레이 리소스 경로는 다음과 같습니다.

Source images, fonts, and animations
        │
        ▼
GraphicsTool converts supported resources to eZip or eZip-A
        │
        ▼
Compressed assets in NOR Flash, PSRAM, NAND, or file storage
        │
        ▼
eZip hardware decoder expands an asset when required
        │
        ▼
LVGL or another UI framework + graphics/display driver
        │
        ├── CPU fallback rendering
        │
        └── ePicasso pixel acceleration
        │
        ▼
Final rendered bitmap in a draw buffer or framebuffer
        │
        ├── Uncompressed display path
        │
        └── Optional: extDMA compresses it into TurboPixel
                    │
                    ▼
             TurboPixel framebuffer in PSRAM
        │
        ▼
Display controller transfers pixels to the panel
        │
        ▼
SPI / QSPI / 8080 / RGB / MIPI DSI / EPD / JDI panel

이 경로는 필수가 아니라 구성 가능한 경로입니다. 제품에 따라 eZip, ePicasso, TurboPixel 또는 전체 프레임버퍼를 사용하지 않을 수 있습니다. 사용 가능 여부와 연결 방식은 선택한 디바이스, SDK, 디스플레이 인터페이스, 패널, 드라이버 구성에 따라 달라집니다. 현재 OpenSiFli LCDC 헤더는 HAL_EXTDMA_MODULE_ENABLED가 활성화되어 있고 제품군 가드가 허용하는 경우에만 LCDC_SUPPORTED_COMPRESSED_LAYER를 정의하며, SF32LB52x와 SF32LB57x는 제외됩니다. 소스 주석에는 LCPU 경로가 활성화되지 않았다는 내용도 있습니다. 공개된 SDK LCDC 기능 표는 SF32LB55x에서 압축 레이어 압축 해제를 지원하지 않는 것으로 표시하므로, 55x는 종단 간 검증된 지원이 아니라 조건부 지원으로 취급하십시오. 정확한 SDK 리비전, 코어, 빌드 구성, 대상 하드웨어를 확인하십시오. TurboPixel 프레임버퍼 압축을 참고하십시오.

애플리케이션 코드는 UI 상태와 동작을 기술합니다. UI 프레임워크는 위젯, 무효화(invalidation), 드로잉을 관리합니다. 그래픽/디스플레이 드라이버는 CPU 실행과 ePicasso 실행 중 하나를 선택하고 버퍼를 조율하며, 디스플레이 컨트롤러는 패널 전송을 담당합니다. 기능별 구현 세부 사항은 ePicasso 그래픽 엔진, eZip 무손실 압축과 하드웨어 디코딩, TurboPixel 프레임버퍼 압축을 참고하십시오.

디스플레이 먼저 선택하기¶

디스플레이 선택은 거의 모든 그래픽 결정에 영향을 줍니다. 코드를 최적화하기 전에 패널 요구 사항을 명확히 정의하십시오.

• 해상도.
• 색 깊이.
• 리프레시 레이트.
• 인터페이스 유형.
• 터치 컨트롤러 요구 사항.
• 백라이트 또는 디스플레이 전원 레일.
• 부분 리프레시 지원 여부.
• 패널에 내부 GRAM이 있는지 여부.
• 저전력 상시 표시(always-on display) 동작이 필요한지 여부.

소형 SPI 또는 QSPI AMOLED는 RGB 패널, MIPI DSI 패널, JDI 메모리 디스플레이, EPD 패널과 동작이 크게 다릅니다. 동일한 UI 프레임워크로 여러 디스플레이 유형을 대상으로 할 수 있지만, 최적의 버퍼 전략과 리프레시 정책은 달라집니다.

인터페이스 선택, 플러시 경로 설계, 패널 브링업에 대한 자세한 내용은 디스플레이 컨트롤러를 참고하십시오.

검증된 LVGL 예제에서 시작하기¶

화면을 구성하기 전에, 제품에서 가장 위험한 그래픽 경계를 이미 검증해 주는 SDK 예제를 선택하십시오. LVGL SDK 예제는 공식 기준 예제, 디자인 툴, 위젯, 압축 에셋, 애니메이션/미디어, 나침반, 게임, 워치 인터페이스 예제를 각각 어떤 엔지니어링 과제를 확립하는지에 따라 정리합니다. 또한 제품에 맞게 적용할 때 어떤 보드, 버전, 디스플레이, 메모리, 성능 가정을 다시 검증해야 하는지도 분명히 밝힙니다.

알맞은 SF32 디바이스 선택¶

CPU 주파수만이 아니라 디스플레이와 UI 워크로드를 기준으로 칩을 선택하십시오.

가장 중요한 제약은 디스플레이 인터페이스, 해상도, 메모리 용량, 그래픽 가속기 세대, 사용 가능한 핀, 전력 예산입니다.

프레임버퍼 및 대역폭 계산기¶

패널이나 애니메이션 방식을 선택하기 전에 메모리와 전송 비용을 추정하십시오.

framebuffer bytes = width x height x bytes_per_pixel
raw full-frame bandwidth = framebuffer bytes x frames_per_second

예시:

버퍼 크기는 KiB(1,024 바이트)로, 대역폭은 MB/s 단위(메가바이트를 1,000,000 바이트로 환산)로 표기합니다. 이 수치는 명령 오버헤드, 정렬, 캐시 관리, 에셋 읽기, 블렌딩 또는 기타 시스템 트래픽을 반영하기 전의 원시 픽셀 수치입니다. 제품에서 Bluetooth 오디오, AI 또는 외부 PSRAM 트래픽도 함께 발생한다면 여유를 두십시오.

버퍼 이해하기¶

UI는 결국 메모리 안의 픽셀입니다. 주요 버퍼 유형은 다음과 같습니다.

전체 화면 프레임버퍼는 편리할 수 있지만 큰 패널에서는 SRAM을 너무 많이 차지할 수 있습니다. 454 x 454 RGB565 버퍼는 412,232 바이트(약 412 kB 또는 403 KiB)이며, 버퍼 두 개를 사용하면 용량이 두 배 필요합니다. 색 깊이가 높아지고 디스플레이가 커지면 용량이 빠르게 늘어납니다.

메모리가 부족하면 부분 드로 버퍼와 변경 영역(dirty-region) 업데이트를 사용하십시오. 애니메이션이 중요하고 메모리에 여유가 있다면 전체 화면 또는 더블 버퍼링 전략이 UI를 더 부드럽게 만들 수 있습니다.

색 깊이 신중히 선택하기¶

색 깊이는 화질, 메모리 사용량, 버스 대역폭에 영향을 줍니다.

대부분의 웨어러블 및 소형 HMI 제품에서는 패널, UI 화질 목표 또는 제품 요구 사항이 더 높은 수준을 요구하지 않는 한 RGB565가 좋은 기본값입니다.

투명도, 알파, 레이어 합성¶

투명도는 알파(alpha) 계수로 표현됩니다. 알파는 전경 픽셀을 배경 픽셀 위에 그릴 때 전경 픽셀이 얼마나 강하게 반영되는지를 나타내는 값입니다. 알파는 RGB 색상 채널과는 독립적입니다. 불투명 픽셀의 알파는 1(8비트 알파 채널에서는 255)이고, 완전 투명 픽셀의 알파는 0입니다.

불투명 배경 위에 스트레이트 알파 전경색을 source-over 방식으로 합성하고 알파를 0~1로 정규화한 경우, 각 출력 RGB 채널은 다음과 같이 계산됩니다. 이 단순화된 식은 투명한 대상의 출력 알파를 계산하지 않습니다.

output = foreground × alpha + background × (1 − alpha)

예를 들어 알파가 50%인 아이콘 픽셀은 색상의 절반을 반영하고 배경의 절반이 보이도록 남깁니다. 이 연산을 반복하면 UI의 시각적 스택, 즉 배경, 이미지, 텍스트, 반투명 컨트롤, 그림자, 애니메이션 레이어가 만들어집니다. 최종 합성된 비트맵은 위에 나온 프레임버퍼와 디스플레이 컨트롤러 단계를 거쳐 진행됩니다.

RGB565에는 알파 채널이 없으므로 일반적으로 불투명한 드로 타깃과 최종 프레임버퍼에 사용합니다. 알파가 필요한 소스 에셋이나 중간 레이어에는 ARGB8888처럼 알파 채널이 있는 포맷이나, 컬러 이미지와 별도의 알파 마스크를 조합한 방식이 흔히 사용됩니다. 드라이버는 SDK, 디스플레이 경로, 선택한 가속기가 실제로 지원하는 포맷을 사용해야 합니다.

알파 표현 방식은 두 가지가 흔히 쓰입니다. 스트레이트 알파에서는 RGB가 원래 색상을 나타내며 알파는 블렌딩 시점에 적용됩니다. 프리멀티플라이드 알파에서는 RGB에 이미 알파가 곱해져 있으며, source-over 식은 output = premultiplied_foreground + background × (1 − alpha)가 됩니다. 두 표현 방식을 섞어서는 안 됩니다. 스트레이트 알파 데이터를 프리멀티플라이드로 취급하거나 그 반대로 취급하면 가장자리에 어둡거나 밝은 후광(halo)이 생깁니다.

알파 블렌딩은 전경 픽셀과 대상 픽셀을 모두 읽은 다음 결과를 씁니다. 따라서 단순한 불투명 복사나 채우기보다 메모리 트래픽이 늘어납니다. 드라이버가 선택한 블렌드 연산과 픽셀 포맷을 지원하는 곳에서는 ePicasso를 사용하고, 그렇지 않은 경우에는 CPU 폴백을 유지하십시오. PSRAM 대역폭이나 전력이 빠듯하다면 전체 화면 반투명 레이어를 제한하고, 무효화된 영역만 업데이트하며, 불필요한 중간 서피스를 피하십시오.

LVGL 통합¶

LVGL은 위젯, 스타일, 입력 처리, 애니메이션, 무효화, 디스플레이 드라이버 훅을 제공하므로 SF32 디바이스에 실용적인 UI 프레임워크입니다.

일반적인 LVGL 통합에는 다음이 필요합니다.

• 디스플레이 드라이버 플러시 콜백.
• 하나 이상의 드로 버퍼.
• LVGL 타이밍을 위한 틱 소스.
• 터치, 버튼, 엔코더 또는 제스처를 위한 입력 디바이스 드라이버.
• 이미지와 폰트에 대한 에셋 처리.
• ePicasso를 위한 선택적 하드웨어 가속 훅.

디스플레이 플러시 콜백은 렌더링과 출력 사이의 경계입니다. 해당 컨트롤러와 DMA 동작은 디스플레이 컨트롤러에서 다룹니다.

LVGL 포팅 결정 사항¶

화면을 다듬기 전에 다음 LVGL 통합 세부 사항을 확정하십시오.

잘 만든 LVGL 포팅에서는 화면 코드가 선언적으로 유지되고, 전송, 동기화, 가속, 캐시 동작은 드라이버가 담당합니다.

ePicasso 가속 사용¶

ePicasso는 UI에 반복적인 픽셀 계산이 많이 필요한 연산이 있을 때 유용합니다. 대표적인 후보는 다음과 같습니다.

• 사각형 채우기.
• 이미지 복사 및 블릿(blit) 연산.
• 알파 블렌딩.
• 이미지 스케일링.
• 지원되는 이미지 영역의 회전 또는 변환.
• 레이어 합성.
• 드라이버가 지원하는 경우 픽셀 포맷 변환.

잘 만든 포팅은 처리량이 큰 일반 연산을 가속하면서 지원되지 않는 경우를 위한 CPU 폴백 경로를 유지합니다. 모든 LVGL 스타일 효과나 위젯이 하드웨어에 대응된다고 가정하지 마십시오. 제품에 중요한 실제 화면을 측정하십시오.

가속이 가장 도움이 되는 경우¶

ePicasso는 보통 다음과 같은 경우에 가장 큰 도움이 됩니다.

• 넓은 영역을 채우거나, 복사하거나, 블렌딩하거나, 스케일링하거나, 변환하는 경우.
• UI가 투명 아이콘, 텍스트 마스크, 그림자, 오버레이 또는 애니메이션 전환을 사용하는 경우.
• 가속기가 없으면 CPU가 매 프레임의 상당 부분을 픽셀 루프에 사용하게 되는 경우.
• 메모리 배치와 픽셀 포맷이 가속기가 효율적으로 처리할 수 있는 조건에 맞는 경우.

가속이 큰 도움이 되지 않을 수 있는 경우¶

하드웨어 가속의 이점이 제한적일 수 있는 경우는 다음과 같습니다.

• 업데이트되는 영역이 매우 작은 경우.
• 병목이 렌더링이 아니라 패널 전송 대역폭인 경우.
• 에셋이 지원되지 않는 포맷이거나 변환 비용이 큰 경우.
• 버퍼가 대역폭이 충분하지 않은 느린 메모리에 배치된 경우.
• 캐시 관리 오버헤드가 연산 시간을 좌우하는 경우.

메모리 배치 전략¶

그래픽 성능은 메모리 이동에 의해 제한되는 경우가 많습니다. 버퍼를 의도적으로 배치하십시오.

• 자주 사용하는 드로 버퍼는 가능하면 빠른 SRAM에 둡니다.
• 큰 프레임버퍼는 SRAM이 부족할 때만 PSRAM에 둡니다.
• 큰 이미지와 폰트는 플래시 또는 PSRAM에 저장하되 액세스 지연 시간을 고려합니다.
• 런타임에 에셋을 반복해서 변환하지 않습니다.
• DMA가 액세스하는 버퍼는 SDK 가이드에 따라 정렬합니다.
• 총 대역폭과 디코딩 비용을 줄일 수 있다면 압축 또는 인덱스 에셋을 사용합니다.

CPU와 그래픽 또는 디스플레이 하드웨어가 버퍼를 공유할 때는 SDK의 캐시 및 버퍼 소유권 규칙을 따르십시오. 하드웨어가 CPU가 쓴 데이터를 읽기 전에 해당 캐시 라인을 clean하고 필요한 동기화를 완료하십시오. 하드웨어가 버퍼에 쓰기 전에는 더티 CPU 캐시 라인이 나중에 하드웨어 결과를 덮어쓰지 않도록 버퍼를 준비하십시오. 전송이 완료되기를 기다린 다음, CPU가 결과를 읽기 전에 오래된 캐시 라인을 invalidate하십시오. 캐시 라인 정렬과 인접 데이터를 고려하고, 하드웨어가 소유 중인 버퍼는 수정하지 마십시오. clean과 invalidate를 서로 바꿔 쓸 수 있는 것으로 취급하지 말고 SDK가 지원하는 루틴을 사용하십시오.

부분 리프레시, 패널별 동작, 단계별 브링업 순서는 디스플레이 컨트롤러를 참고하십시오.

에셋 준비¶

에셋을 잘 준비하면 코드를 최적화하기 전에도 UI가 더 빨라질 수 있습니다.

다음 경험칙을 활용하십시오.

• 이미지 크기를 실제 화면 표시 크기에 맞춥니다.
• 큰 이미지를 매 프레임 스케일링하지 않습니다.
• 가능하면 복잡한 그림자, 그라데이션 또는 배경을 미리 렌더링합니다.
• 투명도가 필요한 곳에만 알파를 사용합니다.
• 공유 아이콘 세트와 폰트 서브셋을 우선 사용합니다.
• 폰트에서 사용하지 않는 글리프를 제거합니다.
• 자주 사용하는 에셋은 그래픽 경로에서 효율적으로 지원되는 포맷으로 유지합니다.

다국어 제품에서는 폰트 메모리가 UI 예산의 대부분을 차지할 수 있습니다. 폰트 폴백, 글리프 서브셋, 텍스트 레이아웃을 일찍 계획하십시오.

애니메이션 전략¶

부드러운 애니메이션은 프레임 예산, 패널 대역폭, 렌더링 비용, 전력에 좌우됩니다.

실용적인 접근 방식은 다음과 같습니다.

• 사용자가 알아차리는 부분만 애니메이션합니다.
• 애니메이션 영역을 작게 유지합니다.
• 가속에 잘 대응되는 변환이나 불투명도 변경을 우선 사용합니다.
• 매 프레임마다 비용이 큰 전체 화면 블러, 그림자 또는 투명도 효과를 피합니다.
• 중요하지 않은 효과는 프레임 레이트를 낮춥니다.
• 화면 밝기가 낮아지거나, 가려지거나, 비활성 상태일 때는 애니메이션을 중지합니다.

웨어러블 UI에 데스크톱 방식의 애니메이션이 곳곳에 필요한 것은 아닙니다. 전력을 소모하거나 프레임을 놓치는 여러 효과보다는 빠르고 명확한 몇 가지 전환이 보통 더 좋게 느껴집니다.

그래픽 검증 매트릭스¶

"충분히 부드럽다"는 주관적인 확인 대신 반복 가능한 화면을 사용하십시오.

화면마다 렌더 시간, 플러시 시간, CPU 부하, 전력을 추적하십시오. 전체 프레임 시간만 측정하면 병목이 LVGL, ePicasso, 메모리, 패널 인터페이스 중 어디에 있는지 알기 어렵습니다.

그래픽 성능 디버깅¶

UI가 느릴 때는 설계를 바꾸기 전에 병목을 먼저 파악하십시오.

다음 항목을 각각 따로 측정하십시오.

• LVGL 렌더 시간.
• ePicasso 연산 시간.
• 디스플레이 플러시 시간.
• CPU 부하.
• 메모리 대역폭 압박.
• 활성, 유휴, 슬립 상태에서의 소비 전력.

흔한 실수¶

다음은 초기에 피하십시오. 나중에 고치려면 비용이 큽니다.

• 대역폭을 추정하기 전에 패널 인터페이스를 선택하는 것.
• 작은 UI 변경에 전체 화면을 다시 그리는 것.
• 프로파일링 없이 모든 UI 에셋을 느린 메모리에 저장하는 것.
• RGB565로 충분한데 RGB888을 사용하는 것.
• 큰 이미지를 매 프레임 스케일링하는 것.
• 하드웨어와 공유하는 버퍼의 캐시 관리를 잊는 것.
• ePicasso가 모든 UI 연산을 자동으로 가속한다고 가정하는 것.
• CPU를 깨어 있게 만드는 타이머나 애니메이션을 너무 많이 사용하는 것.
• 프레임 레이트만 최적화하고 터치 지연 시간을 무시하는 것.
• PCB 브링업 단계까지 기다렸다가 패널 초기화를 검증하는 것.

브링업 체크리스트¶

새 SF32 그래픽 프로젝트를 시작할 때 이 체크리스트를 활용하십시오.

• 디스플레이 해상도, 색 깊이, 인터페이스, 패널 드라이버 IC를 확인합니다.
• 선택한 SF32 디바이스가 필요한 디스플레이 인터페이스를 지원하는지 확인합니다.
• 프레임버퍼와 드로 버퍼의 메모리 요구량을 추정합니다.
• 전체 프레임/부분 버퍼링과 단일/더블 버퍼링 중 적절한 전략을 결정합니다.
• 패널 리셋, 전원 레일, 백라이트, 초기화 시퀀스를 브링업합니다.
• LVGL 틱, 디스플레이 플러시, 입력 드라이버를 구현합니다.
• 기본 채우기, 이미지, 텍스트, 터치 동작을 확인합니다.
• SDK와 드라이버가 지원하는 곳에서 ePicasso 가속을 활성화합니다.
• 공유 버퍼의 캐시 clean/invalidate 동작을 검증합니다.
• 렌더 시간, 플러시 시간, CPU 부하, 전력을 프로파일링합니다.
• 최악의 경우를 가정한 화면, 애니메이션, Bluetooth 동작, 슬립/웨이크업 경로를 테스트합니다.

핵심 요약¶

• 그래픽 설계는 디스플레이 인터페이스, 해상도, 색 깊이, 리프레시 요구 사항에서 시작하십시오.
• 위젯, 무효화, 드로잉, 입력을 관리하려면 LVGL 또는 유사한 프레임워크를 사용하십시오.
• 일반적인 픽셀 연산을 가속하려면 ePicasso를 사용하되 CPU 폴백 경로를 유지하십시오.
• 렌더링 코드만큼 메모리 배치와 버퍼 전략도 신중하게 최적화하십시오.
• 대역폭이 제한된 패널과 정적인 웨어러블 화면에는 부분 리프레시를 우선 사용하십시오.
• UI 성능을 CPU, ePicasso, 메모리, 디스플레이 컨트롤러, 패널 인터페이스, 터치, 전력 정책이 관련된 시스템 문제로 다루십시오.

최종 업데이트: 2026-10-19