Envio em lote de dados do sensor para economia de energia

Este tópico aborda as interfaces necessárias entre a extensão da classe de sensor e o driver do sensor para implementar o envio em lote de dados do sensor em Windows 10.

Introdução

Um driver de sensor que implementa o envio em lote de dados permite que o processador do aplicativo economize energia, já que o processador recebe e processa dados do sensor com menos frequência. Nesse caso, o driver do sensor armazena em buffer os exemplos de dados do sensor no hardware do sensor e, em seguida, transfere-os juntos em um lote para a extensão da classe de sensor. Para dar suporte ao envio em lote, você deve fornecer um driver de sensor universal UMDF 2.0, que implementa as interfaces necessárias.

Latência do lote

A latência do Lote é definida como a quantidade máxima de tempo para a qual um sensor pode armazenar em buffer um exemplo de dados depois de ser coletado, antes de entregá-lo à extensão da classe de sensor. O "agendamento" de envio em lote de dados do sensor é iniciado quando os eventos do sensor são entregues pelo driver, com base no valor de latência do lote, conforme mostrado nos diagramas a seguir.

No caso de um driver que não implementa o envio em lote de dados, o driver simplesmente coleta e envia os dados do sensor à medida que ficam disponíveis. Portanto, por exemplo, para enviar N amostras de dados, o driver iniciaria a coleta e o envio dos exemplos de dados, N vezes.

No caso de um driver que implementa o envio em lote de dados, a sequência de coleta e entrega de dados é realizada em lotes, conforme mostrado no diagrama imediatamente anterior. O valor de latência em lote é especificado pela extensão de classe do sensor. Portanto, quando o hardware do sensor precisa coletar e transferir N amostras de dados, por exemplo, o driver do sensor pode dividir o processo em dois lotes. A primeira metade dos exemplos de dados N seria enviada após um intervalo de tempo igual ao período de latência do lote. Em seguida, após outro intervalo de tempo de latência em lote, a segunda metade dos exemplos de dados seria enviada, fazendo um total de duas transferências, em comparação com as N transferências exigidas pelo método de entrega normal.

Propriedades do sensor

Além das propriedades comuns do sensor e das propriedades de enumeração necessárias, um driver que dá suporte ao envio em lote de dados também deve relatar as seguintes propriedades:

• PKEY_Sensor_FifoReservedSize_Samples
• PKEY_Sensor_FifoMaxSize_Samples
• PKEY_Sensor_WakeCapable

Para obter mais informações, consulte Propriedades comuns do sensor e propriedades de enumeração.

Se o subsistema de hardware do sensor for compatível com a ativação, ele deverá garantir que ele inicie a ativação cedo o suficiente para evitar estouros de buffer.

Funções DDSI opcionais para envio em lote de dados

As funções DDSI (interface de software do driver de dispositivo) são a interface entre o driver e a extensão de classe. Para dar suporte ao envio em lote de dados, um driver deve implementar a seguinte função DDSI, para que a extensão da classe de sensor possa definir a latência em lote.

• EvtSensorSetBatchLatency

  Essa é uma função de retorno de chamada que define a latência em lote para um sensor especificado. O driver deve definir a Latência do Lote como um valor menor ou igual ao parâmetro BatchLatencyMs , dependendo da disponibilidade do buffer.

O driver também deve implementar todas as funções DDSI necessárias. Para obter mais informações, consulte _SENSOR_CONTROLLER_CONFIG estrutura.

É opcional que a extensão da classe de sensor especifique a latência em lote. A latência de lote padrão para todos os sensores é zero (0), que é usada para indicar que os exemplos não serão agrupados em lote. Os exemplos de sensor serão entregues em lotes, somente se a extensão de classe chamar EvtSensorSetBatchLatency para definir um valor de latência em lote. Caso contrário, os exemplos serão entregues normalmente na taxa periódica de intervalo de dados.

A extensão da classe de sensor pode chamar EvtSensorSetBatchLatency para alterar o valor de latência do lote a qualquer momento. Em particular, essa função pode ser chamada enquanto o sensor especificado já está ativo e em execução, e isso não deve resultar na perda de eventos. Espera-se que o driver do sensor colete e comece a fornecer amostras do lote mais recente imediatamente (com o melhor esforço). O driver não deve exceder a latência de lote especificada pela extensão de classe.

É importante observar que não há nenhuma alteração implícita nos métodos e eventos de entrega de dados do sensor devido ao envio em lote de dados. Quando a latência em lote expira, o driver chama SensorsCxSensorDataReady repetidamente para entregar todos os exemplos de dados armazenados em buffer um de cada vez. Os exemplos de dados são acompanhados por seus carimbos de data/hora (contidos em seus campos de dados PKEY_SensorData_Timestamp associados) indicando quando cada amostra foi obtida. Para obter mais informações sobre PKEY_SensorData_Timestamp, consulte Campos de dados comuns.

Latência em lote e relação de taxa de dados

A latência do lote e a taxa de dados estão relacionadas da seguinte maneira:

Em que SensorBatching_MaxSize_Bytes é o tamanho máximo do buffer para os dados do sensor em lote. Se o sensor for um acelerômetro, recomendamos um buffer de hardware grande o suficiente para conter 250 ou mais amostras. A taxa de dados é expressa em milissegundos e é o período de tempo necessário para transferir um exemplo de dados. O número de exemplos que o hardware do sensor deve armazenar em um lote é inversamente proporcional à taxa de dados. Quanto menor a taxa de dados, maior será o buffer de exemplo necessário para armazenar os exemplos em lote para um determinado valor de latência em lote. Na fórmula anterior, a latência em lote é representada por BatchLatencyMs e a taxa de dados é representada por DataRateMs. E se a combinação de BatchLatencyMs e DataRateMs resultar em um tamanho de buffer maior que SensorBatching_MaxSize_Bytes, EvtSensorSetBatchLatency e EvtSensorSetDataInterval definirão a latência do lote como o valor mostrado pela fórmula anterior.

Se o chamador especificar um valor BatchLatencyMs menor que DataRateMs, os dados serão entregues sem buffer.

Envio em lote com limites de dados

Um driver de sensor que implementa o envio em lote de dados pode usar EvtSensorSetDataThresholds para definir um limite de dados diferente de zero. Nesse caso, quando a diferença de valores de dados entre as leituras atuais e as últimas leituras excede o limite de dados que foi definido usando EvtSensorSetDataThresholds, o processo de coleta, envio em lote e entrega de dados é invocado. Portanto, usar o envio em lote de dados com limites de dados permite que o driver do sensor economize ainda mais energia.

Quando limites de dados não zero são definidos pela extensão de classe de sensor, juntamente com o envio em lote de dados, espera-se que o driver forneça amostras em lote com carimbos de data/hora precisos e também cumpra os limites de dados. Se o hardware do sensor em si não for capaz de manter carimbos de data/hora precisos ao impor limites de dados, ele poderá coletar amostras sem impor limites de dados. No entanto, nesse caso, o driver deve filtrar amostras que não atendam às configurações atuais do limite de dados, antes de entregá-las à extensão de classe de sensor.

Exemplos de diagrama de sequência

Aqui estão diagramas de sequência que mostram o uso das funções DDSI de envio em lote de dados opcionais que foram mencionadas em funções DDSI opcionais para envio em lote de dados. Podemos adicionar mais diagramas de sequência conforme necessário para esclarecer cenários com base nos comentários dos parceiros.

Cenário 1

Nesse cenário, a extensão da classe de sensor define a latência do lote e o intervalo de dados, antes de iniciar o sensor. Depois que o sensor é iniciado, ele entrega lotes periodicamente respeitando as propriedades definidas.

Cenário 2

Nesse cenário, a extensão de classe de sensor define a latência do lote, o intervalo de dados e os limites de dados, antes de iniciar o sensor. Depois que o sensor é iniciado, ele entrega lotes periodicamente respeitando as propriedades definidas. Observe que o driver não deve entregar um lote, a menos que haja um exemplo que atenda aos valores de limite de dados, que precisa ser enviado dentro da latência de lote especificada.

Cenário 3

Nesse cenário, a extensão de classe de sensor define a latência do lote e o intervalo de dados antes de iniciar o sensor. Depois que o sensor é iniciado, ele entrega lotes periodicamente, respeitando as propriedades definidas. A extensão de classe do sensor altera a latência em lote e o intervalo de dados enquanto o sensor está em execução e o driver começa imediatamente a fornecer amostras de acordo com os novos valores sem perder nenhuma amostra de dados durante a execução.

Configurações de hardware de envio em lote de dados

Os dados do sensor devem ser agrupados em lote no hardware do sensor, sem o envolvimento do processador do aplicativo. Isso permitirá que o processador durma enquanto os dados estão sendo agrupados para economizar energia. O diagrama a seguir mostra as possíveis configurações para o envio em lote de dados baseado em hardware do sensor.

• Configuração 1: o buffer FIFO é implementado no componente Sensor, que está conectado diretamente ao processador do aplicativo.

• Configuração 2: o buffer FIFO é implementado no núcleo de hardware do sensor de baixa potência, ao qual o componente do sensor está conectado. Nesse caso, o buffer FIFO pode ser compartilhado entre vários sensores ou até mesmo compartilhado com componentes não sensor, dependendo do design do núcleo do sensor. O núcleo do sensor de baixa potência, por sua vez, está conectado ao processador do aplicativo e pode ser integrado ao SoC. Ou pode ser um componente externo.

• Configuração 3: o buffer FIFO é implementado no componente do sensor. O componente do sensor está conectado a um núcleo de sensor de baixa potência, que está conectado ao processador do aplicativo. O componente do sensor pode ser integrado ao SoC ou pode ser um componente externo.

• Configuração 4: o buffer FIFO é implementado no componente do sensor e no núcleo do sensor de baixa potência. O componente do sensor está conectado a um núcleo de sensor de baixa potência que, por sua vez, está conectado ao processador do aplicativo. O componente do sensor pode ser integrado ao SoC ou pode ser um componente externo. Vale a pena observar que o núcleo do sensor pode ser usado para estender um FIFO muito superficial.

O importante a observar é que o FIFO pode ser implementado no hardware do sensor principal ou no hardware do sensor ou em ambos. O driver abstrai isso para o sistema operacional e apresenta uma interface uniforme por meio do DDSI.

O diagrama a seguir ilustra as diferentes configurações descritas na lista anterior.

Comportamento completo do buffer no hardware

Em circunstâncias normais, o driver deve ler o buffer de hardware pelo menos uma vez a cada intervalo de tempo igual a BatchLatencyMs, para garantir que nenhum dado seja descartado ou perdido. Quando o buffer FIFO de hardware for preenchido, ele deverá ser encapsulado e se comportar como um buffer circular, substituindo eventos mais antigos.