Teu progresso
0 / 83 módulos0%
Estágio 05 · 05-07
BloqueadoSoftware roda em mais que servidores e laptops. Carros, tracking devices, sensores de logística, IoT industrial, médicos, bilhões de microcontroladores rodando código com 32KB RAM, sem GC, sem OS, talvez com RTOS, em conexão flaky 2G/LoRa/BLE. Cloud-only engineer perde porção significativa da computação real.
Pra Logística, embedded é altamente relevante: tracker GPS no caminhão, sensor de temperatura em entrega refrigerada, leitor de barcode/QR custom, beacon BLE em hub. Construir hardware ou stack mobile-edge expande o que produto pode fazer.
Este módulo é embedded suficiente pra Staff que talvez nunca seja embedded full-time mas precisa entender quando contratar, integrar, ou fazer um wedge inicial. Microcontrollers (Arm Cortex-M, ESP32), RTOS (FreeRTOS, Zephyr), bare-metal vs RTOS, constrained networks (LoRa, NB-IoT, BLE, MQTT), OTA updates, security em devices, telemetry pipeline. Plus quando NÃO embedded (overengineering pra problema que app mobile resolve).
Optional pra Staff cujo eixo é cloud-only. Obrigatório se Logística genuinely envolve hardware.
Logística likely uses: MCU em tracker custom, MPU em router de hub, smartphone como driver tool.
Real-Time Operating System:
Popular:
Bare metal (sem RTOS): main loop + interrupts. Simples, escala mal acima de poucas tasks.
Sem heap dinâmico em hard real-time. Static allocation, pools de tamanho fixo.
Stack overflow não há helper, debug via canários, watermarks.
Linker scripts decidem layout (text, data, bss, heap, stack) em flash + RAM.
Interrupt: hardware sinaliza CPU. ISR (Interrupt Service Routine) responde. Restrições:
ISR + RTOS: defer trabalho pra task via queue/sema.
Battery-powered devices: deep sleep dominante. Patterns:
Months/years de bateria possíveis com discipline.
Logística trackers usually: cellular (NB-IoT) outdoor + BLE local.
QoS levels MQTT: 0 (fire-and-forget), 1 (at-least-once), 2 (exactly-once via 4-way).
Crítico. Device em campo precisa update sem visit físico.
Patterns:
Failures podem brick device. Test extensively.
Threats únicos:
Defesas:
PCI-DSS-like padrões em payment terminals (PCI PTS).
Device → broker → cloud → time-series store (03-13) → dashboards.
Backpressure quando connection cai: device buffers locally, replays. SD/flash log.
Schema: protobuf compacto > JSON em links escassos. Avro também usado.
Cobertura difícil. Pesquisa ativa.
IDEs: PlatformIO (popular para multi-platform), STM32CubeIDE, Espressif IDF, Zephyr's west.
Rust embedded ganhou maturidade industrial 2023-2026 (Espressif oficializou Rust em ESP32; Linux kernel aceitando drivers em Rust). Stack típico:
HAL trait pattern (embedded-hal crate): abstrações vendor-neutral sobre periféricos.
use embedded_hal::digital::OutputPin;
use embedded_hal::i2c::I2c;
// Driver de sensor escrito uma vez, roda em STM32, ESP32, RP2040, nRF52, ...
pub struct DhtSensor<I, P> where I: I2c, P: OutputPin {
i2c: I,
power_pin: P,
}
impl<I: I2c, P: OutputPin> DhtSensor<I, P> {
pub fn read(&mut self) -> Result<f32, Error> { /* ... */ }
}
Cada vendor implementa o trait com seu HAL crate (stm32f4xx-hal, esp-hal, rp2040-hal, nrf-hal). Driver de aplicação fica portável.
no_std vs std vs std com allocator custom:
#![no_std]: sem heap, sem stdlib. Defaults pra MCU pequeno (STM32 Cortex-M0, M3). Tudo &'static ou stack-allocated.#![no_std] + alloc: heap via custom allocator (linked_list_allocator, embedded-alloc). Permite Box, Vec, mas você decide tamanho do heap.std: precisa OS abaixo (Linux embarcado, Tock OS). MCUs maiores (Cortex-A) ou embedded Linux.Async runtimes em embedded:
| Runtime | Modelo | Quando |
|---|---|---|
| embassy | async/await em no_std, executor cooperativo, integra HAL async | Default moderno; HAL async em quase todos vendors em 2026 |
| RTIC (Real-Time Interrupt-driven Concurrency) | Static priority scheduling, SoftIRQ-like | Quando timing é crítico (ms determinístico) |
| Tock OS | Multiprocesso real, isolation entre apps | Plataforma multi-tenant em embedded (raro) |
Embassy Logística (firmware do tracker do desafio):
#[embassy_executor::task]
async fn gps_task(mut uart: Uart<'static>) {
let mut buf = [0u8; 256];
loop {
let n = uart.read(&mut buf).await.unwrap();
// parse NMEA, broadcast position via channel
}
}
#[embassy_executor::task]
async fn telemetry_task(mut socket: TcpSocket<'static>) {
Timer::after_secs(30).await;
// send batched telemetry via MQTT
}
defmt — logging compactado: serializa logs binários (não strings) → host-side decoder reconstrói. 10-100x menor que printf. Crítico em MCU sem console grande.
defmt::info!("GPS lock: lat={=f32} lng={=f32}", lat, lng);
// transmitido como ~10 bytes vs ~80 bytes em printf
probe-rs — debugger/flasher universal: substitui OpenOCD + gdb + STLink utility com 1 binário em Rust. cargo flash --chip STM32F411RETx ou cargo embed (RTT log + flash + reset em 1 comando).
Quando Rust vs C em 2026:
Flash wear-out (NAND). Filesystem aware:
Logs e config persistem; mas evite write-heavy.
Staff IT often interage com firmware/hardware engineers. Vocabulário:
Não substitui EE, but ajuda comunicação.
Direct (device → cloud over MQTT/HTTP) vs via gateway (device → BLE/Zigbee → gateway → cloud).
Trade-off: gateway adds dependência mas reduz cellular cost (1 modem vez de N).
Trabalho em device em vez de cloud. ML inference em MCU (TinyML, TensorFlow Lite Micro). Privacy-preserving (data não sai).
Trade-off: dev complexity vs cloud cost reduzido.
Default: smartphone como compute + sensors + network. Custom hardware quando:
90% dos casos B2B SaaS, smartphone basta. Don't over-engineer.
Nem todos justificam build próprio; smartphone-app-only sim.
Cruza com: 05-02 §2.11 (Capstone B on-device AI — overlap com edge AI em embedded), 02-17 §2.20 (mobile native — patterns que cross-over com edge IoT).
Você precisa, sem consultar:
Construir tracker IoT mínimo integrado à Logística, opcional simulado em ESP32 dev kit ($10).
Relação com 05-08 (Hardware Design): este desafio cobre o lado firmware (MQTT, sleep, OTA, buffer, telemetry). O desafio do 05-08 cobre o lado hardware do mesmo dispositivo (schematic + PCB + BOM + manufacturing files). Use MCU e sensors consistentes entre os dois (ESP32 + GPS NEO-6M + DHT22 é uma escolha viável que aparece em ambos os módulos). Se você está fazendo o eixo embedded/hardware completo (track A/B do CAPSTONE-amplitude com foco IoT), o output integrado é firmware-em-PCB-custom validado por bring-up real.
Hardware (escolha 1 path):
iot_pings).EMBEDDED-DECISIONS.md:
Threshold de Maestria
Acerte todas as 5 pra marcar o módulo como concluído. Sem pressa, sem timer. Tudo fica salvo no teu navegador.
Q1Quais restricoes governam uma ISR (Interrupt Service Routine) em RTOS?
Q2Qual rede e adequada para tracker de logistica outdoor com bateria de meses?
Q3Por que A/B partition e o padrao para OTA updates?
Q4Em Rust embedded, qual e o papel do crate embedded-hal?
Q5Quando NAO investir em hardware custom para um produto B2B?
Destrava
05-07 é prereq dos seguintes módulos: