O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.
Esta página foi traduzida pela API Cloud Translation.
Switch to English

Lote

O que é lote?

Lote refere-se a eventos de sensor de buffer em um hub de sensor e / ou FIFO de hardware antes de relatar os eventos através do HAL de sensores . O local em que os eventos do sensor são armazenados em buffer (hub do sensor e / ou FIFO de hardware) é referido como "FIFO" nesta página. Quando o lote de eventos do sensor não está ativo, os eventos do sensor são imediatamente relatados ao HAL dos sensores, quando disponíveis.

O lote pode permitir uma economia significativa de energia, ativando apenas o processador de aplicativos principais (AP), que executa o Android, quando muitos eventos do sensor estão prontos para serem processados, em vez de ativá-lo para cada evento individual. A economia de energia em potencial está diretamente correlacionada ao número de eventos que o hub do sensor e / ou o FIFO podem armazenar em buffer: há um potencial maior de economia de energia se mais eventos puderem ser agrupados. Os lotes utilizam o uso de memória de baixa potência para reduzir o número de despertares de AP de alta potência.

Os lotes podem ocorrer apenas quando um sensor possui um FIFO de hardware e / ou pode armazenar eventos em buffer em um hub de sensores. Nos dois casos, o sensor deve relatar o número máximo de eventos que podem ser agrupados de uma vez por meio de SensorInfo.fifoMaxEventCount .

Se um sensor tiver espaço reservado em um FIFO, ele deverá relatar o número de eventos reservados por meio de SensorInfo.fifoReservedEventCount . Se o FIFO for dedicado ao sensor, SensorInfo.fifoReservedEventCount será o tamanho do FIFO. Se o FIFO for compartilhado entre vários sensores, esse valor poderá ser zero. Um caso de uso comum é permitir que um sensor use o FIFO inteiro, se for o único sensor ativo. Se vários sensores estiverem ativos, cada sensor SensorInfo.fifoReservedEventCount espaço garantido para pelo menos eventos SensorInfo.fifoReservedEventCount no FIFO. Se um hub de sensor for usado, a garantia poderá ser aplicada por meio de software.

Os eventos do sensor são agrupados nas seguintes situações:

  • A latência máxima de relatório atual do sensor é maior que zero, o que significa que os eventos do sensor podem ser adiados até a latência máxima do relatório antes de serem relatados pelo HAL.
  • O ponto de acesso está no modo de suspensão e o sensor é um sensor que não é de ativação. Nesse caso, os eventos não devem ativar o AP e devem ser armazenados até que o AP seja ativado.

Se um sensor não suportar lotes e o AP estiver em suspensão, apenas os eventos do sensor de ativação serão relatados ao AP e os eventos de não ativação não deverão ser relatados ao AP.

Parâmetros de lote

Os dois parâmetros que governam o comportamento do lote são sampling_period_ns e max_report_latency_ns . sampling_period_ns determina com que frequência um novo evento de sensor é gerado e max_report_latency_ns determina quanto tempo até que o evento deva ser relatado ao HAL de Sensores.

sampling_period_ns

O significado do parâmetro sampling_period_ns depende do modo de relatório do sensor especificado:

  • Contínuo: sampling_period_ns é a taxa de amostragem, ou seja, a taxa na qual os eventos são gerados.
  • Em mudança: sampling_period_ns limita a taxa de amostragem de eventos, o que significa que os eventos são gerados não mais rápido que todos sampling_period_ns nanossegundos sampling_period_ns . Os períodos podem ser maiores que sampling_period_ns se nenhum evento for gerado e os valores medidos não mudarem por longos períodos. Para mais detalhes, consulte o modo de relatório de alteração .
  • Um tiro: sampling_period_ns é ignorado. Não tem efeito.
  • Especial: para obter detalhes sobre como sampling_period_ns é usado para sensores especiais, consulte Tipos de sensores .

Para obter mais informações sobre o impacto de sampling_period_ns nos diferentes modos, consulte Modos de relatório .

