Пакетная обработка данных датчика для экономии энергии

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

Введение

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

Задержка пакетной службы

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

В случае драйвера, который не реализует пакетную обработку данных, драйвер просто собирает и отправляет данные датчика по мере их доступности. Например, чтобы отправить N примеров данных, драйвер инициирует сбор и отправку примеров данных( N раз).

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

Свойства датчика

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

• PKEY_Sensor_FifoReservedSize_Samples
• PKEY_Sensor_FifoMaxSize_Samples
• PKEY_Sensor_WakeCapable

Дополнительные сведения см. в разделах Общие свойства датчика и Свойства перечисления.

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

Необязательные функции DDSI для пакетной обработки данных

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

• EvtSensorSetBatchLatency

  Это функция обратного вызова, которая задает задержку пакета для указанного датчика. Драйвер должен задать для параметра Batch Latency значение, которое меньше или равно параметру BatchLatencyMs в зависимости от доступности буфера.

Драйвер также должен реализовать все необходимые функции DDSI. Дополнительные сведения см. в разделе структура _SENSOR_CONTROLLER_CONFIG.

Это необязательно для расширения класса датчика, чтобы указать задержку пакета. Задержка пакета по умолчанию для всех датчиков равна нулю (0), которая указывает, что образцы не будут пакетными. Примеры датчиков будут доставляться пакетами, только если расширение класса вызывает EvtSensorSetBatchLatency , чтобы задать значение задержки пакета. В противном случае выборки будут доставляться в обычном режиме с частотой интервала периодических данных.

Расширение класса датчика может вызвать EvtSensorSetBatchLatency , чтобы изменить значение задержки пакета в любое время. В частности, эту функцию можно вызывать, когда указанный датчик уже активен и работает, и это не должно привести к потере событий. Ожидается, что драйвер датчика собирает и начинает доставлять образцы последней партии немедленно (на основе наилучших усилий). Драйвер не должен превышать задержку пакета, заданную расширением класса.

Важно отметить, что в методах и событиях доставки данных датчика не подразумевается никаких изменений из-за пакетной обработки данных. Когда истечет задержка пакета, драйвер многократно вызывает SensorsCxSensorDataReady, чтобы доставить все образцы буферизованной данных по одному. Выборки данных сопровождаются метками времени (содержащимися в связанных PKEY_SensorData_Timestamp полях данных), указывающими, когда была сделана каждая выборка. Дополнительные сведения о PKEY_SensorData_Timestamp см. в разделе Общие поля данных.

Отношение задержки пакетной службы и скорости передачи данных

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

Где SensorBatching_MaxSize_Bytes — это максимальный размер буфера для пакетных данных датчика. Если датчик является акселерометром, рекомендуется использовать аппаратный буфер, который достаточно велик для хранения 250 или более образцов. Скорость передачи данных выражается в миллисекундах. Это время, необходимое для передачи одной выборки данных. Количество образцов, которые оборудование датчика должно хранить в пакете, обратно пропорционально скорости передачи данных. Чем меньше скорость передачи данных, тем больше буфер выборки, необходимый для хранения пакетных выборок для заданного значения задержки пакета. В приведенной выше формуле задержка пакета представлена BatchLatencyMs , а скорость передачи данных — DataRateMs. Если сочетание BatchLatencyMs и DataRateMs приводит к увеличению размера буфера, превышающего SensorBatching_MaxSize_Bytes, то EvtSensorSetBatchLatency и EvtSensorSetDataInterval установят для задержки пакета значение, показанное в предыдущей формуле.

Если вызывающий объект задает значение BatchLatencyMs меньше , чем DataRateMs, данные доставляются без буферизации.

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

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

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

Примеры схем последовательностей

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

Сценарий 1

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

Сценарий 2

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

Сценарий 3

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

Конфигурации оборудования пакетной обработки данных

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

• Конфигурация 1. Буфер FIFO реализован в компоненте Датчик, который напрямую подключен к процессору приложения.

• Конфигурация 2. Буфер FIFO реализован в аппаратном ядре датчика с низким энергопотреблением, к которому подключен компонент датчика. В этом случае буфер FIFO может быть совместно использоваться несколькими датчиками или даже совместно использоваться компонентами без датчиков в зависимости от структуры ядра датчика. Ядро датчика с низким энергопотреблением, в свою очередь, подключено к процессору приложения и может быть интегрировано в SoC. Или это может быть внешний компонент.

• Конфигурация 3. Буфер FIFO реализуется в компоненте датчика. Компонент датчика подключен к ядру датчика с низким энергопотреблением, которое подключено к процессору приложения. Компонент датчика может быть интегрирован в SoC или быть внешним компонентом.

• Конфигурация 4. Буфер FIFO реализован в компоненте датчика и ядре датчика с низким энергопотреблением. Компонент датчика подключен к ядру датчика с низким энергопотреблением, которое, в свою очередь, подключено к процессору приложения. Компонент датчика может быть интегрирован в SoC или быть внешним компонентом. Стоит отметить, что ядро датчика можно использовать для расширения FIFO, который является слишком мелким.

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

На следующей схеме показаны различные конфигурации, описанные в предыдущем списке.

Поведение полного буфера в оборудовании

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