일괄 처리란?
일괄 처리란 센서 HAL을 통해 이벤트를 보고하기 전에 센서 허브 또는 하드웨어 FIFO의 센서 이벤트를 버퍼링하는 것을 의미합니다. 이 페이지에서는 센서 이벤트가 버퍼링되는 위치(센서 허브 또는 하드웨어 FIFO)를 'FIFO'라고 부릅니다. 센서 이벤트 일괄 처리가 활성화되지 않은 경우 센서 이벤트는 준비되는 즉시 센서 HAL에 보고됩니다.
일괄 처리는 다수의 센서 이벤트에 관한 처리 준비가 완료되었을 때 각 개별 이벤트에 관해 절전 모드를 해제하는 대신 기본 애플리케이션 프로세서(AP)의 절전 모드만 해제하여 상당한 전력을 절약할 수 있게 합니다. 잠재적인 전력 절약은 센서 허브 또는 FIFO에서 버퍼링할 수 있는 이벤트 수와 직접적인 상관관계를 지닙니다. 일괄 처리 가능한 이벤트의 수가 많을수록 더 많은 전력을 절약할 수 있습니다. 일괄 처리는 저전력 메모리 사용을 활용하여 고전력 AP의 절전 모드 해제 횟수를 줄입니다.
일괄 처리는 센서가 하드웨어 FIFO를 처리하거나 센서 허브 내의 이벤트를 버퍼링할 수 있는 경우에만 발생합니다. 두 경우 모두 센서는 SensorInfo.fifoMaxEventCount를 통해 일괄 처리 가능한 최대 이벤트 수를 보고해야 합니다.
센서가 FIFO 내에 공간을 남겨둔 경우 센서는 SensorInfo.fifoReservedEventCount를 통해 예약된 이벤트 수를 보고해야 합니다. FIFO가 센서 전용으로 사용되는 경우에는 SensorInfo.fifoReservedEventCount가 FIFO의 크기입니다. FIFO가 여러 센서 간에 공유되는 경우 이 값은 0일 수 있습니다. 일반적인 사용 사례는 센서가 유일한 활성 센서인 경우 전체 FIFO를 사용할 수 있도록 허용하는 것입니다. 여러 개의 센서가 활성화된 경우에는 FIFO에 포함된 최소 SensorInfo.fifoReservedEventCount개 이벤트를 위한 공간이 각 센서에 보장됩니다. 센서 허브가 사용된 경우에는 소프트웨어를 통해 공간이 보장될 수 있습니다.
센서 이벤트는 다음과 같은 상황에서 일괄 처리됩니다.
- 센서의 현재 최대 보고 지연 시간이 0보다 큰 경우 HAL을 통해 보고되기 전에 센서 이벤트를 최대 보고 지연 시간까지 지연시킬 수 있음을 의미합니다.
- AP는 정지 모드이며 센서는 non-wake-up 센서입니다. 이 경우 이벤트는 AP의 절전 모드를 해제하면 안 되며 AP의 절전 모드가 해제될 때까지 저장되어야 합니다.
센서가 일괄 처리를 지원하지 않고 AP가 절전 모드인 경우에는 wake-up 센서 이벤트만 AP에 보고되며, non-wake-up 이벤트는 AP에 보고되면 안 됩니다.
일괄 처리 매개변수
일괄 처리 동작에 적용되는 두 매개변수는 sampling_period_ns와 max_report_latency_ns입니다.
sampling_period_ns는 새로운 센서 이벤트가 생성되는 빈도를 결정하며, max_report_latency_ns는 이벤트가 센서 HAL에 보고되어야 하는 기한을 결정합니다.
sampling_period_ns
sampling_period_ns 매개변수의 의미는 지정된 센서의 보고 모드에 따라 다릅니다.
- 연속:
sampling_period_ns는 샘플링 레이트 즉, 이벤트가 생성되는 속도를 의미합니다. - 변경 시:
sampling_period_ns는 이벤트의 샘플링 레이트를 제한합니다. 즉, 이벤트가sampling_period_ns나노초보다 빨리 생성되지 않습니다. 생성된 이벤트가 없고 측정된 값이 장시간 동안 변경되지 않으면 기간이sampling_period_ns보다 길 수 있습니다. 자세한 내용은 변경 시 보고 모드를 참고하세요. - 한 번:
sampling_period_ns는 무시되어 효과를 미치지 않습니다. - 특수:
sampling_period_ns가 특수 센서에 사용되는 방식은 센서 유형을 참고하세요.
sampling_period_ns가 여러 모드에 미치는 영향에 관한 자세한 내용은 보고 모드를 참고하세요.
연속 및 변경 시 센서:
sampling_period_ns가SensorInfo.minDelay보다 짧은 경우에는 HAL 구현이 자동으로 이를max(SensorInfo.minDelay, 1ms)로 고정해야 합니다. Android는 1000Hz를 초과하는 이벤트 생성을 지원하지 않습니다.sampling_period_ns가SensorInfo.maxDelay보다 긴 경우에는 HAL 구현이 자동으로 이를SensorInfo.maxDelay로 잘라야 합니다.
간혹 실제 센서는 실행 가능한 속도와 클록의 정확도 면에서 한계를 지닙니다. 이를 감안했을 때, 실제 샘플링 주파수는 요청된 주파수와 다를 수 있습니다. 단, 아래 표의 요구사항을 충족해야 합니다.
요청된 주파수가 다음과 같은 경우 |
실제 주파수가 다음과 같아야 함 |
|---|---|
최소 주파수 미만(<1/maxDelay) |
최소 주파수의 90% 및 110% 사이 |
최소 및 최대 주파수 사이 |
요청된 주파수의 90% 및 220% 사이 |
최대 주파수 초과(>1/minDelay) |
최대 주파수의 90% 및 110% 사이, 1100Hz 미만 |
max_report_latency_ns
max_report_latency_ns는 AP의 절전 모드가 해제된 상태에서 이벤트가 HAL을 통해 보고되기 전에 지연되고 하드웨어 FIFO에 저장될 수 있는 최대 시간(나노초)을 설정합니다.
값이 0인 경우 이벤트를 측정되는 즉시 보고해야 함을 의미합니다(FIFO를 아예 건너뛰거나 센서의 한 이벤트가 존재하는 즉시 FIFO를 비움).
예를 들어 50Hz에서 max_report_latency_ns=0으로 활성화된 가속도계는 AP의 절전 모드가 해제되었을 때 인터럽트를 초당 50회 트리거합니다.
max_report_latency_ns>0인 경우 센서 이벤트를 감지되는 즉시 보고할 필요가 없습니다. max_report_latency_ns나노초 넘게 지연되지 않는 한, 이벤트를 FIFO에 임시 저장했다가 일괄적으로 보고할 수 있습니다. 즉, 이전 일괄 처리 이후의 모든 이벤트가 한 번에 기록 및 반환됩니다. 이렇게 하면 AP로 전송되는 인터럽트 수가 감소하며, 센서가 데이터를 캡처하고 일괄 처리하는 동안 AP가 저전력 모드(유휴)로 전환될 수 있습니다.
각 이벤트에는 타임스탬프가 연결되어 있습니다. 이벤트가 보고되는 시간을 지연해도 이벤트 타임스탬프가 영향을 받지는 않습니다. 타임스탬프는 정확해야 하며 이벤트가 보고된 시간이 아니라 이벤트가 실제로 발생한 시간과 일치해야 합니다.
센서 이벤트가 FIFO에 임시 저장되도록 허용해도 HAL에 이벤트를 제출하는 동작이 변경되지는 않습니다. 다른 센서의 이벤트는 인터리브할 수 있으며 같은 센서의 모든 이벤트가 시간순으로 정렬됩니다.
wake-up 및 non-wake-up 이벤트
wake-up 센서의 센서 이벤트는 한 개 이상의 wake-up FIFO에 저장해야 합니다. 일반적인 설계는 모든 wake-up 센서의 이벤트가 인터리브되는 대규모의 공유된 단일 wake-up FIFO를 보유하는 것입니다. 또는 wake-up FIFO를 센서당 하나씩 보유하거나, 특정 wake-up 센서를 위한 전담 FIFO와 나머지 wake-up 센서를 위한 공유 FIFO를 보유할 수 있습니다.
마찬가지로 non-wake-up 센서의 센서 이벤트는 하나 이상의 non-wake-up FIFO에 저장해야 합니다.
어떠한 경우든 wake-up 센서 이벤트와 non-wake-up 센서 이벤트는 같은 FIFO에 인터리브할 수 없습니다. wake-up 이벤트는 wake-up FIFO에, non-wake-up 이벤트는 non-wake-up FIFO에 저장해야 합니다.
wake-up FIFO의 경우 대규모의 공유된 단일 FIFO 설계가 최상의 전력 이점을 제공합니다. non-wake-up FIFO의 경우 대규모의 공유된 단일 FIFO와 다수의 예약된 소규모 FIFO 설계가 비슷한 전력 특성을 지닙니다. 각 FIFO를 구성하는 방법에 관한 추가적인 제안사항은 FIFO 할당 우선순위를 참고하세요.
정지 모드 외의 동작
AP의 절전 모드(정지 모드)가 해제되면 이벤트가 FIFO에 임시 저장됩니다. 단, max_report_latency를 초과하여 지연되면 안 됩니다.
AP가 정지 모드로 전환되지 않는 한, 어떠한 이벤트도 드롭되거나 사라지지 않습니다. max_report_latency가 경과되기 전에 내부 FIFO가 가득 차면 사라지는 이벤트가 없도록 이 시점의 이벤트가 보고됩니다.
여러 센서가 같은 FIFO를 공유하고 그중 하나의 max_report_latency가 경과되면 다른 센서의 max_report_latency가 아직 경과되지 않은 경우에도 FIFO의 모든 이벤트가 보고됩니다. 이렇게 하면 이벤트의 일괄 처리가 보고되는 횟수가 감소합니다. 이벤트 하나를 보고해야 하는 경우 모든 센서의 모든 이벤트가 보고됩니다.
예를 들어 다음 센서가 활성화되는 경우:
max_report_latency= 20s로 일괄 처리된 가속도계max_report_latency= 5s로 일괄 처리된 자이로스코프
가속도계 일괄 처리는 가속도계와 자이로스코프가 같은 FIFO를 공유하지 않는 경우에도 자이로스코프 일괄 처리가 보고되는 같은 시점(5초마다)에 보고됩니다.
정지 모드의 동작
일괄 처리는 AP의 절전 모드 해제 상태를 유지하지 않고 백그라운드에서 센서 데이터를 수집하는 경우에 특히 유용합니다. 센서 드라이버와 HAL 구현은 wake lock*을 유지할 수 없으므로 센서 데이터가 수집되는 도중에도 AP가 정지 모드로 전환될 수 있습니다.
AP가 정지된 동안의 센서 동작은 센서가 wake-up 센서인지에 따라 다릅니다. 자세한 내용은 wake-up 센서를 참고하세요.
차기 시작한 non-wake-up FIFO는 주변을 둘러싸며 순환 버퍼처럼 동작하여 기존 이벤트를 새 이벤트로 덮어쓰고 기존 이벤트를 대체해야 합니다. max_report_latency는 정지 모드 상태에서 non-wake-up FIFO에 영향을 미치지 않습니다.
wake-up FIFO가 차기 시작하거나 wake-up 센서 중 하나의 max_report_latency가 경과되면 하드웨어는 AP의 절전 모드를 해제하고 데이터를 보고해야 합니다.
두 경우 모두(wake-up 및 non-wake-up) AP의 정지 모드가 해제되는 즉시 모든 FIFO의 콘텐츠를 포함하는 배치가 생성됩니다. 이는 일부 센서의 max_report_latency가 아직 경과되지 않은 경우에도 마찬가지입니다. 이렇게 하면 AP가 정지 모드로 돌아간 직후에 AP의 정지 모드를 다시 해제해야 하는 위험이 최소화되며, 따라서 전력 소모가 최소화됩니다.
*wake lock 유지가 허용되지 않은 드라이버의 눈에 띄는 예외 중 하나는 연속 보고 모드를 포함하는 wake-up 센서가 max_report_latency < 1초로 활성화되는 경우입니다. 이 경우 드라이버는 wake lock을 유지할 수 있으며, 이는 AP가 정지 모드에 도달하기 전에 wake-up 이벤트에 의해 절전 모드가 해제되어 정지 모드로 전환될 시간이 없기 때문입니다.
wake-up 센서 일괄 처리 시 주의사항
기기에 따라 AP가 정지 모드에서 완전히 해제되고 FIFO를 플러시하기 시작할 때까지 몇 밀리초가 소요될 수 있습니다. 기기가 wake-up FIFO가 넘치지 않는 상태에서 기기가 정지 모드에서 해제될 수 있도록 충분한 헤드룸을 FIFO에 할당해야 합니다. 어떠한 이벤트도 손실되면 안 되며 max_report_latency가 적용되어야 합니다.
non-wake-up 변경 시 센서 일괄 처리 시 주의사항
변경 시 센서는 측정 중인 값이 변경될 때에만 이벤트를 생성합니다. AP가 정지 모드인 상태에서 측정된 값이 변경되면 애플리케이션은 AP의 절전 모드가 해제되는 즉시 이벤트를 수신할 것으로 예상합니다. 따라서 non-wake-up 변경 시 센서 이벤트의 일괄 처리는 센서가 FIFO를 다른 센서와 공유하는 경우 신중히 실행해야 합니다. 각 변경 시 센서에 의해 생성된 마지막 이벤트는 다른 이벤트로 덮어쓰기되지 않도록 항상 공유 FIFO 외부에 저장되어야 합니다. FIFO의 모든 이벤트가 보고된 후에 AP의 절전 모드가 해제되면 마지막 변경 시 센서 이벤트가 보고되어야 합니다.
피해야 할 상황은 다음과 같습니다.
- 애플리케이션이 같은 FIFO를 공유하는 non-wake-up 걸음수 측정기(변경 시)와 non-wake-up 가속도계(연속)에 등록됩니다.
- 애플리케이션이 걸음수 측정기 이벤트
step_count=1000 stepscode>를 수신합니다. - AP가 정지 모드로 전환됩니다.
- 사용자가 20보를 걸어 걸음수 측정기 및 가속도계 이벤트가 인터리브되고 마지막 걸음수 측정기 이벤트가
step_count = 1020 steps가 되도록 합니다. - 사용자가 장시간 동안 움직이지 않아 가속도계 이벤트가 계속해서 FIFO에서 누적되고, 결국에는 공유 FIFO의 모든
step_count이벤트를 덮어씁니다. - AP의 절전 모드가 해제되고 FIFO의 모든 이벤트가 애플리케이션으로 전송됩니다.
- 애플리케이션이 가속도계 이벤트만 수신하고 사용자가 걷지 않았다고 생각합니다.
FIFO 외부에 마지막 걸음수 측정기 이벤트를 저장함으로써 HAL은 다른 모든 걸음수 측정기 이벤트가 가속도계 이벤트로 덮어쓰기되는 경우에도 AP의 절전 모드가 해제될 때 이 이벤트를 보고할 수 있습니다. 이렇게 하면 AP의 절전 모드가 해제될 때 애플리케이션이 step_count = 1020 steps를 수신합니다.
일괄 처리 구현
전력을 절약하려면 AP의 도움 없이 일괄 처리를 구현해야 하며, AP가 일괄 처리 도중에 정지될 수 있어야 합니다.
일괄 처리가 센서 허브에서 실행된 경우 센서 허브의 전력 사용량이 최소화되어야 합니다.
최대 보고 지연 시간은 언제든지 수정 가능하며(특히 지정된 센서가 이미 사용 설정된 경우), 이벤트의 손실로 이어지면 안 됩니다.
FIFO 할당 우선순위
하드웨어 FIFO 또는 센서 허브의 버퍼 크기가 제한된 플랫폼에서는 시스템 설계자가 각 센서용으로 어느 정도의 FIFO를 남겨 놓을지 선택해야 할 수도 있습니다. 이러한 선택에 도움이 되도록 아래에는 여러 센서에 일괄 처리를 구현할 때 사용 가능한 애플리케이션이 나열되어 있습니다.
높은 값: 저전력 PDR(Pedestrian Dead Reckoning)
타겟 일괄 처리 시간: 1~10분
일괄 처리할 센서:
- Wake-up 걸음수 감지기
- Wake-up 게임 회전 벡터(5Hz)
- Wake-up 기압계(5Hz)
- Wake-up 미보정 자기계(5Hz)
이 데이터를 일괄 처리하면 AP의 정지 모드 전환을 허용하는 동시에 PDR을 실행할 수 있습니다.
높은 값: 중전력 간헐적 활동/동작 인식
타겟 일괄 처리 시간: 3초
일괄 처리할 센서: non-wake-up 가속도계(50Hz)
이 데이터를 일괄 처리하면 데이터가 수집되는 동안 AP의 절전 모드 해제 상태를 유지하지 않고도 임의의 활동과 동작을 주기적으로 인식할 수 있습니다.
중간 값: 중전력 연속 활동/동작 인식
타겟 일괄 처리 시간: 1~3분
일괄 처리할 센서: wake-up 가속도계(50Hz)
이 데이터를 일괄 처리하면 데이터가 수집되는 동안 AP의 절전 모드 해제 상태를 유지하지 않고도 임의의 활동과 동작을 연속으로 인식할 수 있습니다.
중간보다 높은 값: 인터럽트 로드 감소
타겟 일괄 처리 시간: < 1초
일괄 처리할 센서: 모든 고주파수 센서(보통 non-wake-up)
자이로스코프가 240Hz로 설정되면 자이로스코프 이벤트 10개만 일괄 처리해도 인터럽트 수를 초당 240회에서 초당 24회로 줄일 수 있습니다.
중간 값: 연속 저주파수 데이터 수집
타겟 일괄 처리 시간: 1~10분
일괄 처리할 센서:
- wake-up 기압계(1Hz)
- wake-up 습도 센서(1Hz)
- 속도가 비슷한 다른 저주파수 wake-up 센서
저전력에서 모니터링 애플리케이션을 생성할 수 있게 해줍니다.
중간보다 낮은 값: 연속 전체 센서 수집
타겟 일괄 처리 시간: 1~10분
일괄 처리할 센서: 모든 wake-up 센서(고주파수)
AP를 정지 모드로 유지한 상태에서 센서 데이터를 전체 수집할 수 있게 해줍니다. FIFO 공간에 문제가 없는 경우에만 고려하세요.