저전력 설계 개요¶

목적과 범위¶

이 가이드는 SF32 디바이스의 실무적인 저전력 설계를 다룹니다. 전원 모드, 배터리를 실제로 소모하는 요인, 그리고 시스템이 최대한 오랜 시간을 저전력 상태로 보내도록 펌웨어를 구성하는 방법을 설명합니다. 전력은 시스템 수준의 문제입니다. Bluetooth, 그래픽, 오디오, AI에 관한 결정이 모두 소비 전력에 영향을 미치므로, 이 가이드에서 이러한 영향을 함께 정리합니다.

SiFli SDK 문서는 SF32LB52x를 포함한 특정 타깃에 대해 RT-Thread 기반 PM(Power Management) 미들웨어를 설명합니다. 사용 가능한 모드와 웨이크업 동작은 디바이스와 SDK 구성에 따라 다를 수 있으므로, 대상 디바이스의 문서를 확인하십시오. 선택한 SDK가 Bluetooth 컨트롤러 작업을 별도의 프로세서에 할당하는 제품군에서는(Bluetooth 프로세서 참조), 무선 이벤트가 있을 때마다 애플리케이션 CPU를 깨우지 않고 처리할 수 있습니다. 애플리케이션 CPU가 계속 슬립 상태를 유지할 수 있는지는 태스크 배치, 구성된 웨이크업 소스, 프로세서 간 트래픽에 따라 달라지므로 대상 디바이스에서 확인하십시오.

배터리 수명 목표를 측정된 근거가 있는 펌웨어 및 하드웨어 결정으로 옮겨야 할 때 이 페이지를 사용하십시오. 이 페이지는 connected standby, 디스플레이 동작, 오디오, 센싱, AI, 사용자 응답성 사이에서 균형을 잡아야 하는 엔지니어를 위한 것이며, 슬립을 API 호출 한 번으로 다루려는 경우를 위한 것이 아닙니다.

제품의 전력 예산을 먼저 정의하기¶

전원 관리 코드를 작성하기 전에, 제품에서 "좋은 상태"가 무엇인지 정의하십시오.

• 목표 배터리 수명(시간, 일 또는 주 단위)과 배터리 용량.
• 예상 듀티 사이클: 하루 중 디바이스를 능동적으로 사용하는 시간, 연결된 상태로 대기하는 시간, 완전히 슬립 상태인 시간의 비율.
• 시스템을 깨워야 하는 이벤트는 무엇이며, 얼마나 빨리 깨워야 하는지.
• 지속적으로 동작해야 하는 서브시스템(예: 연결된 Bluetooth 링크, 상시 켜짐(always-on) 디스플레이, 음성 트리거)과 완전히 이벤트 구동으로 동작할 수 있는 서브시스템은 각각 무엇인지.
• 제품의 전력 정책과 관련이 있다면 충전 동작과 예상 충전 횟수.

이러한 목표가 칩 선택, 디스플레이 종류, 상시 음성 청취나 상시 켜짐 디스플레이 같은 기능을 전력 예산 안에서 감당할 수 있는지 여부를 포함하여, 초기에 아키텍처 결정을 이끄는 것이 좋습니다.

전원 모드와 PM 프레임워크¶

다음은 개념적인 시스템 상태이며, SF32 하드웨어 모드나 SDK enum 값의 정확한 목록이 아닙니다. 지원되는 모드, 웨이크업 소스, 리텐션 동작은 선택한 디바이스와 SDK 문서에서 확인하십시오.

실제 작업이 시스템을 상태 사이에서 이동시킵니다. 구성된 웨이크업 소스가 CPU 또는 서브시스템을 저전력 상태에서 깨웁니다. 웨이크업 및 클럭 복원 시퀀스는 디바이스마다 다릅니다. 작업이 끝나면 해당 드라이버나 태스크는 슬립 진입을 막는 PM 요청을 해제하는 것이 좋으며, 그래야 구성된 정책이 조건을 충족하는 저전력 상태를 선택할 수 있습니다. 아래 트레이스는 설명용입니다. 상대적인 전이를 보여 줄 뿐이며, 디바이스별 전류 값이나 타이밍을 나타내지 않습니다.

