제품 검증¶

이 튜토리얼은 연결된 서브시스템의 내용을 익힌 상태를 전제로 합니다. 주변 장치를 브링업해 미들웨어에 연결할 수 있고, 공존 문제도 한 번 이상 직접 경험했어야 합니다. 이 트랙에서는 동작하는 데모를 실제 출시 가능한 제품으로 발전시키는 데 필요한 작업을 다룹니다. 측정 기반 전력 최적화, 복구 가능한 OTA, 커스텀 하드웨어 브링업, 크래시 분석, 다중 연결 Bluetooth, 재사용 가능한 드라이버가 여기에 포함됩니다.

제품 검증은 예제 하나를 그대로 따라 하는 데 그치지 않고 검증 근거를 쌓는 과정입니다. 각 튜토리얼에서 보드 리비전, SDK 버전, 기반 예제, 테스트 환경, 기대 결과, 관찰 결과, 변경 내용을 기록하십시오.

기능이 한 번 동작하는 것만으로 충분하지 않고 제품 수준의 책임을 져야 할 때 이 시리즈를 활용하십시오. 전력 동작을 측정하고, 업데이트를 복구 가능하게 만들며, 커스텀 하드웨어 브링업을 재현하고, 정상 동작 경로를 벗어난 장애의 원인을 입증해야 하는 경우에 적합합니다.

예제 경로와 지원 보드는 SDK 릴리스에 따라 달라질 수 있습니다. 빌드하기 전에 각 예제의 최신 Supported Platforms 목록과 보드별 하드웨어 및 구성 요구 사항을 확인하십시오. 한 실습이 지원된다고 해서 다른 실습이나 모든 기능 조합까지 지원되는 것은 아닙니다.

저전력 모드와 웨이크업 소스 튜닝¶

목표: 펌웨어가 슬립 함수를 호출한다는 이유로 저전력이라고 가정하는 대신, 실제 배터리 수명에 대한 증거를 확보합니다.

소요 시간: 2시간 이상, 측정 환경 구성 별도

시작 위치: example/pm/classical, example/pm/raise_wrist

저전력 설계 개요에 설명된 대로 전류 측정 환경을 구성하십시오.
부팅, 활성, 연결 상태 유휴, 디스플레이 꺼짐 유휴, 가능한 경우 Deep Sleep에 대한 기준값을 기록하십시오.
classical PM 예제에서 rt_pm_request(PM_SLEEP_MODE_IDLE)가 IDLE보다 깊은 모드로의 진입을 막는 위치와, 이에 대응하는 rt_pm_release(PM_SLEEP_MODE_IDLE)가 제한을 해제하는 위치를 찾으십시오. 주변 장치가 활성 상태일 때 드라이버 프레임워크가 슬립 진입을 자동으로 막는지도 확인하십시오.
raise-to-wake 예제로 넘어가 가속도계 샘플링, 손목 제스처 인식, 디스플레이 웨이크업, 슬립 복귀 과정을 살펴보십시오. 예제의 실제 샘플링 및 웨이크업 시퀀스를 확인하고, 인터럽트를 사용한다고 단정하지 마십시오.
같은 전력 절감 원칙을 제품에도 적용하십시오. 하드웨어와 드라이버가 지원하면 인터럽트나 이벤트 기반 작업을 사용해 불필요한 타이머와 폴링 루프를 줄이십시오.
변경할 때마다 다시 측정하십시오.
Deep Sleep이 기대만큼 깊지 않으면 list_thread, list_device, PM 로그, 웨이크업 소스 계측을 사용해 계속 활성 상태인 서브시스템을 찾으십시오.

성공 기준: 펌웨어가 기대한 저전력 상태에 도달하고, 측정할 때마다 전류 값이 재현 가능하며, 웨이크업 소스가 의도적으로 설정되어 있습니다.

