Visão geral do projeto de baixo consumo de energia¶

Objetivo e público-alvo¶

Este guia apresenta o projeto de baixo consumo em dispositivos SF32: modos de energia, o que realmente consome a bateria e como organizar o firmware para que o sistema permaneça o maior tempo possível em estados de baixo consumo. O consumo de energia é uma questão que envolve o sistema como um todo: decisões sobre Bluetooth, gráficos, áudio e IA afetam o consumo e, por isso, este guia reúne esses efeitos.

A documentação do SDK da SiFli descreve o middleware PM (Power Management, gerenciamento de energia) baseado em RT-Thread para algumas plataformas, incluindo o SF32LB52x. Os modos disponíveis e o comportamento de despertar podem variar conforme o dispositivo e a configuração do SDK; consulte a documentação do dispositivo em questão. Nas famílias em que o SDK atribui as tarefas do controlador Bluetooth a um processador separado (consulte Arquitetura do processador Bluetooth), o processador separado pode tratar os eventos de rádio sem despertar a CPU da aplicação a cada evento. A possibilidade de ela permanecer suspensa depende da distribuição das tarefas, das fontes de despertar configuradas e do tráfego entre processadores; valide esse comportamento no dispositivo de destino.

Use esta página para transformar uma meta de autonomia em decisões de hardware e firmware sustentadas por medições. Ela se destina a engenheiros que precisam equilibrar standby conectado, display, áudio, sensores, IA e tempo de resposta ao usuário. Entrar em suspensão não se resume a chamar uma API.

Defina primeiro o orçamento de energia do produto¶

Antes de escrever o código de gerenciamento de energia, estabeleça o que o produto precisa atingir:

• Autonomia alvo, em horas, dias ou semanas, e capacidade da bateria.
• Ciclo de trabalho esperado: que proporção do dia o dispositivo passa em uso ativo, inativo mas conectado e totalmente suspenso?
• Quais eventos devem despertar o sistema e com que rapidez?
• Quais subsistemas precisam permanecer ativos, como um enlace Bluetooth, um display sempre ativo ou uma função de ativação por voz? Quais podem funcionar apenas em resposta a eventos?
• Comportamento de carga e ciclos de carga previstos, quando forem relevantes para a política de energia do produto.

Essas metas devem orientar cedo as decisões de arquitetura, incluindo a escolha do chip e do display e a viabilidade de recursos como escuta contínua de voz ou display sempre ativo dentro do orçamento de energia.

Modos de energia e framework PM¶

As categorias abaixo são estados conceituais do sistema, não uma lista exata dos modos de hardware SF32 nem dos valores de enumeração do SDK. Consulte a documentação do dispositivo e do SDK escolhidos para confirmar os modos disponíveis, as fontes de despertar e a retenção de estado:

Durante a execução normal, o sistema alterna entre estados. Uma fonte de despertar configurada desperta a CPU ou o subsistema; a sequência de despertar e restauração dos clocks varia conforme o dispositivo. Ao concluir o trabalho, os drivers ou tarefas responsáveis devem liberar as solicitações de PM que impedem a suspensão, para que a política configurada selecione um estado de baixo consumo permitido. A curva abaixo é ilustrativa: mostra transições relativas, não correntes ou tempos específicos de um dispositivo.

Diagrama: transições ilustrativas de energia durante uma tarefa curta

A seleção do modo de baixo consumo e o bloqueio da suspensão são mecanismos distintos. A referência do middleware PM para SF32LB52x e o guia de baixo consumo para SF32LB55x da SiFli documentam que rt_pm_request(PM_SLEEP_MODE_IDLE) bloqueia a entrada em LIGHT, DEEP e STANDBY até a chamada correspondente a rt_pm_release(PM_SLEEP_MODE_IDLE); essa solicitação não seleciona um modo mais profundo.

Para implementar a gestão de energia, consulte o guia oficial da família do dispositivo: SF32LB52x, SF32LB55x, SF32LB56x ou SF32LB58x. Os modos disponíveis, as condições de entrada, as fontes de despertar e o estado preservado dependem da família do chip, da placa e da configuração do SDK. O guia de baixo consumo do SF32LB52x inclui um exemplo de configuração dos pinos de despertar Hibernate, explicitamente agrupado para 58x/56x/52x/57x. A referência comum da API HAL PMU do SDK informa que, no SF32LB57x, o intervalo de índices usado por HAL_PMU_EnablePinWakeup() vai de 0 a 13. Essas fontes comprovam apenas essa configuração de pinos; não comprovam que a disponibilidade dos modos RT-Thread, os limites da política de PM ou o comportamento de retenção do 52x também se apliquem ao 57x. Confirme esses pontos na documentação do SDK e do dispositivo-alvo. Em geral, uma política configurada só pode selecionar um estado elegível mais profundo quando o intervalo de inatividade e as demais condições de entrada permitem. Uma solicitação não liberada pode manter o sistema em um estado mais superficial do que o previsto.

O que consome energia em um produto SF32¶

Cada subsistema tem um perfil de consumo diferente:

Nenhuma medida isolada resolve todos esses fatores. Em um produto real, é preciso ajustar a contribuição de cada subsistema e verificar o efeito conjunto, pois todos influenciam a profundidade de suspensão possível.

Projete o firmware para aproveitar a suspensão¶

Os maiores ganhos costumam vir da estrutura do firmware, não de truques de baixo nível:

• Prefira interrupções e eventos ao polling. Um loop de polling mantém a CPU ativa mesmo quando não há trabalho.
• Agrupe tarefas. Quando a latência permitir, acumule amostras de sensores, eventos Bluetooth ou blocos de áudio e processe-os juntos, em vez de despertar para cada item.
• Libere rapidamente as solicitações de PM que impedem o repouso. Um driver ou tarefa que mantém uma solicitação bloqueando a entrada em um estado de baixo consumo mais profundo deve liberar a solicitação correspondente assim que esse bloqueio deixar de ser necessário. Caso contrário, o sistema pode permanecer em um estado menos profundo que o previsto.
• Projete os caminhos de interface e áudio para responder a eventos, em vez de polling periódico baseado em temporizadores, quando o framework permitir.
• Revise os temporizadores. Um temporizador periódico agenda trabalho futuro e pode despertar o sistema ou reduzir o intervalo de inatividade disponível para a política de PM. Por isso, vários temporizadores aparentemente inofensivos podem reduzir o tempo nos estados mais profundos de baixo consumo.

Comece por um exemplo de energia validado¶

Antes de estimar a autonomia, escolha um exemplo do SDK que permita verificar o aspecto mais incerto do consumo. Exemplos de baixo consumo do SDK relacionam os projetos oficiais de PM, GPIO, processador, Bluetooth, display, GUI, atualização de tela e acendimento ao levantar o pulso aos cenários que verificam. A página também explica quais premissas sobre conexão de alimentação, placa, configuração, fonte de despertar, circuito externo e carga de trabalho precisam ser revalidadas antes de usar o exemplo como evidência para o produto.

Ajuste o consumo de Bluetooth¶

Os parâmetros de conexão e advertising são os principais ajustes para o consumo de Bluetooth; consulte a tabela completa na Visão geral do Bluetooth:

• Aumente o intervalo de conexão e a latência do periférico em enlaces que passam a maior parte do tempo inativos.
• Reduza a potência de TX ao menor nível que ainda atenda ao alcance necessário.
• Diminua a frequência de advertising quando o produto estiver aguardando reconexão, em vez de precisar facilitar a descoberta inicial.
• Quando o SDK escolhido trata eventos do controlador Bluetooth em um processador separado, a CPU da aplicação pode dormir entre eventos de conexão se nenhuma tarefa, fonte de despertar ou mensagem entre processadores exigir sua ativação. Despertá-la a cada callback Bluetooth reduz essa vantagem; confirme a distribuição de núcleos e tarefas no dispositivo de destino.

