Дозирование

Что такое пакетная обработка?

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

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

Пакетная обработка может происходить только в том случае, если датчик имеет аппаратный 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 датчиков.

sample_ 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 не поддерживает генерацию событий с частотой более 1000 Гц.
  • если sampling_period_ns больше SensorInfo.maxDelay , то реализация HAL должна автоматически усечь его до SensorInfo.maxDelay .

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

Если запрошенная частота

Тогда фактическая частота должна быть

частота ниже минимальной (<1/maxDelay)

от 90% до 110% минимальной частоты

между минимальной и максимальной частотой

от 90 % до 220 % от запрошенной частоты

частота выше максимальной (>1/минЗадержка)

от 90% до 110% максимальной частоты и ниже 1100 Гц.

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 = 20 с
  • гироскоп в пакетном режиме с max_report_latency = 5 с

О пакетах акселерометра сообщается одновременно с пакетами гироскопа (каждые 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. Точка доступа просыпается, и все события из 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 не является проблемой.