Дозирование

Что такое пакетирование?

Пакетная обработка относится к буферизации событий датчика в концентраторе датчиков и/или аппаратном FIFO перед тем, как сообщать о событиях через Sensors HAL . Место, в котором буферизируются события датчиков (концентратор датчиков и/или аппаратный FIFO), на этой странице называется «FIFO». Когда пакетная обработка событий датчиков не активна, события датчиков немедленно передаются в HAL датчиков, когда они доступны.

Пакетная обработка может обеспечить значительную экономию энергии за счет пробуждения основного процессора приложений (AP), работающего под управлением Android, только тогда, когда многие события датчика готовы к обработке, вместо того, чтобы пробуждать его для каждого отдельного события. Потенциальная экономия энергии напрямую связана с количеством событий, которые концентратор датчиков и/или FIFO может буферизовать: существует больший потенциал для экономии энергии, если можно пакетировать больше событий. Пакетная обработка использует память с низким энергопотреблением, чтобы уменьшить количество пробуждений AP с высоким энергопотреблением.

Пакетирование может происходить только в том случае, если датчик имеет аппаратный FIFO и/или может буферизовать события в концентраторе датчиков. В любом случае датчик должен сообщать о максимальном количестве событий, которые могут быть объединены в пакеты одновременно, с помощью SensorInfo.fifoMaxEventCount .

Если для датчика зарезервировано место в FIFO, датчик должен сообщить о количестве зарезервированных событий через SensorInfo.fifoReservedEventCount . Если FIFO предназначен для датчика, то SensorInfo.fifoReservedEventCount — это размер FIFO. Если FIFO используется несколькими датчиками, это значение может быть равно нулю. Обычный вариант использования — разрешить датчику использовать весь FIFO, если он единственный активный датчик. Если активны несколько датчиков, то каждому датчику гарантировано место как минимум для событий SensorInfo.fifoReservedEventCount в FIFO. Если используется концентратор датчиков, гарантия может быть реализована с помощью программного обеспечения.

События датчика группируются в следующих ситуациях:

• Текущая максимальная задержка отчета датчика больше нуля, что означает, что события датчика могут быть задержаны до максимальной задержки отчета, прежде чем они будут переданы через HAL.
• Точка доступа находится в режиме ожидания, а датчик не является датчиком пробуждения. В этом случае события не должны будить точку доступа и должны сохраняться до тех пор, пока точка доступа не проснется.

Если датчик не поддерживает пакетную обработку данных, а точка доступа находится в спящем режиме, точка доступа получает сообщения только о событиях датчика пробуждения, а о событиях, не связанных с активацией, не следует сообщать точке доступа.

Параметры дозирования

Два параметра, которые управляют поведением пакетной обработки, — sample_period_ns и max_report_latency_ns . sampling_period_ns определяет, как часто генерируется новое событие датчика, а max_report_latency_ns определяет, как долго, прежде чем о событии должно быть сообщено HAL датчиков.

выборка_период_нс

Что означает параметр sampling_period_ns , зависит от режима отчета указанного датчика:

• Continuous: sampling_period_ns — это частота дискретизации, то есть скорость, с которой генерируются события.
• При изменении: sampling_period_ns ограничивает частоту дискретизации событий, то есть события генерируются не быстрее, чем каждые наносекунды sampling_period_ns . Периоды могут быть длиннее, чем sampling_period_ns , если не генерируется событие и измеренные значения не изменяются в течение длительных периодов времени. Дополнительные сведения см. в разделе Режим отчетов об изменениях .
• Одноразовый: sampling_period_ns игнорируется. Это не имеет никакого эффекта.
• Special: Подробную информацию о том, как sampling_period_ns используется для специальных датчиков, см. в разделе Sensor Types .

Для получения дополнительной информации о влиянии sampling_period_ns в различных режимах см. Режимы создания отчетов .

Для датчиков непрерывного действия и датчиков изменения:

• если sampling_period_ns меньше, чем SensorInfo.minDelay , тогда реализация HAL должна молча зафиксировать его на max(SensorInfo.minDelay, 1ms) . Android не поддерживает генерацию событий с частотой более 1000 Гц.
• если sampling_period_ns больше, чем SensorInfo.maxDelay , тогда реализация HAL должна молча урезать его до SensorInfo.maxDelay .

Физические датчики иногда имеют ограничения на скорость, с которой они могут работать, и на точность своих часов. Чтобы учесть это, фактическая частота дискретизации может отличаться от запрошенной частоты, если она удовлетворяет требованиям, указанным в таблице ниже.

max_report_latency_ns

max_report_latency_ns устанавливает максимальное время в наносекундах, на которое события могут быть задержаны и сохранены в аппаратном FIFO, прежде чем о них будет сообщено через HAL, пока точка доступа находится в активном состоянии.

Нулевое значение означает, что о событиях необходимо сообщать, как только они измерены, либо полностью пропуская FIFO, либо очищая FIFO, как только появляется одно событие от датчика.

Например, акселерометр, активированный на частоте 50 Гц с max_report_latency_ns=0 , будет запускать прерывания 50 раз в секунду, когда точка доступа находится в активном состоянии.

Когда max_report_latency_ns>0 , о событиях датчика не нужно сообщать, как только они обнаружены. Они могут быть временно сохранены в FIFO и сообщаться пакетами, если ни одно событие не задерживается более чем на max_report_latency_ns наносекунд. Это означает, что все события, начиная с предыдущей партии, записываются и возвращаются одновременно. Это уменьшает количество прерываний, отправляемых на точку доступа, и позволяет точке доступа переключаться в режим пониженного энергопотребления (в режиме ожидания), пока датчик собирает и группирует данные.

Каждое событие имеет связанную с ним временную метку. Задержка времени сообщения о событии не влияет на метку времени события. Отметка времени должна быть точной и соответствовать времени, когда событие произошло физически, а не времени, когда о нем было сообщено.

Разрешение на временное хранение событий датчика в FIFO не изменяет поведение отправки событий в HAL; события от разных датчиков могут чередоваться, и все события от одного и того же датчика упорядочены по времени.

События пробуждения и не пробуждения

События датчика от датчиков пробуждения должны храниться в одном или нескольких FIFO пробуждения. Обычный дизайн состоит в том, чтобы иметь один большой общий буфер FIFO для пробуждения, в котором чередуются события от всех датчиков пробуждения. В качестве альтернативы вы можете иметь один FIFO пробуждения для каждого датчика или иметь выделенные FIFO для определенных датчиков пробуждения и общий FIFO для остальных датчиков пробуждения.

Точно так же события датчика от датчиков без пробуждения должны храниться в одном или нескольких FIFO без пробуждения.

Во всех случаях события датчика пробуждения и события датчика, не являющегося датчиком пробуждения, не могут чередоваться в одном и том же FIFO. События пробуждения должны храниться в FIFO пробуждения, а события без пробуждения должны храниться в FIFO не пробуждения.

Что касается FIFO пробуждения, единый, большой, общий FIFO дизайн обеспечивает наилучшие преимущества в области энергопотребления. Для FIFO без пробуждения один большой общий FIFO и несколько небольших зарезервированных FIFO имеют схожие характеристики мощности. Дополнительные рекомендации по настройке каждого FIFO см. в разделе Приоритет распределения FIFO .

Поведение вне режима приостановки

Когда точка доступа активна (не в режиме приостановки), события временно сохраняются в FIFO до тех пор, пока они не задерживаются более чем на max_report_latency .

Пока точка доступа не переходит в режим приостановки, ни одно событие не будет пропущено или потеряно. Если внутренние FIFO заполняются до истечения max_report_latency , в этот момент сообщается о событиях, чтобы гарантировать, что ни одно событие не будет потеряно.