Para medir, por cenário, o consumo real com apenas Bluetooth clássico, apenas BLE e ambos operando em modo dual, consulte Medição e análise do consumo de energia em Bluetooth.

Consumo do display e da retroiluminação¶

Displays e retroiluminação frequentemente representam o maior consumo individual em produtos vestíveis ou portáteis:

• Use atualização parcial e de regiões alteradas em vez de redesenhar toda a tela quando o painel e a interface permitirem; consulte Controlador de display: atualização parcial.
• Durante a inatividade, reduza o brilho do display ou desligue a retroiluminação, se houver. Pare também as animações quando a tela estiver escurecida ou coberta.
• Para produtos com display sempre ativo, compare painéis como EPD, JDI/memory-in-pixel, AMOLED e TFT pela energia medida nesse modo e pela experiência de uso exigida. Escolha o painel e a política de operação que atendam ao orçamento, em vez de manter continuamente um modo normal de display ativo.
• Trate o display sempre ativo como uma linha independente no orçamento, pois ela muda substancialmente o significado de “inativo” para o produto.

Ajuste o consumo de IA e sensores¶

A inferência no dispositivo e a amostragem de sensores devem ser programadas deliberadamente, não executadas continuamente:

• Execute inferência apenas quando houver dados novos e úteis, não em um temporizador fixo independentemente da atividade na entrada.
• Transfira tarefas leves de sensoriamento contínuo para o processador de baixo consumo quando o dispositivo e o SDK permitirem, em vez de despertar a CPU principal a cada amostra.
• Meça energia por inferência ou por amostra, não apenas latência. Uma operação mais rápida só reduz o consumo se permitir que o sistema volte antes à suspensão.

Consulte a Visão geral de IA para aprofundar o equilíbrio entre precisão, latência e consumo.

Memória e clocks¶

O local de execução do código afeta tanto o desempenho quanto o consumo. Em dispositivos SF32 que implementam e habilitam os recursos de cache correspondentes, os caches de instruções e dados podem reduzir o tempo de espera por acessos à Flash ou à PSRAM. Menos tempo ativo pode deixar mais tempo para suspensão. Consulte STAR-MC1 para saber mais sobre cache e sistema de memória.

Além da CPU:

• PSRAM e Flash externas têm características próprias de consumo ativo e em standby. Verifique no datasheet o consumo de retenção e acesso, sobretudo se buffers grandes precisarem preservar seus dados durante a suspensão.
• A escolha da fonte de clock, cristal ou oscilador interno, e dos domínios de PLL/clock que permanecem ativos afeta a latência de despertar e o consumo em suspensão.
• Reduzir a frequência da CPU em fases menos exigentes pode ajudar, mas verifique se o aumento do tempo ativo não elimina o ganho. Meça a energia real, não apenas a corrente instantânea.

Hardware e RF¶

A política do firmware só pode funcionar dentro dos limites do hardware:

• A eficiência do PMIC/LDO nas correntes reais do produto importa mais que valores destacados para cargas sem relação com o uso.
• Layout de RF e ajuste da antena afetam a potência de TX necessária para obter alcance confiável. Um projeto de RF ruim força o firmware a compensar com mais potência e reduz a autonomia; consulte Arquitetura do processador Bluetooth: considerações sobre RF e clock.
• A precisão do cristal afeta as margens de temporização de RF e o quanto o firmware precisa ser conservador nos timeouts de supervisão e nas margens de despertar.
• Preveja acesso para teste e calibração na produção. O ajuste de energia e RF costuma continuar após a primeira revisão do hardware.

Caso prático: acender a tela ao levantar o pulso¶

