LilyGO T-Display-SF32¶

T-Display-SF32란 무엇인가?¶

Xinyuan-LilyGO/T-Display-SF32는 SF32LB52x MCU와 CST9220 터치를 갖춘 2.16인치 CO5300 AMOLED를 중심으로 구성된 개발 플랫폼입니다. 이 저장소에는 16 MB 플래시, 8 MB PSRAM, BHI260AP IMU, SX1262 LoRa, microSD 인터페이스, 오디오, USB Type-C, 충전 지원, 보드 핀 할당, 예제 애플리케이션, 하드웨어 파일, 공장 출하 펌웨어 디렉터리, 보드 전용 소비 전력 보고서가 문서화되어 있습니다.

이러한 조합 덕분에 이 보드는 디스플레이 중심의 웨어러블, 휴대용 컨트롤러, 휴대용 센서 단말, 연결형 HMI를 평가하는 데 유용합니다. 완성된 제품이 아니라 플랫폼 레퍼런스입니다. 저장소가 많은 하드웨어 경로를 제공하지만, 제품 팀은 여전히 어떤 경로가 중요한지 선택하고, 알려진 기준 구성을 재현하고, 정확한 보드 리비전에서 측정하고, 전력, RF, 안전, 소프트웨어 유지 관리, 복구를 검증해야 합니다.

저장소의 기능 매트릭스는 단독형 T-SF32-Display와 선택적인 T-SF32-Keyboard 확장을 구분합니다. Wi-Fi(ESP32-C6), GPS(L76K), 매트릭스 키보드와 LED(TCA8418, AW21009, XL9555), BME280, 적외선 송신기, 진동 모터(AW86224)는 이 확장이 있어야 하므로 단독형 보드 기준 구성에 포함하지 마십시오.

왜 SF32 구현인가?¶

T-Display-SF32는 SF32LB52x의 그래픽, Bluetooth, 오디오, 저전력 기능을 외부 디스플레이, 터치, 모션, 스토리지, LoRa 디바이스와 한 보드에서 결합합니다. LilyGO는 보드 구성, 전용 디바이스 드라이버, 예제와 함께 SiFli-SDK 2.4.0을 기반으로 한 것으로 설명되는 별도의 LilyGO SDK 포크도 제공합니다. 따라서 수정되지 않은 범용 SDK 타깃에서 시작하는 것보다 초기 보드 브링업 시간을 줄일 수 있습니다.

대신 소유권의 문제가 따릅니다. 보드 지원, 드라이버 변경, 하드웨어 리비전, 번들 펌웨어, LilyGO의 SDK 포크와 업스트림 SiFli-SDK의 관계는 SiFli 밖에서 통제됩니다. 따라서 재현 가능한 프로젝트가 되려면 두 저장소를 모두 커밋 단위로 고정하고, 동작하는 공장 출하/복구 이미지를 보관하고, 더 새로운 업스트림 SDK로의 마이그레이션을 명시적인 엔지니어링 변경으로 테스트해야 합니다.

목표, 범위, 시작 조건¶

목표: 버전이 고정된 T-Display-SF32 기준 구성을 확립하고, 디스플레이/터치, 선택한 주변 장치, 전력 동작, 복구 경로를 검증하고, 소스 빌드를 재현한 다음, 제품 검토에 적합한 회귀 증거와 함께 범위가 제한된 애플리케이션 변경 하나를 수행합니다.

이 페이지는 모든 보드 변형에 모든 주변 장치가 실장되어 있다는 점, 벤더 펌웨어가 양산 수준이라는 점, 전력 보고서가 다른 리비전이나 워크로드에도 적용된다는 점, LoRa 동작이 모든 지역에서 합법이라는 점을 증명하지 않습니다. 또한 SiFli의 지원을 LilyGO 전용 하드웨어나 드라이버로 이전하지도 않습니다.

시작하기 전에 다음을 준비하십시오.

• 회로도 또는 핀 맵을 포함한 정확한 T-Display-SF32 보드와 하드웨어 리비전;
• 전류 제한이 있는 벤치 전원 공급 장치 또는 전압과 상태를 모니터링할 수 있는 보호된 배터리;
• 검증된 USB 데이터 케이블, 문서화된 Type-C 플래싱 연결, 보관해 둔 복구 이미지;
• T-Display-SF32 저장소와 LilyGO의 SDK 포크 모두에 대해 고정된 커밋;
• 최초의 재현 가능한 빌드를 위해 LilyGO SDK 포크가 문서화한 Windows/PowerShell 환경. 다른 호스트 경로는 별도로 검증해야 하는 것으로 취급하십시오;
• microSD 카드, 헤드폰 또는 오디오 부하, 합법적인 대역의 LoRa 상대 장치처럼 범위에 포함된 인터페이스에 필요한 테스트 액세서리만;
• 펌웨어 버전, 빌드 로그, 시리얼 출력, 사진, 전류 측정, 장애/복구 결과의 기록.