문제 해결: 전류가 한 번은 낮게 측정되었는데 이후 높아지면 오류 경로, 재연결 경로, 디스플레이와 오디오 세션의 종료 처리, 시작 후 생성된 타이머를 확인하십시오.

배운 내용: "저전력일 것"이라는 추정에서 측정으로 확인된 저전력으로 나아가는 방법과, 해제되지 않은 채 남아 있는 PM 요청을 추적하는 방법입니다.

BLE를 통한 OTA 펌웨어 업데이트 추가¶

목표: 유선 연결 없이 현장에서 펌웨어를 업데이트합니다.

소요 시간: 2시간

시작 위치: example/ble/peripheral_with_ota

OTA가 활성화된 페리퍼럴 예제를 빌드하고 플래시에 기록하십시오.
업데이트를 시도하기 전에 일반 BLE 페리퍼럴 동작이 여전히 동작하는지 확인하십시오.
OTA 업데이트를 시작하고 디바이스가 새 이미지로 부팅하는지 확인하십시오.
문서화된 복구 경로가 있는 테스트 유닛에서 전송 중 연결 해제나 통신 범위 이탈 같은 중단 상황을 한 번에 하나씩 재현하십시오. 전원 차단은 보드 문서와 제품 복구 설계 모두에서 해당 테스트가 안전하다고 명시한 경우에만 하십시오.
중단되거나 거부된 업데이트 이후 이 제품이 실제로 구현한 동작(재시도, 이어받기, 복구 모드, 롤백 등)을 확인하십시오. 부트 및 파티션 설계가 롤백을 구현한 경우에만 롤백을 요구 사항으로 취급하십시오.
오래되었거나 유효하지 않은 본딩 정보, 휴대폰에서 페어링 정보를 삭제한 경우, 디바이스 재부팅 후에도 OTA를 테스트하십시오.
제품이 이미 데이터 전송에 PAN을 사용한다면 PAN OTA 경로를 별도의 설계 선택지로 평가하십시오.

성공 기준: 성공한 업데이트는 새 이미지로 부팅하고, 중단되거나 거부된 업데이트는 제품의 문서화된 복구 정책을 따르며, 사용자가 디바이스가 어떤 상태에 도달했는지 알 수 있습니다. 모든 OTA 설계가 롤백을 지원한다고 가정하지 마십시오.

문제 해결: 파티션 레이아웃, 사용하는 경우 이미지 서명 또는 무결성 검사, 부트 선택 및 복구 동작, 구현된 경우 롤백 지원, 전송 중 연결 파라미터, 본딩 또는 스토리지 변경이 업데이트 후에도 유지되는지 확인하십시오.

배운 내용: 파티션 레이아웃, 이미지 검증, 부트 선택, 복구 정책이 OTA 동작을 어떻게 결정하는지, 그리고 업데이트가 한 번 성공했다고 해서 중단된 업데이트를 복구할 수 있다는 것이 입증되지는 않는 이유입니다.

커스텀 디스플레이 모듈 브링업¶

목표: 기본 지원되는 레퍼런스 패널을 사용하는 대신 새로운 LCD, AMOLED, EPD 또는 메모리 디스플레이를 포팅합니다.

소요 시간: 3시간 이상

시작 위치: 패널에 맞게 수정할 SDK의 가장 유사한 기존 디스플레이 드라이버

패널 데이터시트, 초기화 시퀀스, 타이밍 파라미터, 인터페이스 유형, 리셋 요구 사항, 전원 시퀀스를 수집하십시오.
선택한 SF32 디바이스와 패키지가 필요한 인터페이스와 핀 배치를 지원하는지 확인하십시오.
가장 유사한 기존 디스플레이 드라이버를 복사하고 패널별 초기화 시퀀스와 레지스터 맵을 교체하십시오.
단색 채우기부터 브링업하십시오. 패널이 단순한 패턴을 표시할 수 있을 때까지 LVGL 위젯을 디버깅하지 마십시오.
색상 순서, 바이트 순서, 방향, 주소 윈도우, 부분 업데이트 동작을 확인하십시오.
연결된 서브시스템의 실습 2에서 LVGL을 다시 추가하십시오.
선택한 칩, 디스플레이 경로, 드라이버, SDK가 지원하는 경우 DMA, 부분 리프레시, ePicasso 가속을 한 번에 하나씩 활성화하십시오.
디스플레이 끄기, 슬립, 웨이크업, 재초기화 경로를 테스트하십시오.