Acender a tela quando o usuário levanta o pulso é um caso de uso comum em dispositivos vestíveis, mas a implementação depende do sensor, da placa e do SDK. O exemplo da SiFli para SF32LB52x destina-se à placa sf32lb52-lchspi-ulp e usa um LSM6DSL (acelerômetro/giroscópio), amostrando a aceleração a cada 200 ms para reconhecer os gestos de levantar e abaixar o pulso. O dispositivo entra em suspensão após 10 segundos de inatividade e desperta para acender o display ao detectar o gesto de levantar o pulso. Essa é uma implementação específica da placa e não demonstra que outros alvos usem interrupção do sensor ou o mesmo comportamento de PM. Se o sensor de destino oferecer interrupções de movimento ou de limite, o firmware poderá configurá-las como fonte de despertar para evitar polling contínuo pela CPU da aplicação. Caso contrário, inclua a amostragem do sensor e os despertares da CPU no orçamento de energia. Verifique o sensor, a placa, as fontes de despertar e a configuração de PM do alvo específico.

Planilha de orçamento de energia¶

Transforme as metas do produto em números antes de ajustar o firmware. Uma planilha simples costuma ser suficiente:

Para um conjunto de estados de operação mutuamente exclusivos, estime average current = state current x duty cycle e some as contribuições de cada estado. Se houver cargas simultâneas, inclua-as no total do cenário correspondente para não contar estados sobrepostos duas vezes. Isso revela problemas de projeto cedo: uma meta de 20 μA em suspensão não compensa um produto que passa tempo demais com retroiluminação intensa ou inferência ativa em intervalos fixos.

Análise de consumo: modele, meça e atualize¶

A análise de consumo transforma o orçamento em um ciclo de engenharia reproduzível. Defina cenários representativos, registre tensão e corrente no limite de alimentação pertinente e considere a duração e a frequência de cada carga. Calcule a energia ao longo do tempo e concilie as medições por linha de alimentação com o consumo no lado da bateria, incluindo as perdas de conversão; não some diretamente correntes de linhas com tensões diferentes. Assim, estime a corrente média da bateria, a carga consumida por dia e a autonomia, além de priorizar os cenários que devem ser medidos e otimizados.

flowchart LR
    A["Definir cenários representativos do produto"] --> B["Definir premissas de corrente, tensão, duração e frequência"]
    B --> C["Calcular energia por evento e por dia"]
    C --> D["Comparar com o orçamento da bateria e ordenar os consumos"]
    D --> E["Medir os cenários prioritários no hardware de destino"]
    E --> F["Atualizar o modelo com corrente e tempos medidos"]
    F --> B

Trate o perfil como uma estimativa, não como uma medição. O Online Power Profiler for Bluetooth LE da Nordic segue o mesmo princípio: usa modelos derivados de medições, mas seus resultados são valores esperados, não a medição de um produto específico. A corrente pode variar com o silício, o projeto da placa, a tensão da bateria, a temperatura, as condições de RF, a temporização do firmware e o caso de uso.

Em cada cenário, registre as premissas que afetam significativamente a energia:

• Quais subsistemas estão ligados e em que modo de energia o MCU realmente entra?
• Qual é a corrente na entrada da bateria ou em cada linha de alimentação regulada?
• Quanto tempo dura a tarefa e quantas vezes ela ocorre em um dia típico?
• Quais picos de corrente são esperados e quais indicam trabalho desnecessário ou falha ao entrar em suspensão?

Use a estimativa para identificar as maiores parcelas do orçamento e valide os cenários no hardware antes de declarar a autonomia. Análise de consumo de um smartwatch aplica esse método a um modelo de uso diário; Medição e validação do consumo de energia define o fluxo de captura reproduzível.

Revise as responsabilidades de PM e as fontes de despertar¶

Um projeto de baixo consumo confiável precisa de um responsável claro para cada fonte de despertar e cada solicitação que iniba a suspensão. Acompanhe estes itens na revisão:

Durante a depuração, registre a política de PM configurada, as solicitações ativas que inibem modos mais profundos e o último modo de baixo consumo indicado pelo SDK ou pelos logs. Se o sistema chegar a um estado mais superficial do que o esperado, esses dados costumam ser mais úteis que o valor de corrente isolado.

Meça o consumo na prática¶

Não adivinhe: meça. Um conjunto básico para validar o consumo inclui:

• Uma ponta de prova de corrente ou analisador de potência em série entre bateria/fonte e placa.
• Cenários que correspondam ao uso real: conectado e inativo, interação com a interface, reprodução de áudio, inferências breves de IA e a pior carga combinada.
• Registro ou marcação dos estados do firmware, ativo/inativo/suspensão, junto com a curva de consumo para atribuir picos de corrente a caminhos de código específicos.

A documentação do SDK da SiFli oferece exemplos de caracterização de consumo para alguns dispositivos e placas, incluindo cenários com displays AMOLED e JDI, GPIO, BLE/Bluetooth Classic e carga de CPU semelhante a CoreMark. Consulte a documentação do SDK e da placa de destino para confirmar a disponibilidade e a configuração. Os exemplos aplicáveis podem servir como referência de medição e verificação de plausibilidade, mas não garantem o consumo do produto.

Matriz de validação de energia¶

Use cenários reproduzíveis para comparar melhorias entre revisões do firmware. No mínimo, meça:

Registre versão do firmware, revisão da placa, tensão da bateria/fonte, temperatura, configuração de antena/gabinete e script de teste. Sem esses dados, os valores de consumo ficam difíceis de comparar e fáceis de interpretar incorretamente.

Investigue o consumo elevado¶

Erros comuns¶

• Tratar a otimização de energia como acabamento final, em vez de requisito de projeto desde o início.
• Fazer polling de sensores, estado Bluetooth ou temporizadores em vez de usar interrupções e eventos.
• Deixar uma solicitação de PM ativa após concluir o trabalho que a exigia.
• Redesenhar toda a tela para pequenas mudanças na interface.
• Ignorar a qualidade do layout de RF e compensar com mais potência de TX no firmware.
• Medir apenas corrente instantânea em vez da energia de um cenário de uso realista.
• Validar apenas na bancada, nunca no gabinete final com antena e bateria reais.

Checklist de bring-up¶

• Defina autonomia alvo, ciclo de trabalho e fontes de despertar necessárias.
• Identifique quais subsistemas precisam permanecer ativos continuamente e quais podem ser totalmente acionados por eventos.
• Confirme que cada driver/tarefa libera a solicitação de PM logo após o uso.
• Ajuste os parâmetros de advertising/conexão Bluetooth ao uso real do produto.
• Confirme a atualização parcial quando disponível e uma política de retroiluminação compatível com o uso.
• Revise os temporizadores periódicos e elimine ou agrupe os desnecessários.
• Prepare a medição de corrente e valide separadamente os estados ativo, inativo e em suspensão.
• Teste a pior carga combinada, Bluetooth + display + áudio + IA conforme aplicável, e confirme o orçamento de energia.
• Revalide o consumo após cada mudança significativa de firmware, não apenas no fim do projeto.

Pontos principais¶

• O consumo é uma propriedade do sistema: Bluetooth, display, áudio, IA e memória determinam a profundidade e a frequência da suspensão.
• A política de PM configurada escolhe entre os estados de baixo consumo permitidos; uma solicitação não liberada que iniba modos mais profundos pode manter o sistema em um estado mais superficial do que o previsto.
• Em quase todas as situações em que energia importa, o projeto por eventos e interrupções é melhor que polling.
• Os parâmetros de conexão Bluetooth e a atualização do display costumam ser os dois maiores ajustes em um produto vestível conectado.
• Meça energia real com cargas combinadas e realistas no hardware dentro do gabinete final. Medições de bancada ou de subsistemas isolados podem subestimar o consumo do produto real.

Para estimar a porcentagem restante da bateria a partir da tensão, consulte Estimativa do estado de carga da bateria.

Última atualização: 2026-10-21