그림: 짧은 워크로드 동안의 전원 모드 전이(설명용)

전원 모드 선택과 슬립 억제는 별개입니다. SiFli의 SF32LB52x PM 미들웨어 레퍼런스와 SF32LB55x 저전력 가이드에 따르면, rt_pm_request(PM_SLEEP_MODE_IDLE) 호출은 그에 대응하는 rt_pm_release(PM_SLEEP_MODE_IDLE) 호출이 있을 때까지 LIGHT, DEEP, STANDBY 진입을 막습니다. 이 요청이 더 깊은 모드를 선택하는 것은 아닙니다.

구현할 때는 대상 제품군의 공식 저전력 가이드를 사용하십시오: SF32LB52x, SF32LB55x, SF32LB56x, SF32LB58x. 모드 가용성, 진입 조건, 웨이크업 소스, 리텐션 동작은 칩 제품군, 보드, SDK 구성에 따라 달라집니다. SF32LB52x 저전력 가이드에는 58x/56x/52x/57x를 명시적으로 묶어 설명하는 Hibernate 웨이크업 핀 예제가 있으며, 공통 SDK HAL PMU API 레퍼런스는 SF32LB57x에 대한 HAL_PMU_EnablePinWakeup() 인덱스 범위를 0부터 13까지로 명시합니다. 이 자료들이 입증하는 것은 이 웨이크업 핀 구성뿐이며, 52x의 RT-Thread 모드 가용성, 정책 임계값, 리텐션 동작이 57x에도 적용된다는 것을 입증하지는 않습니다. 이러한 사항은 대상 SDK와 디바이스 문서에서 확인하십시오. 일반적으로 구성된 정책은 유휴 구간과 기타 진입 조건이 허용할 때만 조건을 충족하는 더 깊은 상태를 선택할 수 있습니다. 해제되지 않은 요청은 시스템을 의도한 것보다 얕은 상태에 머물게 할 수 있습니다.

SF32 제품에서 전력을 소모하는 요인¶

서브시스템마다 전력 특성이 다릅니다.

이 모든 요인을 한 번에 해결하는 방법은 없습니다. 실제 제품의 전력 최적화는 각 서브시스템의 기여분을 조정한 다음 합산된 효과를 검증하는 일입니다. 서브시스템들이 "얼마나 깊이 슬립할 수 있는가"라는 같은 결정을 두고 경쟁하기 때문입니다.

슬립을 고려한 펌웨어 설계¶

가장 큰 전력 절감은 대개 정교한 저수준 기법이 아니라 펌웨어 구조에서 나옵니다.

• 폴링보다 인터럽트와 이벤트를 우선하십시오. 폴링 루프는 할 일이 없을 때도 CPU를 활성 상태로 유지합니다.
• 작업을 묶어서 처리하십시오. 지연 시간이 허용하는 범위에서는 센서 샘플, Bluetooth 이벤트, 오디오 블록을 모아 한꺼번에 처리하고, 하나씩 개별적으로 깨어나지 마십시오.
• 슬립을 막는 PM 요청을 즉시 해제하십시오. 더 깊은 저전력 상태로의 진입을 막는 PM 요청을 보유한 드라이버나 태스크는, 막을 필요가 없어지는 즉시 대응하는 요청을 해제하는 것이 좋습니다. 해제되지 않은 요청은 시스템을 의도한 것보다 얕은 상태에 머물게 할 수 있습니다.
• 프레임워크가 허용하는 한 UI 경로와 오디오 경로를 타이머 폴링이 아니라 이벤트 구동으로 설계하십시오.
• 타이머를 점검하십시오. 주기 타이머는 향후 작업을 예약하며, 시스템을 깨우거나 PM 정책이 사용할 수 있는 유휴 구간을 제한할 수 있습니다. 따라서 무해해 보이는 타이머 여러 개가 더 깊은 저전력 상태에 머무는 시간을 줄일 수 있습니다.

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

제품 배터리 수명을 추정하기 전에, 가장 불확실한 전력 경계를 확인해 주는 SDK 예제를 선택하십시오. 저전력 SDK 예제는 공식 PM, GPIO, 프로세서, Bluetooth, 디스플레이, GUI, 화면 리프레시, raise-to-wake 프로젝트를 각각이 입증하는 시나리오와 대응시켜 정리합니다. 또한 예제를 제품 근거로 사용하기 전에 어떤 전원 연결, 보드, 구성, 웨이크업 소스, 외부 회로, 워크로드 가정을 다시 검증해야 하는지도 설명합니다.