Para sensores contínuos e em mudança:

  • se sampling_period_ns for menor que SensorInfo.minDelay , a implementação do HAL deverá silenciosamente fixá-la ao max(SensorInfo.minDelay, 1ms) . O Android não suporta a geração de eventos em mais de 1000 Hz.
  • se sampling_period_ns for maior que SensorInfo.maxDelay , a implementação do HAL deverá silenciosamente truncá-la para SensorInfo.maxDelay .

Às vezes, os sensores físicos têm limitações nas taxas em que podem funcionar e na precisão de seus relógios. Para explicar isso, a frequência de amostragem real pode diferir da frequência solicitada, desde que atenda aos requisitos da tabela abaixo.

Se a frequência solicitada for

Então a frequência real deve ser

abaixo da frequência mínima (<1 / maxDelay)

entre 90% e 110% da frequência mínima

entre a frequência mínima e máxima

entre 90% e 220% da frequência solicitada

acima da frequência máxima (> 1 / minDelay)

entre 90% e 110% da frequência máxima e abaixo de 1100 Hz

max_report_latency_ns

max_report_latency_ns define o tempo máximo em nanossegundos, pelo qual os eventos podem ser atrasados ​​e armazenados no FIFO do hardware antes de serem relatados pelo HAL enquanto o AP está ativado.

Um valor zero significa que os eventos devem ser relatados assim que medidos, ignorando completamente o FIFO ou esvaziando o FIFO assim que um evento do sensor estiver presente.

Por exemplo, um acelerômetro ativado em 50 Hz com max_report_latency_ns=0 acionará interrupções 50 vezes por segundo quando o AP estiver ativado.

Quando max_report_latency_ns>0 , os eventos do sensor não precisam ser relatados assim que são detectados. Eles podem ser armazenados temporariamente no FIFO e relatados em lotes, desde que nenhum evento seja atrasado em mais de max_report_latency_ns nanossegundos. Isso significa que todos os eventos desde o lote anterior são registrados e retornados de uma só vez. Isso reduz a quantidade de interrupções enviadas ao ponto de acesso e permite que o ponto de comutação passe para um modo de energia mais baixo (inativo) enquanto o sensor está capturando e agrupando dados.

Cada evento tem um registro de data e hora associado a ele. Atrasar a hora em que um evento é relatado não afeta o carimbo de data e hora do evento. O registro de data e hora deve ser preciso e corresponder à hora em que o evento ocorreu fisicamente, não à hora em que foi relatado.

Permitir que os eventos do sensor sejam armazenados temporariamente no FIFO não modifica o comportamento de enviar eventos ao HAL; eventos de diferentes sensores podem ser intercalados e todos os eventos do mesmo sensor são ordenados por tempo.

Eventos de despertar e não despertar

Os eventos do sensor dos sensores de ativação devem ser armazenados em um ou mais FIFOs de ativação. Um projeto comum é ter um FIFO de ativação único, grande e compartilhado, onde os eventos de todos os sensores de ativação são intercalados. Como alternativa, você pode ter um FIFO de ativação por sensor ou ter FIFOs dedicados para sensores de ativação específicos e um FIFO compartilhado para o restante dos sensores de ativação.

Da mesma forma, os eventos do sensor de sensores sem ativação devem ser armazenados em um ou mais FIFOs sem ativação.

Em todos os casos, eventos de sensor de ativação e eventos de sensor de ativação não podem ser intercalados no mesmo FIFO. Os eventos de ativação devem ser armazenados em um FIFO de ativação e os eventos que não são de ativação devem ser armazenados em um FIFO de ativação.

Para o FIFO de ativação, o design único, grande e compartilhado do FIFO oferece os melhores benefícios de energia. Para o FIFO sem ativação, o FIFO único, grande e compartilhado e vários projetos pequenos de FIFO reservados têm características de energia semelhantes. Para obter mais sugestões sobre como configurar cada FIFO, consulte Prioridade de alocação FIFO .

Comportamento fora do modo de suspensão

Quando o AP está ativado (não no modo de suspensão), os eventos são armazenados temporariamente nos FIFOs, desde que não sejam atrasados ​​em mais de max_report_latency .