성공 기준: 콜드 부트와 리셋 이후 패널이 안정적으로 초기화되고, 알려진 패턴을 올바르게 렌더링하며, 슬립/웨이크업 후에도 깨짐이 없습니다.

문제 해결: 채우기가 잘못되면 UI 코드를 수정하기 전에 픽셀 포맷, MADCTL/방향 비트, 바이트 순서, 커맨드/데이터 배선, 리셋 타이밍, 전원 레일 시퀀싱을 확인하십시오.

배운 내용: 전기적/시퀀스 정확성을 UI 프레임워크 구성과 분리하는 방법입니다.

CPU 사용률 프로파일링과 크래시 분석¶

목표: 라이브 디버거에서 편하게 재현되지 않는 문제를 디버깅합니다.

소요 시간: 2시간

시작 위치: example/system/cpu_usage_profiler, example/system/coredump

연결된 서브시스템의 복합 워크로드 하나를 대상으로 CPU 사용률 프로파일러 예제를 실행하십시오.
어떤 태스크가 CPU 시간을 사용하는지 확인하고, 그 결과가 예상과 일치하는지 살펴보십시오.
연습용 브랜치나 폐기해도 되는 예제에 의도적인 오류를 추가하고 코어 덤프를 캡처하십시오.
SDK의 덤프 분석 도구로 오류가 발생한 함수와 콜 스택을 찾으십시오.
크래시 시점의 상태를 list_thread, 로그, 최근 이벤트와 비교하십시오.
의도적인 오류를 제거한 뒤, 간헐적으로 발생하는 실제 문제가 있다면 같은 절차를 반복하십시오.

성공 기준: 추측이 아니라 캡처한 증거로 성능 문제와 크래시를 모두 설명할 수 있습니다.

문제 해결: 콜 스택을 해석하기 전에 심볼이 플래시에 기록된 바이너리와 일치하는지, 로그에 펌웨어 버전이 포함되는지, 최적화 수준을 파악했는지 확인하십시오.

배운 내용: 느린 경로에 대한 사전 프로파일링과, 라이브로 잡기 어려운 장애에 대한 사후 덤프 분석입니다.

다중 연결 BLE 제품 구축¶

목표: 둘 이상의 BLE 역할 또는 연결을 동시에 지원합니다.

소요 시간: 2시간

시작 위치: example/ble/central_and_peripheral, example/ble/multi_connection

연결된 서브시스템의 실습 3에서 구현한 페리퍼럴 동작을 출발점으로 삼으십시오.
여기에 센트럴 역할을 추가하십시오. 예를 들어 휴대폰에는 페리퍼럴로 연결되고 센서 액세서리에는 센트럴로 연결되도록 구성할 수 있습니다.
여러 연결을 동시에 처리하도록 확장하십시오.
각 링크의 연결 간격, 슬레이브 지연 시간(slave latency), 감독 타임아웃(supervision timeout), 알림 전송 속도를 기록하십시오.
애플리케이션 코드를 의심하기 전에 SDK 처리량 예제로 기준값을 측정하십시오.
재연결, 휴대폰 슬립, 액세서리 연결 끊김, 동시 알림 폭주를 테스트하십시오.

성공 기준: 의도한 모든 역할이 안정적으로 연결, 해제, 재연결되며, 복합 동작 상황에서도 연결 파라미터 선택이 안정적으로 유지됩니다.