Bluetooth 전력 튜닝¶

연결 파라미터와 광고 파라미터는 Bluetooth 전력을 좌우하는 주된 수단입니다(Bluetooth 개요의 전체 표 참조).

• 대부분 유휴 상태인 링크에서는 연결 간격과 슬레이브 지연 시간을 늘리십시오.
• 요구되는 통신 거리를 충족하는 가장 낮은 수준으로 TX 전력을 줄이십시오.
• 제품이 최초 검색이 아니라 재연결을 기대하는 단계가 되면 광고를 덜 공격적으로 수행하십시오.
• 선택한 SDK가 Bluetooth 컨트롤러 이벤트를 별도의 프로세서에서 처리하는 경우, 애플리케이션 태스크, 웨이크업 소스, 프로세서 간 메시지가 필요로 하지 않는다면 애플리케이션 CPU는 연결 이벤트 사이에 슬립할 수 있습니다. 모든 Bluetooth 콜백마다 애플리케이션 CPU를 깨우면 이 이점이 줄어들 수 있으므로, 대상 디바이스의 코어/태스크 분할을 확인하십시오.

Classic Bluetooth만 사용하는 경우, BLE만 사용하는 경우, 둘을 듀얼 모드로 함께 사용하는 경우의 실제 소비 전력을 시나리오별로 측정하는 실용적인 방법은 Bluetooth 저전력 프로파일링을 참조하십시오.

디스플레이와 백라이트 전력¶

디스플레이와 백라이트는 웨어러블이나 휴대용 제품에서 단일 항목으로는 가장 큰 전력 소모원인 경우가 많습니다.

• 패널과 UI가 허용하는 경우 전체 화면 재렌더링 대신 부분 리프레시와 dirty-region 업데이트를 사용하십시오(디스플레이 컨트롤러: 부분 리프레시 참조).
• 사용하지 않는 상태가 되면 디스플레이 밝기를 낮추거나 해당하는 경우 백라이트를 끄십시오. 화면이 어두워졌거나 가려졌을 때는 애니메이션을 중지하십시오.
• 상시 켜짐 디스플레이 제품에서는 EPD, JDI/memory-in-pixel, AMOLED, TFT 같은 패널을 측정된 상시 동작 에너지와 요구되는 사용자 경험을 기준으로 비교하십시오. 일반적인 활성 디스플레이 모드를 계속 켜 두기보다는, 예산에 맞는 패널과 동작 정책을 선택하십시오.
• "상시 켜짐 디스플레이"는 "유휴"의 의미 자체를 근본적으로 바꾸므로, 별도의 전력 예산 항목으로 취급하십시오.

AI 및 센서 전력 튜닝¶

온디바이스 추론과 센서 샘플링은 계속 실행하지 말고 의도적으로 스케줄링하는 것이 좋습니다.

• 입력 활동과 무관하게 고정된 타이머로 실행하지 말고, 새롭고 유용한 데이터가 있을 때만 추론을 실행하십시오.
• 디바이스와 SDK가 지원하는 경우, 가벼운 상시 센싱은 샘플마다 메인 애플리케이션 CPU를 깨우지 말고 저전력 프로세서로 옮기십시오.
• 지연 시간만이 아니라 추론당 또는 샘플당 에너지를 측정하십시오. 더 빠른 동작이 전력에 도움이 되는 것은 시스템이 더 일찍 슬립으로 돌아갈 수 있을 때뿐입니다.

정확도, 지연 시간, 전력 사이의 트레이드오프는 AI 개요에서 더 자세히 다룹니다.

메모리와 클럭 고려 사항¶

코드가 어디에서 실행되는지는 성능과 전력 모두에 중요합니다. 관련 캐시 기능을 구현하고 활성화한 SF32 디바이스에서는, 명령어 캐시와 데이터 캐시가 플래시나 PSRAM 접근 때문에 지연되는 시간을 줄일 수 있으며, 활성 시간이 짧아지면 슬립에 쓸 수 있는 시간이 늘어날 수 있습니다. 캐시와 메모리 시스템 관련 고려 사항은 STAR-MC1을 참조하십시오.

