Sistemas Embarcados e IoT
Video da aula estara disponivel em breve
O que e um Sistema Embarcado?
Um sistema embarcado e um sistema computacional projetado para executar uma funcao dedicada dentro de um sistema maior. Diferente de um computador de proposito geral (PC), um sistema embarcado e otimizado para uma tarefa especifica, com restricoes de custo, consumo de energia, tamanho e — frequentemente — tempo real.
Exemplos cotidianos de sistemas embarcados:
- Modulo de injecao eletrônica de um automovel (dezenas de ECUs por carro)
- Controlador de uma maquina de lavar (sensor de nivel, motor, temporizador)
- Firmware de um roteador Wi-Fi (stack TCP/IP, firewall, DHCP)
- Marcapasso cardiaco (restricoes extremas de seguranca e energia)
- Sistema de controle de voo de um drone (fusao de sensores, PID, comunicacao)
┌──────────────────────────────────────────────┐
│ Mundo Fisico (ambiente) │
└────────┬────────────────────────┬────────────┘
│ sensores │ atuadores
v ^
┌────────────────┐ ┌─────────────────┐
│ Condicionamento│ │ Drivers de │
│ de Sinal │ │ Potencia │
│ (amp, filtro) │ │ (ponte H, PWM) │
└───────┬────────┘ └────────┬────────┘
│ ADC │ DAC/GPIO
v ^
┌──────────────────────────────────────┐
│ Microcontrolador │
│ ┌─────────┐ ┌──────────┐ │
│ │ CPU │ │ Firmware │ │
│ │ │ │ (bare- │ │
│ │ Timer │ │ metal │ │
│ │ UART │ │ ou RTOS)│ │
│ │ ADC │ │ │ │
│ └─────────┘ └──────────┘ │
└──────────────┬───────────────────────┘
│ comunicacao
v
┌──────────────────────────────────────┐
│ Interface (display, LEDs, rede) │
└──────────────────────────────────────┘
Restricoes de Tempo Real
Muitos sistemas embarcados são sistemas de tempo real — devem responder a eventos dentro de prazos (deadlines) rigidos. Ha dois tipos:
- Hard real-time: perder um deadline causa falha catastrofica. Exemplo: sistema de freio ABS (deve responder em microsegundos), marcapasso cardiaco, sistema de controle de voo.
- Soft real-time: perder um deadline degrada a qualidade mas nao causa falha critica. Exemplo: streaming de video (frame atrasado causa glitch, nao crash), sistema de automacao residencial.
Interfaceamento com Sensores
Sensores convertem grandezas fisicas em sinais eletricos que o microcontrolador pode processar:
Grandeza Sensor Interface Saida
──────────────────────────────────────────────────────────────
Temperatura LM35, DS18B20 Analog/1-Wire 0.01V/°C
BME280 I2C/SPI Digital
Umidade DHT22, BME280 1-Wire/I2C Digital
Pressao BMP280, BME280 I2C/SPI Digital
Distancia HC-SR04 (ultra-som) GPIO (trigger) Pulso
VL53L0X (ToF laser) I2C Digital
Aceleracao MPU6050 (6-axis) I2C Digital
Luminosidade LDR (resistor) Analog (ADC) Resistencia
Corrente ACS712 Analog (ADC) Proporcional
Presenca PIR HC-SR501 GPIO Digital (0/1)
// Leitura simplificada do sensor BME280 via I2C
// Endereco I2C: 0x76 ou 0x77
float ler_temperatura_bme280(void) {
uint8_t data[3];
// 1. Enviar endereco do registrador de temperatura
i2c_start();
i2c_write(0x76 << 1); // endereco do dispositivo + write
i2c_write(0xFA); // registrador temp_msb
// 2. Ler 3 bytes de dados
i2c_start(); // repeated start
i2c_write((0x76 << 1) | 1); // endereco + read
data[0] = i2c_read_ack(); // MSB
data[1] = i2c_read_ack(); // LSB
data[2] = i2c_read_nack(); // XLSB (4 bits)
i2c_stop();
// 3. Combinar bytes e aplicar compensacao
int32_t raw = (data[0] << 12) | (data[1] << 4) | (data[2] >> 4);
return compensar_temperatura(raw); // algoritmo do datasheet
}
Protocolos de Comunicacao IoT
A Internet das Coisas (IoT) conecta sistemas embarcados a internet. Os protocolos de comunicacao mais usados diferem dos protocolos web tradicionais, pois precisam funcionar com restricoes de banda, energia e processamento:
- MQTT (Message Queuing Telemetry Transport): protocolo publish/subscribe sobre TCP. Extremamente leve (header de 2 bytes). Ideal para sensores que publicam dados periodicamente. Usa um broker central (ex: Mosquitto, HiveMQ).
- CoAP (Constrained Application Protocol): similar a HTTP mas sobre UDP. Modelo request/response, otimizado para dispositivos com pouca memoria. Suporta observacao (servidor notifica cliente de mudancas).
- HTTP/REST: protocolo web padrao. Mais pesado, mas amplamente suportado. Usado quando o dispositivo tem recursos suficientes (ESP32, Raspberry Pi).
- LoRaWAN: comunicacao de longo alcance (ate 15 km), baixissima taxa de dados (0.3-50 kbps). Ideal para sensores remotos com bateria.
- BLE (Bluetooth Low Energy): curto alcance (~30m), baixo consumo. Ideal para wearables e dispositivos proximos ao smartphone.
Protocolo Transporte Modelo Overhead Alcance Energia
──────────────────────────────────────────────────────────────────────
MQTT TCP Pub/Sub 2 bytes Wi-Fi Medio
CoAP UDP Request/Reply 4 bytes Wi-Fi Baixo
HTTP TCP Request/Reply ~100 bytes Wi-Fi Alto
LoRaWAN LoRa Pub/Sub 13 bytes 15 km Muito baixo
BLE BT 4.0+ GATT services ~20 bytes 30 m Muito baixo
// Publicar leitura de temperatura via MQTT (PubSubClient + ESP32)
#include <WiFi.h>
#include <PubSubClient.h>
WiFiClient espClient;
PubSubClient mqtt(espClient);
void publicar_temperatura() {
float temp = ler_sensor();
char payload[32];
snprintf(payload, sizeof(payload), "{\"temp\": %.1f}", temp);
mqtt.publish("casa/sala/temperatura", payload);
// Topico: casa/sala/temperatura
// Qualquer subscriber desse topico recebe a mensagem
}
Gerenciamento de Energia
Em dispositivos IoT alimentados por bateria, o consumo de energia e a restricao principal. Estrategias comuns:
- Sleep modes: microcontroladores oferecem modos de baixo consumo (sleep, deep sleep, standby). O ESP32, por exemplo, consome 150 mA em atividade mas apenas 10 uA em deep sleep.
- Duty cycling: o dispositivo acorda, coleta dados, transmite, e volta a dormir. Exemplo: acordar a cada 5 minutos, enviar leitura de temperatura, dormir.
- Clock gating: desligar o clock de perifericos nao utilizados para reduzir consumo dinamico.
- Voltage scaling: reduzir a tensao de operacao (e o clock) quando processamento pesado nao e necessario.
// ESP32: acordar a cada 5 minutos, ler sensor, publicar, dormir
#define SLEEP_US (5 * 60 * 1000000ULL) // 5 minutos em microsegundos
void setup() {
wifi_connect();
mqtt_connect();
publicar_temperatura();
mqtt_disconnect();
wifi_disconnect();
// Configurar deep sleep com timer
esp_sleep_enable_timer_wakeup(SLEEP_US);
esp_deep_sleep_start(); // CPU desliga, RTC mantem timer
// Ao acordar, executa setup() novamente desde o inicio
}
void loop() {
// Nunca chega aqui — deep sleep reinicia do setup()
}
Edge Computing
Edge computing e o processamento de dados no proprio dispositivo (ou proximo a ele), em vez de enviar tudo para a nuvem. Vantagens:
- Latência reduzida: decisoes criticas sao tomadas localmente (ex: deteccao de obstaculos em veiculos autônomos)
- Economia de banda: enviar apenas resultados processados (ex: "temperatura anômala detectada") em vez de dados brutos
- Privacidade: dados sensiveis nao saem do dispositivo
- Resiliência: funciona mesmo sem conexao com a internet
No harness.os
Sistemas embarcados e IoT oferecem analogias diretas para a arquitetura do harness.os:
- Edge computing = Inner harness: o inner harness (CLAUDE.md, arquivos locais) processa informacao na "borda" — sem precisar consultar o servidor. Assim como edge computing reduz latência e funciona offline, o inner harness permite que o agente opere com conhecimento local quando o MCP nao esta acessivel.
- MQTT pub/sub = Event mesh: o modelo pub/sub do MQTT — publicar em topicos e subscribers recebem — e o mesmo modelo conceitual do event mesh do harness.os. Sessoes publicam eventos; outras sessoes (ou o governance layer) fazem subscribe e reagem.
- Deep sleep + duty cycling = Sessoes intermitentes: um agente Claude nao esta sempre ativo — ele "acorda" quando chamado, executa, e "dorme" (sessao encerra). O handoff e o equivalente do "salvar estado no RTC" antes do deep sleep.
- Restricoes de energia = Restricoes de tokens: assim como IoT otimiza consumo de energia, o harness.os otimiza consumo de tokens. Carregar so o contexto necessario (nao tudo), processar localmente quando possivel, e transmitir apenas o essencial.
- Sensores + atuadores = Inputs + outputs do sistema: sensores captam dados do mundo fisico; o harness.os capta dados de repositorios, sessoes e bancos de dados. Atuadores agem no mundo fisico; o harness.os age via commits, deploys e mensagens.
Exercicios
- Projete a arquitetura de um sistema embarcado para monitoramento de temperatura e umidade de uma estufa. Liste os componentes (sensor, MCU, comunicacao) e justifique suas escolhas.
- Compare MQTT e CoAP para um sistema com 100 sensores de temperatura publicando dados a cada 10 segundos. Qual protocolo e mais adequado? Considere consumo de energia e escalabilidade.
- Um ESP32 consome 150 mA quando ativo e 10 uA em deep sleep. Se ele acorda por 2 segundos a cada 5 minutos, qual e o consumo medio? Quanto tempo duraria com uma bateria de 2000 mAh?
- Explique a diferenca entre hard e soft real-time. De dois exemplos de cada e justifique a classificacao.
- Projete o fluxo de dados de um sistema IoT para monitoramento de qualidade do ar: sensor → MCU → cloud → dashboard. Inclua protocolos de comunicacao em cada etapa.
Resumo
- Sistemas embarcados sao computadores dedicados a funcoes especificas com restricoes de custo, energia e tempo real
- Hard real-time exige deadlines rigorosos (falha catastrofica se violados); soft real-time tolera atrasos ocasionais
- Sensores convertem grandezas fisicas em sinais eletricos; interfaces comuns: analog (ADC), I2C, SPI, 1-Wire
- Protocolos IoT: MQTT (pub/sub leve), CoAP (HTTP sobre UDP), LoRaWAN (longo alcance), BLE (curto alcance)
- Gerenciamento de energia: sleep modes, duty cycling, clock gating, voltage scaling
- Edge computing processa dados localmente, reduzindo latência, banda e dependência da nuvem
Verifique seu entendimento
Qual protocolo IoT usa o modelo publish/subscribe sobre TCP e e o mais leve em termos de overhead?