Boas Práticas Embarcadas
Regras para firmware Rust embarcado determinístico, seguro e com baixo consumo.
Como Usar Esta Lista
- Revise antes dos marcos de bring-up de hardware.
- Trate o design de ISR e o layout de memória como decisões de arquitetura.
- Meça stack, flash e RAM em cada candidato a release.
A - Memória e Segurança
- Prefira
heaplessem vez de heap. Buffers limitados com tratamento explícito de overflow. - Documente os proprietários de buffers estáticos. Lifetimes de DMA e ISR devem ser
'static. - Sem
unwrapem caminhos de produção. Usedefmt::unwrap!apenas em desenvolvimento. - Verificações de pico de stack. Padrão de preenchimento ou análise de stack com probe-rs antes do envio.
B - Interrupções e Temporização
- ISRs mínimas. Defina flags; adie o trabalho para tasks ou loop principal.
- Não bloqueie em ISR. Sem sleep de mutex, sem transações I2C.
- Documente o mapa de prioridade de interrupção. Conflitos de NVIC causam bugs latentes.
- Watchdog habilitado. Alimente apenas em caminhos de código conhecidos como bons.
C - Integração de Hardware
- Verifique a planilha de mux de pinos. Um pino, uma função.
- Pull-ups externos em I2C. Não assuma que os pull-ups internos são suficientes.
- Shift de nível em tensões mistas. Proteja as entradas de MCU de 3.3V.
- Modos SPI/I2C da datasheet. Modo incorreto parece chip morto.
D - Ferramentas e Debug
- Logging com defmt ou RTT. Evite UART-only quando SWD estiver disponível.
- ID de chip fixo com probe-rs. CI e máquinas de desenvolvimento flasheiam consistentemente.
-
cargo sizena CI. Falhe em caso de crescimento inesperado de flash/RAM. -
Cargo.lockreproduzível. Builds de firmware são artefatos sensíveis ao tempo.
E - Arquitetura
- HAL para aplicação, PAC com moderação. Manipulação de registradores apenas quando necessário.
- Drivers portáteis em
embedded-hal. Crate de placa conecta periféricos. - Feature por placa. Um crate de firmware, múltiplos
featurespara PCBs. - Plano de OTA/atualização documentado. Mesmo que seja apenas "arrastar e soltar USB".
FAQs
Heap é aceitável alguma vez?
Raramente, com alocador de pool e testes de imersão medindo fragmentação ao longo de semanas.
RTIC ou Embassy?
RTIC para prioridades preemptivas estritas; Embassy para firmware com muita rede assíncrona.
Quanto de headroom de flash?
Reserve 20% para atualizações de correção de bugs e recursos opcionais.
Testes unitários no host?
Teste algoritmos no target std. Testes de hardware para temporização e drivers.
Regras estilo MISRA?
A propriedade do Rust ajuda; ainda assim, reforce a ausência de unsafe sem revisão e invariantes documentadas.
Orçamento de energia?
Meça a corrente em modos de sono. Desabilite periféricos não utilizados após a inicialização.
Concorrência sem RTOS?
RTIC, Embassy ou atômicos lock-free. Evite static mut ad-hoc sem sincronização.
Retornos de campo?
Registre a versão do firmware e o hash git via defmt no boot para chamadas de suporte.
Schema para configuração?
Armazene a configuração da placa em flash com CRC. Migre versões explicitamente.
Drivers Rust vs C?
Prefira drivers Rust em embedded-hal. FFI para C apenas para blobs certificados ou de fornecedores.
Relacionados
- Noções Básicas de Embarcados - toolchain
- Programação no_std - modelo de memória
- Memória em Embarcados - buffers e heaps
- Depurando Firmware - observabilidade
Versões da Stack: Esta página foi escrita para Rust 1.97.0 (edição 2024), Tokio 1.x, Axum 0.8, serde 1.0, sqlx 0.8, clap 4, e Polars 0.46+.