CPU 자체 외에도 다음을 고려해야 합니다.

• 외부 PSRAM과 플래시에는 각각 고유한 활성/대기 전력 특성이 있습니다. 특히 큰 버퍼가 슬립 중에도 유효해야 한다면 리텐션 전력과 접근 전력을 데이터시트에서 확인하십시오.
• 클럭 소스 선택(크리스털 대 내부 오실레이터, 그리고 어떤 PLL/클럭 도메인을 활성 상태로 유지할지)은 웨이크업 지연 시간과 슬립 상태 전력 소모에 모두 영향을 줍니다.
• 부하가 덜한 구간에서 CPU 주파수를 낮추면 도움이 될 수 있지만, 활성 시간이 늘어나 이점이 상쇄되지 않는지 확인하십시오. 순간 전류가 아니라 실제 에너지를 측정하십시오.

하드웨어 및 RF 전력 고려 사항¶

펌웨어 정책은 하드웨어가 허용하는 범위 안에서만 작동할 수 있습니다.

• PMIC/LDO 효율은 관련 없는 부하 지점에서의 대표 효율 수치보다, 제품이 실제로 소모하는 부하 전류에서의 효율이 더 중요합니다.
• RF 레이아웃과 안테나 튜닝은 안정적인 통신 거리를 위해 실제로 필요한 TX 전력에 영향을 줍니다. RF 설계가 부실하면 펌웨어가 더 높은 TX 전력으로 보상해야 하며, 이는 배터리 수명을 희생시킵니다. Bluetooth 프로세서: RF 및 클럭 고려 사항을 참조하십시오.
• 크리스털 정확도는 RF 타이밍 마진과, 펌웨어가 감독 타임아웃(supervision timeout)과 웨이크업 마진을 얼마나 보수적으로 설정해야 하는지에 모두 영향을 줍니다.
• 설계에 양산 테스트/캘리브레이션 접근 수단을 남겨 두십시오. 전력 및 RF 튜닝은 첫 하드웨어 리비전 이후에도 계속되는 경우가 많습니다.

사례 연구: Raise-to-Wake¶

사용자가 손목을 들어 올릴 때 디스플레이를 깨우는 것은 흔한 웨어러블 사용 사례이지만, 구현은 센서, 보드, SDK에 따라 달라집니다. SiFli의 SF32LB52x raise-wrist 예제는 sf32lb52-lchspi-ulp 보드를 대상으로 하며, LSM6DSL 가속도계/자이로스코프를 사용해 200 ms마다 가속도를 샘플링하여 손목 올림 및 손목 내림 제스처를 인식합니다. 10초 동안 활동이 없으면 슬립에 들어가고, 올림 제스처가 감지되면 깨어나 디스플레이를 켭니다. 이것은 보드에 특화된 구현 하나일 뿐이며, 다른 타깃이 센서 인터럽트나 동일한 PM 동작을 사용한다는 근거가 아닙니다. 대상 센서가 모션 또는 임계값 인터럽트를 지원한다면, 펌웨어가 이를 구성된 웨이크업 소스로 사용하여 애플리케이션 CPU의 지속적인 폴링을 피할 수 있습니다. 그렇지 않다면 센서 샘플링과 CPU 웨이크업을 전력 예산에 포함하십시오. 실제 타깃의 센서, 보드, 웨이크업 소스, PM 구성을 확인하십시오.

전력 예산 워크시트¶

펌웨어를 튜닝하기 전에 제품 목표를 숫자로 바꾸십시오. 대개 간단한 워크시트면 충분합니다.

서로 배타적인 동작 상태에서는 average current = state current x duty cycle로 추정한 다음 상태별 기여분을 합산하십시오. 부하가 동시에 동작한다면, 겹치는 상태를 이중으로 계산하지 말고 시나리오 총합에 포함하십시오. 이렇게 하면 설계 문제를 일찍 드러낼 수 있습니다. 밝은 백라이트나 고정 간격 추론 루프가 활성 상태로 너무 오래 유지되는 제품은, 20 μA의 슬립 목표를 달성해도 구제되지 않습니다.