Enquanto o AP não entrar no modo de suspensão, nenhum evento será descartado ou perdido. Se FIFOs internos ficarem cheios antes que max_report_latency , os eventos serão relatados nesse ponto para garantir que nenhum evento seja perdido.

Se vários sensores compartilham o mesmo FIFO e o max_report_latency de um deles decorre, todos os eventos do FIFO são relatados, mesmo que o max_report_latency dos outros sensores ainda não tenha decorrido. Isso reduz o número de vezes que lotes de eventos são relatados. Quando um evento deve ser relatado, todos os eventos de todos os sensores são relatados.

Por exemplo, se os seguintes sensores estiverem ativados:

  • acelerômetro em lote com max_report_latency = 20s
  • giroscópio em lotes com max_report_latency = 5s

Os lotes do acelerômetro são relatados ao mesmo tempo que os lotes do giroscópio são relatados (a cada 5 segundos), mesmo que o acelerômetro e o giroscópio não compartilhem o mesmo FIFO.

Comportamento no modo de suspensão

O lote é particularmente benéfico para a coleta de dados do sensor em segundo plano, sem manter o AP acordado. Como os drivers do sensor e a implementação do HAL não têm permissão para reter uma trava de ativação *, o ponto de acesso pode entrar no modo de suspensão mesmo enquanto os dados do sensor estão sendo coletados.

O comportamento dos sensores enquanto o AP está suspenso depende se o sensor é um sensor de ativação. Para mais detalhes, consulte Sensores de ativação .

Quando um FIFO sem ativação é preenchido, ele deve se agrupar e se comportar como um buffer circular, substituindo eventos mais antigos pelos novos, substituindo os antigos. max_report_latency não tem impacto nos FIFOs sem ativação, enquanto estiver no modo de suspensão.

Quando um FIFO de ativação é preenchido ou quando a max_report_latency de um dos sensores de ativação termina, o hardware deve ativar o AP e relatar os dados.

Nos dois casos (ativação e não ativação), assim que o AP sai do modo de suspensão, um lote é produzido com o conteúdo de todos os FIFOs, mesmo que o max_report_latency de alguns sensores ainda não tenha decorrido. Isso minimiza o risco de o AP ter que acordar novamente logo após retornar ao modo de suspensão e, portanto, minimiza o consumo de energia.

* Uma exceção notável dos motoristas que não podem reter uma trava de ativação é quando um sensor de ativação com o modo de relatório contínuo é ativado com max_report_latency <1 segundo. Nesse caso, o driver pode reter um bloqueio de ativação porque o AP não tem tempo para entrar no modo de suspensão, pois seria despertado por um evento de ativação antes de acessar o modo de suspensão.

Precauções a serem tomadas ao agrupar sensores de ativação

Dependendo do dispositivo, pode demorar alguns milissegundos para que o AP saia completamente do modo de suspensão e comece a liberar o FIFO. É necessário alocar espaço suficiente no FIFO para permitir que o dispositivo saia do modo de suspensão sem que o FIFO seja excedido. Nenhum evento será perdido e a max_report_latency deve ser respeitada.

Precauções a serem tomadas ao usar sensores de mudança sem ativação

Os sensores em mudança só geram eventos quando o valor que eles estão medindo está mudando. Se o valor medido mudar enquanto o PA estiver no modo de suspensão, os aplicativos esperam receber um evento assim que o PA acordar. Por esse motivo, o lote de eventos de sensor de mudança sem ativação deve ser realizado com cuidado se o sensor compartilhar seu FIFO com outros sensores. O último evento gerado por cada sensor de mudança sempre deve ser salvo fora do FIFO compartilhado para que nunca possa ser substituído por outros eventos. Quando o AP acorda, após todos os eventos do FIFO terem sido relatados, o último evento do sensor em mudança deve ser relatado.