하드웨어 및 소프트웨어 사양¶

하드웨어 사양¶

소프트웨어 사양¶

지원되는 기준 구성 선택¶

업스트림 저장소는 현재 master 브랜치를 사용하며, 태그된 릴리스를 공통 소프트웨어 기준 구성으로 제시하지 않습니다. "최신"이라고 적지 말고 정확한 커밋을 기록하십시오. 저장소에는 firmware/T-SF32-Factory-V1.2 디렉터리가 있지만, 그 디렉터리 이름이 일치하는 보드 리비전, 저장소 커밋, 플래시 기록 절차의 기록을 대신하지는 않습니다.

T-Display-SF32 README는 필요한 환경을 구성한 뒤의 Windows 빌드 및 플래싱 경로를 다음과 같이 문서화합니다.

cd T-Display-SF32\examples\rt_os\rt_driver\project
scons --board=t-display-sf32_hcpu -j8
build_t-display-sf32_hcpu\uart_download.bat

실제 저장소와 SDK 커밋, 환경 익스포트 결과, 전체 빌드 로그, 생성된 이미지, 플래싱 로그, 부트 로그를 저장하십시오. 병렬 작업 수는 바꿔도 되지만, 타깃과 소스 리비전은 바꾸면 안 됩니다.

프로젝트 개발 단계와 의사결정 지점¶

시스템 아키텍처와 의존성¶

flowchart LR
    U["사용자\n터치와 버튼"] --> F["T-Display-SF32 펌웨어\nSF32LB52x + RT-Thread"]
    F --> D["CO5300 AMOLED\nCST9220 터치"]
    F --> P["실장된 주변 장치\nIMU, microSD, 오디오, LoRa"]
    B["배터리 / USB Type-C\n충전기와 전원 레일"] --> F
    H["호스트 빌드 및 플래싱 도구"] -->|"UART 플래싱과 로그"| F
    R["LilyGO 보드 저장소"] --> H
    S["LilyGO SDK 포크\nSiFli-SDK에서 파생"] --> H
    O["SiFli 디바이스 및 SDK 소스"] -. "기반 플랫폼 레퍼런스" .-> S

장애를 별개의 영역으로 취급하십시오. 보드 전원/충전, 부팅과 플래싱, 디스플레이/터치, 선택한 각 주변 장치, LilyGO 보드 지원, 기반 SDK입니다. 예를 들어 디스플레이 예제의 실패는 전원, 보드 리비전, 패널/터치 구성, 애플리케이션, SDK/드라이버 불일치 중 어느 것에서든 비롯될 수 있으므로 "SDK가 실패했다"는 것은 충분한 진단이 아닙니다.

1단계 — 수정하지 않은 벤더 기준 구성 확립¶

목표: 소스를 변경하기 전에 받은 보드와 벤더 기준 구성이 실제로 무엇을 하는지 증명합니다.

1. 보드 양면을 촬영하고 마킹, 실장된 주변 장치, 디스플레이/터치 부품, 메모리, 스위치, 커넥터, 저장소 커밋을 기록하십시오.
2. 전원 공급원과 극성을 확인하십시오. LilyGO는 시작에 3.5 V를 초과하는 전압이 필요하다고 경고합니다. 전압을 모니터링할 수 있는 전원을 사용하고, 심하게 방전된 셀을 시험에 사용하지 마십시오.
3. 보드와 일치하는 것으로 확인된 기준 구성만 플래시에 기록하거나, 출처를 알고 있다면 먼저 기존 펌웨어를 실행하십시오. 도구가 허용하면 원래 이미지를 보존하십시오.
4. 로컬 메뉴 또는 수정하지 않은 예제로 디스플레이/터치와 제품에 사용할 각 주변 장치를 점검하십시오. 사용할 수 없거나 실장되지 않은 기능은 실패로 취급하지 말고 그대로 기록하십시오.
5. 콜드 스타트를 두 번 수행하고 부트 로그, UI 사진, 터치/입력 결과, 명확히 정의한 유휴/동작 워크로드 하나의 전류 트레이스를 보관하십시오.

보관할 증거: 보드 리비전과 사진, 저장소/이미지 식별 정보, 전원 및 배터리 상세, 플래시 기록 및 부트 로그, 실장된 디바이스 목록, 기능 결과, 전류 테스트 조건.

게이트 1 종료 기준: 두 번의 콜드 스타트에서 식별된 디스플레이/터치 기준 구성이 재현되고, 범위에 포함된 실장 주변 장치마다 결과가 기록되어 있으며, 원래 이미지 또는 정상 동작이 확인된 이미지를 복원할 수 있습니다.