전력 프로파일링: 모델링, 측정, 업데이트¶

전력 프로파일링은 예산을 반복 가능한 엔지니어링 루프로 바꿉니다. 대표적인 제품 시나리오를 정의하고, 관련 전원 경계에서 전압과 전류를 기록하며, 각 부하의 지속 시간과 빈도를 반영하십시오. 시간에 따른 에너지를 계산하고, 변환 손실을 포함하여 레일 수준의 측정값을 배터리 측 소비량과 대조하십시오. 서로 다른 전압의 레일 전류를 그대로 더해서는 안 됩니다. 그 결과로 평균 배터리 측 전류, 일일 충전량 소비, 배터리 수명을 추정할 수 있고, 먼저 측정하고 최적화해야 할 시나리오의 우선순위를 정할 수 있습니다.

flowchart LR
    A["대표적인 제품 시나리오 정의"] --> B["전류, 전압, 지속 시간, 빈도 가정 설정"]
    B --> C["이벤트당, 하루당 에너지 계산"]
    C --> D["배터리 예산과 비교하고 기여 요인의 순위 지정"]
    D --> E["대상 하드웨어에서 우선순위 시나리오 측정"]
    E --> F["측정한 전류와 타이밍으로 모델 업데이트"]
    F --> B

프로파일은 계측기가 아니라 추정치로 취급하십시오. Nordic의 Bluetooth LE 온라인 전력 프로파일러도 같은 원칙을 따릅니다. 이 도구는 측정에서 도출한 모델에 기반하지만, 출력은 특정 제품의 측정값이 아니라 기댓값에 머뭅니다. 전류는 실리콘, 보드 설계, 배터리 전압, 온도, RF 조건, 펌웨어 타이밍, 사용 사례에 따라 달라질 수 있습니다.

모든 시나리오에 대해, 에너지에 실질적인 영향을 주는 가정을 기록하십시오.

• 어떤 서브시스템이 켜져 있으며, MCU는 실제로 어떤 전원 모드로 진입하는가?
• 배터리 입력 또는 각 레귤레이션된 레일에서의 전류는 얼마인가?
• 작업은 얼마나 오래 지속되며, 일반적인 하루에 얼마나 자주 발생하는가?
• 어떤 전류 스파이크는 예상된 것이고, 어떤 것은 의도하지 않은 작업이나 놓친 슬립을 나타내는가?

추정치로 가장 큰 예산 항목을 파악한 다음, 배터리 수명을 주장하기 전에 해당 시나리오를 하드웨어에서 검증하십시오. 스마트워치 전력 프로파일링 문서는 이 방법을 일일 사용 모델에 적용하여 단계별로 설명하며, 전력 측정과 검증은 반복 가능한 캡처 워크플로를 정의합니다.

PM 소유권과 웨이크업 소스 검토¶

신뢰할 수 있는 저전력 설계에는 모든 웨이크업 소스와 모든 PM 요청에 대한 명확한 소유자가 필요합니다. 설계 검토에서 다음 항목을 추적하십시오.

디버깅하는 동안 구성된 PM 정책, 더 깊은 모드를 막는 활성 요청, 대상 SDK나 로그가 보고한 마지막 저전력 모드를 기록하십시오. 시스템이 예상보다 얕은 상태에 도달했다면, 이 증거가 전류 측정값만 보는 것보다 더 유용한 경우가 많습니다.

실제 전력 측정¶

추측하지 말고 측정하십시오. 기본적인 전력 검증 환경은 다음을 포함합니다.

• 배터리/전원과 보드 사이의 전류 프로브 또는 인라인 전력 분석기.
• 실제 제품 사용과 일치하는 테스트 시나리오: connected-idle, 활성 UI 상호작용, 오디오 재생, AI 추론 버스트, 최악의 복합 부하.
• 전류 스파이크를 특정 코드 경로로 귀속시킬 수 있도록, 전력 트레이스와 함께 펌웨어 상태(active/idle/sleep)를 로깅하거나 표시하는 것.