Aqui está uma situação a evitar:

  1. Um aplicativo é registrado no contador de etapas sem ativação (em mudança) e no acelerômetro sem ativação (contínuo), ambos compartilhando o mesmo FIFO.
  2. O aplicativo recebe um evento de contador de etapas step_count=1000 steps código de step_count=1000 steps >.
  3. O AP vai suspender.
  4. O usuário caminha 20 etapas, fazendo com que os eventos do contador de etapas e do acelerômetro sejam intercalados, sendo o último evento do contador de etapas step_count = 1020 steps .
  5. O usuário não se move por um longo tempo, fazendo com que os eventos do acelerômetro continuem se acumulando no FIFO, substituindo eventualmente todos os eventos step_count no FIFO compartilhado.
  6. O AP acorda e todos os eventos do FIFO são enviados para o aplicativo.
  7. O aplicativo recebe apenas eventos do acelerômetro e acha que o usuário não andou.

Ao salvar o último evento do contador de etapas fora do FIFO, o HAL pode relatar esse evento quando o AP acordar, mesmo que todos os outros eventos do contador de etapas tenham sido substituídos por eventos do acelerômetro. Dessa maneira, o aplicativo recebe step_count = 1020 steps quando o AP é ativado.

Implementando lotes

Para economizar energia, o lote deve ser implementado sem o auxílio do ponto de acesso, e o ponto de acesso deve ser suspenso durante o lote.

Se o lote for realizado em um cubo de sensor, o uso de energia do cubo de sensor deverá ser minimizado.

A latência máxima do relatório pode ser modificada a qualquer momento, principalmente enquanto o sensor especificado já estiver ativado; e isso não deve resultar na perda de eventos.

Prioridade de alocação FIFO

Nas plataformas em que o tamanho do buffer do FIFO do hardware e / ou do hub do sensor é limitado, os projetistas de sistemas podem ter que escolher quanto FIFO reservar para cada sensor. Para ajudar nessa escolha, aqui está uma lista de possíveis aplicativos quando o lote é implementado nos diferentes sensores.

Valor alto: contagem de mortos de pedestres de baixa potência

Tempo de lote desejado: 1 a 10 minutos

Sensores para lote:

  • Detector de degrau de despertar
  • Vetor de rotação do jogo de despertar a 5 Hz
  • Barômetro de despertar a 5 Hz
  • Magnetômetro não calibrado de ativação em 5 Hz

O agrupamento desses dados permite executar o cálculo de mortos de pedestres e deixar o AP suspender.

Valor alto: atividade intermitente de média potência / reconhecimento de gestos

Tempo de lote desejado: 3 segundos

Sensores em lote: Acelerômetro sem despertar a 50 Hz

O agrupamento desses dados permite reconhecer periodicamente atividades e gestos arbitrários sem ter que manter o AP acordado enquanto os dados são coletados.

Valor médio: atividade contínua de média potência / reconhecimento de gestos

Tempo de lote desejado: 1 a 3 minutos

Sensores em lote: Acelerômetro de despertar a 50 Hz

O agrupamento desses dados permite o reconhecimento contínuo de atividades e gestos arbitrários sem a necessidade de manter o AP acordado enquanto os dados são coletados.

Valor médio-alto: Redução de carga de interrupção

Tempo de lote desejado: <1 segundo

Sensores em lote: qualquer sensor de alta frequência, geralmente sem despertar.

Se o giroscópio estiver definido em 240 Hz, mesmo o lote de apenas 10 eventos de giroscópio poderá reduzir o número de interrupções de 240 / segundo para 24 / segundo.

Valor médio: coleta contínua de dados de baixa frequência

Tempo de lote desejado: 1 a 10 minutos

Sensores para lote:

  • Barômetro de despertar a 1 Hz
  • Sensor de umidade de despertar a 1 Hz
  • Outros sensores de ativação de baixa frequência a taxas semelhantes

Permite criar aplicativos de monitoramento com baixo consumo de energia.

Valor médio-baixo: coleta contínua de sensores completos

Tempo de lote desejado: 1 a 10 minutos

Sensores em lote: todos os sensores de ativação, em altas frequências

Permite a coleta completa de dados do sensor enquanto deixa o AP no modo de suspensão. Considere apenas se o espaço FIFO não é um problema.