Если несколько датчиков используют один и тот же FIFO и max_report_latency одного из них истекает, сообщаются все события из FIFO, даже если max_report_latency других датчиков еще не истек. Это уменьшает количество отчетов о пакетах событий. Когда необходимо сообщить об одном событии, сообщаются обо всех событиях со всех датчиков.

Например, если активированы следующие датчики:

• акселерометр пакетный с max_report_latency = 20s
• гироскоп в пакетном режиме с max_report_latency = 5s

Пакеты акселерометра передаются одновременно с пакетами гироскопа (каждые 5 секунд), даже если акселерометр и гироскоп не используют один и тот же FIFO.

Поведение в режиме ожидания

Пакетная обработка особенно удобна для сбора данных датчиков в фоновом режиме, не поддерживая точку доступа в активном состоянии. Поскольку драйверам датчиков и реализации HAL не разрешено удерживать блокировку пробуждения*, точка доступа может перейти в режим приостановки даже во время сбора данных датчиков.

Поведение датчиков, когда точка доступа приостановлена, зависит от того, является ли датчик датчиком пробуждения. Дополнительные сведения см. в разделе Датчики пробуждения .

Когда FIFO без пробуждения заполняется, он должен зацикливаться и вести себя как циклический буфер, перезаписывая старые события новыми событиями, заменяющими старые. max_report_latency не влияет на FIFO без пробуждения в режиме приостановки.

Когда FIFO пробуждения заполняется или когда max_report_latency одного из датчиков пробуждения истекает, аппаратное обеспечение должно разбудить точку доступа и сообщить данные.

В обоих случаях (пробуждение и не-пробуждение), как только точка доступа выходит из режима приостановки, создается пакет с содержимым всех FIFO, даже если max_report_latency некоторых датчиков еще не истек. Это сводит к минимуму риск того, что точке доступа придется снова выходить из спящего режима вскоре после ее возврата в режим ожидания, и, следовательно, сводит к минимуму энергопотребление.

* Одно заметное исключение, когда драйверам не разрешено удерживать блокировку пробуждения, — это когда датчик пробуждения с режимом непрерывной отчетности активируется с max_report_latency < 1 секунды. В этом случае драйвер может удерживать блокировку пробуждения, потому что у точки доступа нет времени для перехода в режим приостановки, поскольку она будет разбужена событием пробуждения до перехода в режим приостановки.

Меры предосторожности при упаковке датчиков пробуждения

В зависимости от устройства может потребоваться несколько миллисекунд, чтобы точка доступа полностью вышла из режима ожидания и начала очищать FIFO. В FIFO должно быть выделено достаточно места, чтобы устройство могло выйти из режима ожидания без переполнения FIFO пробуждения. Никакие события не должны быть потеряны, и необходимо соблюдать max_report_latency .

Меры предосторожности, которые необходимо соблюдать при пакетировании датчиков смены, не активизирующихся

Датчики изменения генерируют события только тогда, когда измеряемое ими значение изменяется. Если измеренное значение изменяется, когда точка доступа находится в режиме ожидания, приложения ожидают получить событие, как только точка доступа выйдет из спящего режима. По этой причине пакетирование событий датчика, не вызывающих пробуждение при изменении, должно выполняться с осторожностью, если датчик использует общий FIFO-буфер с другими датчиками. Последнее событие, сгенерированное каждым датчиком изменения, должно всегда сохраняться вне общего FIFO, чтобы оно никогда не могло быть перезаписано другими событиями. Когда точка доступа выходит из спящего режима, после того как все события из FIFO были зарегистрированы, необходимо сообщить о последнем событии датчика при смене.

Вот ситуации, которых следует избегать:

1. Приложение регистрируется на счетчике шагов без пробуждения (при изменении) и акселерометре без пробуждения (непрерывно), оба используют один и тот же FIFO.
2. Приложение получает событие step_count=1000 steps >.
3. AP переходит в режим ожидания.
4. Пользователь проходит 20 шагов, в результате чего события счетчика шагов и акселерометра чередуются, при этом последним событием счетчика шагов является step_count = 1020 steps .
5. Пользователь долго не двигается, в результате чего события акселерометра продолжают накапливаться в FIFO, в конечном итоге перезаписывая каждое событие step_count в общем FIFO.
6. AP просыпается, и все события из FIFO отправляются в приложение.
7. Приложение получает только события акселерометра и считает, что пользователь не ходил.

Сохраняя последнее событие счетчика шагов вне FIFO, HAL может сообщить об этом событии, когда точка доступа просыпается, даже если все остальные события счетчика шагов были перезаписаны событиями акселерометра. Таким образом, при пробуждении точки доступа приложение получает step_count = 1020 steps .

Реализация пакетной обработки

Для экономии энергии пакетная обработка должна выполняться без помощи точки доступа, а точка доступа должна приостанавливаться во время пакетной обработки.

Если пакетная обработка выполняется в концентраторе датчиков, энергопотребление концентратора датчиков должно быть сведено к минимуму.

Максимальная задержка отчета может быть изменена в любое время, в частности, когда указанный датчик уже включен; и это не должно приводить к потере событий.

Приоритет распределения FIFO

На платформах, в которых размер аппаратного FIFO и/или буфера концентратора датчиков ограничен, разработчикам систем может потребоваться выбрать, какой объем FIFO резервировать для каждого датчика. Чтобы помочь с этим выбором, вот список возможных приложений, когда пакетная обработка реализована на разных датчиках.

Высокое значение: счисление пешеходов с низким энергопотреблением.

Целевое время дозирования: от 1 до 10 минут

Датчики для партии:

• Детектор шагов пробуждения
• Вектор вращения игры пробуждения на частоте 5 Гц
• Барометр пробуждения на частоте 5 Гц
• Пробуждение некалиброванного магнитометра на частоте 5 Гц

Пакетирование этих данных позволяет выполнять счисление пешеходов, позволяя точке доступа переходить в режим ожидания.

Высокое значение: распознавание прерывистой активности/жестов средней мощности.

Целевое время пакетирования: 3 секунды

Датчики для пакетной обработки: акселерометр без пробуждения на частоте 50 Гц.

Пакетирование этих данных позволяет периодически распознавать произвольные действия и жесты без необходимости держать точку доступа в активном состоянии во время сбора данных.

Среднее значение: непрерывная активность/распознавание жестов средней мощности.

Целевое время дозирования: от 1 до 3 минут

Датчики для пакетной обработки: пробуждающий акселерометр с частотой 50 Гц.

Пакетирование этих данных позволяет непрерывно распознавать произвольные действия и жесты без необходимости держать точку доступа в активном состоянии во время сбора данных.

Средне-высокое значение: Прерывание снижения нагрузки

Целевое время пакетирования: < 1 секунды

Датчики для пакетной обработки: любой высокочастотный датчик, обычно не пробуждающийся.

Если гироскоп настроен на 240 Гц, даже пакетирование всего 10 событий гироскопа может уменьшить количество прерываний с 240 до 24 в секунду.

Среднее значение: непрерывный низкочастотный сбор данных.

Целевое время дозирования: от 1 до 10 минут

Датчики для партии:

• Барометр пробуждения с частотой 1 Гц
• Датчик влажности пробуждения на 1 Гц
• Другие низкочастотные датчики пробуждения с аналогичными частотами

Позволяет создавать приложения мониторинга с низким энергопотреблением.

Среднее-низкое значение: непрерывный сбор данных с полных датчиков.

Целевое время дозирования: от 1 до 10 минут

Датчики для пакетной обработки: все датчики пробуждения, на высоких частотах

Позволяет полностью собирать данные датчиков, оставляя точку доступа в режиме ожидания. Только рассмотрите, если пространство FIFO не является проблемой.