2단계 — 주변 장치, 전원, 복구 경계 검증¶

목표: 안전하지 않은 배터리 사용이나 문서화되지 않은 재플래싱 없이 장애를 감지하고 복구할 수 있는지 판단합니다.

게이트 2 종료 기준: 해당하는 각 테스트에 반복 가능한 결과와 복구 경로가 있고, 커스텀 펌웨어에는 배터리 부족 보호가 구현되어 있으며, 배터리를 손상시키거나 문서화된 복구 경로 없이 보드를 사용할 수 없게 만들 수 있는 미해결 장애가 없습니다.

3단계 — 재현 가능한 소스 기준 구성 빌드¶

목표: 두 번째 엔지니어가 클린하고 버전이 고정된 소스에서 같은 기준 구성을 만들고 플래시에 기록할 수 있게 합니다.

1. 보드 저장소와 LilyGO SDK 포크의 고정된 커밋을 체크아웃하고 포크가 밝힌 업스트림 SDK 기반을 기록하십시오.
2. 문서화된 PowerShell 환경을 구성하고 클린 디렉터리에서 t-display-sf32_hcpu를 빌드하십시오.
3. 환경, 의존성, 구성, 메모리/파티션, 이미지, 플래싱, 시리얼 로그 증거를 보관하십시오.
4. 다른 머신에서 빌드하거나 모든 빌드 출력을 삭제한 뒤 다시 빌드하고 2단계 회귀 테스트 전체를 수행하십시오.

게이트 3 종료 기준: 2단계를 통과하는 펌웨어를 만드는 데 오래된 이미지, 추적되지 않는 보드 파일, 문서화되지 않은 SDK 대체가 필요하지 않습니다.

4단계 — 한 번에 하나의 제품 경로만 적용¶

목표: 동작하는 벤더 기준 구성과 복구 기준 구성을 보존하면서 유용한 변경 하나를 수행합니다.

게이트 4 종료 기준: 변경 사항이 검토되었고, 원래 이미지를 계속 복원할 수 있으며, 해당하는 모든 디스플레이, 터치, 주변 장치, 전원, 플래시, 복구 테스트가 통과합니다.

5단계 — 제품 준비 상태 검토¶

현장 시험이나 커스텀 PCB를 확정하기 전에 다음 질문에 답하십시오.

• 보드 파일, LilyGO SDK 포크, 드라이버 수정, 보안 업데이트, 이후 SiFli-SDK 버전으로의 마이그레이션은 누가 책임지는가?
• 제품 기준 구성에는 어떤 보드 리비전과 실장된 주변 장치가 포함되며, 입고되는 유닛은 어떻게 식별하고 테스트하는가?
• 의도한 디스플레이 밝기, 무선 듀티 사이클, 스토리지, 센서 구성에서 측정한 동작, 유휴, 슬립, 시작, 종료 전류는 얼마인가?
• 배터리 보호, 충전, 열 동작, 케이스, 커넥터 접근성, 전원이 꺼진 상태에서의 복구는 어떻게 검증하는가?
• 어떤 LoRa 지역, 안테나, 주파수 계획, 송신 파라미터, 규제 의무가 적용되는가?
• 하드웨어 파일, 펌웨어, SDK 포크, 예제, 에셋, 서드파티 구성 요소의 라이선스가 의도한 배포 방식과 호환되는가?
• 팀이 서드파티 프로토타입 의존성을 감수하는가, 아니면 관리되는 포크와 지원 계획을 검증했는가?

게이트 5 종료 기준: 남은 리스크마다 담당자, 증거, 처리 방침이 있으며, 팀이 진행, 보류, 중단 중 하나를 명시적으로 결정했습니다.

제품 설계로의 인계¶

정확한 SF32 부품과 메모리 디바이스, 디스플레이/터치 타이밍, 실장된 주변 장치와 버스, 전원 트리, 충전기와 배터리 정책, 안테나/RF 전략, 부팅/플래싱 연결, 파티션 계획, 양산 테스트 접근성, 소프트웨어 포크 소유권, 검증된 복구 경로를 가져가십시오. SF32LB52x 통합 경로, SF32LB52x 하드웨어 설계 가이드, SiFli-SDK 빌드, 플래시, 모니터, 양산 설계로 이어서 진행하십시오.

주요 정보 출처¶

• Xinyuan-LilyGO/T-Display-SF32 저장소
• T-Display-SF32 중국어 README
• T-Display-SF32 예제
• T-Display-SF32 하드웨어 파일
• T-Display-SF32 전력 테스트 자료
• Xinyuan-LilyGO/SlFli-SDK-Lilygo 저장소
• OpenSiFli/SiFli-SDK

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