SiFli SDK 문서는 AMOLED 및 JDI 디스플레이, GPIO, BLE/Classic Bluetooth, CoreMark 방식 CPU 부하 같은 시나리오를 다루는 전력 특성 측정 예제를 일부 디바이스와 보드에 대해 제공합니다. 제공 여부와 설정 방법은 대상 SDK 및 보드 문서에서 확인하십시오. 해당하는 예제는 측정 템플릿과 타당성 확인용으로 사용하고, 제품별 전력 보증으로 사용하지 마십시오.

전력 검증 매트릭스¶

펌웨어 리비전 사이에 개선 효과를 비교할 수 있도록 반복 가능한 테스트 시나리오를 사용하십시오. 최소한 다음을 측정하십시오.

펌웨어 버전, 보드 리비전, 배터리/전원 전압, 온도, 안테나/외장 구성, 테스트 스크립트를 기록하십시오. 이 메타데이터가 없으면 전력 수치를 비교하기 어렵고 잘못 해석하기 쉽습니다.

높은 소비 전력 디버깅¶

흔한 실수¶

• 전력 최적화를 첫날부터의 설계 제약이 아니라 마지막 다듬기 단계로 취급하는 것.
• 인터럽트와 이벤트를 사용하지 않고 센서, Bluetooth 상태, 타이머를 폴링하는 것.
• 필요했던 작업이 끝난 뒤에도 PM 요청을 활성 상태로 남겨 두는 것.
• 작은 UI 변경에도 전체 화면을 다시 그리는 것.
• RF 레이아웃 품질을 무시하고 펌웨어에서 더 높은 TX 전력으로 보상하는 것.
• 현실적인 사용 시나리오에서의 에너지가 아니라 순간 전류만 측정하는 것.
• 전력을 벤치에서만 검증하고, 실제 안테나와 배터리가 있는 최종 외장에서는 검증하지 않는 것.

브링업 체크리스트¶

• 목표 배터리 수명, 듀티 사이클, 필요한 웨이크업 소스를 정의합니다.
• 지속적으로 활성 상태를 유지해야 하는 서브시스템과 완전히 이벤트 구동으로 동작할 수 있는 서브시스템을 식별합니다.
• 모든 드라이버/태스크가 사용 후 PM 요청을 즉시 해제하는지 확인합니다.
• 제품의 실제 사용 패턴에 맞게 Bluetooth 광고/연결 파라미터를 튜닝합니다.
• 디스플레이 경로가 지원되는 곳에서 부분 리프레시를 사용하고 백라이트 정책이 제품 동작과 일치하는지 확인합니다.
• 모든 주기 타이머를 점검하여 불필요한 타이머를 제거하거나 통합합니다.
• 전류 측정 환경을 구축하고 활성, 유휴, 슬립 상태를 각각 검증합니다.
• 복합 최악 부하(해당하는 경우 Bluetooth + 디스플레이 + 오디오 + AI)를 테스트하고 전력 예산을 여전히 충족하는지 확인합니다.
• 프로젝트 마지막에만이 아니라 중요한 펌웨어 변경이 있을 때마다 전력을 다시 검증합니다.

핵심 요약¶

• 전력은 시스템 속성입니다. Bluetooth, 디스플레이, 오디오, AI, 메모리에 관한 결정이 모두 디바이스가 얼마나 깊이, 얼마나 자주 슬립할 수 있는지에 영향을 줍니다.
• 구성된 PM 정책은 조건을 충족하는 저전력 상태 중에서 선택합니다. 더 깊은 슬립을 막는 해제되지 않은 요청은 시스템을 의도한 것보다 얕은 상태에 머물게 할 수 있습니다.
• 전력이 중요한 거의 모든 곳에서 이벤트 구동, 인터럽트 기반 설계가 폴링보다 낫습니다.
• Bluetooth 연결 파라미터와 디스플레이 리프레시 전략은 대개 연결형 웨어러블 제품에서 가장 큰 두 가지 수단입니다.
• 현실적인 복합 워크로드에서, 최종 외장 안의 실제 하드웨어로 실제 에너지를 측정하십시오. 벤치 측정과 개별 서브시스템 측정은 실제 제품의 전력을 과소평가할 수 있습니다.

전압으로 배터리 잔량(%)을 추정하는 방법은 배터리 충전 잔량(SoC) 추정을 참고하세요.

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