문제 해결: 호환되지 않는 파라미터 요청, 과도한 알림 트래픽, 애플리케이션 콜백의 블로킹, 링크 이벤트마다 메인 CPU를 깨우는 전력 정책을 확인하십시오.

배운 내용: 지원되는 SiFli-SDK BLE 구성에서는 페리퍼럴과 센트럴 역할을 함께 사용할 수 있고, 일부 구성은 여러 링크를 동시에 지원합니다. 대상 칩, 스택 구성, 예제에서 지원하는 역할과 연결 수 제한을 확인하십시오. 여러 링크가 무선 스케줄을 공유하면 연결 파라미터의 트레이드오프가 누적됩니다.

커스텀 RT-Thread 디바이스 드라이버 작성¶

목표: 기존 SDK 드라이버가 없는 주변 장치를 애플리케이션 코드에 임시로 덧붙이는 대신 정식 RT-Thread 디바이스로 통합합니다.

소요 시간: 3시간 이상

시작 위치: SDK 애플리케이션 개발 안내와 가장 유사한 기존 드라이버

SDK가 보드 정의, 핀 먹스, 클럭, 주변 장치 드라이버를 어떻게 구성하는지 살펴보십시오.
아키텍처가 대상 주변 장치와 가장 유사한 기존 드라이버에서 시작하십시오.
버스 접근, 디바이스 등록, 구성, 애플리케이션 로직을 분리하십시오.
디바이스를 등록하고 list_device에 표시되는지 확인하십시오.
이전 튜토리얼에서 ADC, PWM, I2C, 스토리지 디바이스를 다룬 방식대로 사용해 보십시오.
하드웨어 누락, 잘못된 인자, 타임아웃, 서스펜드/재개에 대한 오류 처리를 추가하십시오.
드라이버를 재사용할 수 있다면 제품마다 복사해 붙이는 대신 SDK 컴포넌트로 패키징하십시오.

성공 기준: 애플리케이션 코드가 일반적인 RT-Thread 디바이스 모델을 통해 드라이버를 찾아 사용할 수 있으며, 드라이버가 초기화, 사용, 오류, 슬립/웨이크업 경로 전반에서 예측 가능하게 동작합니다.

문제 해결: 드라이버가 한 애플리케이션 파일에서만 동작한다면 디바이스 모델을 우회하고 있을 가능성이 큽니다. 내장 디바이스처럼 느껴질 때까지 리팩터링하십시오.

배운 내용: 유지 관리 부담을 만들지 않고 SDK 에코시스템을 깔끔하게 확장하는 방법입니다.

제품 검증 릴리스 체크리스트¶

전력 수치가 측정되었고 반복 가능하며 명명된 테스트 시나리오와 연결되어 있습니다.
OTA 성공, 무결성 검사, 중단 복구를 제품의 문서화된 정책에 맞게 테스트했습니다. 롤백은 설계가 구현한 경우에만 검증합니다.
커스텀 디스플레이 브링업은 LVGL의 복잡성을 더하기 전에 패턴으로 검증했습니다.
프로파일링과 코어 덤프 워크플로가 팀을 위해 문서화되어 있습니다.
다중 연결 Bluetooth를 재연결 및 휴대폰/액세서리 예외 상황 전반에서 테스트했습니다.
커스텀 드라이버는 RT-Thread 디바이스 모델을 사용하며 슬립/웨이크업을 처리합니다.
복합 부하 테스트에 해당하는 경우 디스플레이, Bluetooth, 스토리지, 오디오, 센서, AI를 포함합니다.

다음 단계¶

이제 주변 장치와 미들웨어 통합, 공존 문제 파악, 전력 관리, OTA, 커스텀 하드웨어 브링업, 사후 디버깅, 드라이버 통합에 필요한 역량을 갖췄습니다. 이후에는 예제 카탈로그와 그래픽 개요를 지속적인 참고 자료로 활용하십시오. 순서대로 훑기보다 필요한 기능을 기준으로 찾아보십시오.

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