No Bloco 7, enxergamos o sistema IoT como um conjunto. Agora ele cresceu: pode medir sensores, atender a rede, atualizar informações e acionar componentes. Duas perguntas aparecem naturalmente: como organizar tarefas que precisam acontecer no tempo certo e como fazer partes diferentes se comunicarem?
Nem todo protocolo precisa virar uma nova montagem. Vamos executar fisicamente e no Wokwi quando a prática acrescentar compreensão; nos demais casos, vamos reutilizar experiências já feitas e analisar a arquitetura correta.
| Tópico | ESP32 física | Wokwi |
|---|---|---|
| RTOS | ✓ Prática completa com o LED do GPIO 23 | ✓ Prática completa |
| I2C | ✓ Scanner + LCD, com níveis elétricos protegidos | ✓ Scanner + LCD 16x2 I2C |
| UART / RS-232 | Conceito e arquitetura; RS-232 real exige transceptor | Conceito; não vamos fingir que UART TTL é RS-232 |
| CAN | Conceito; uma rede real exige transceptor e outro nó | Conceito neste percurso |
| TCP/IP | Retoma a prática HTTP do módulo 6 para enxergar as camadas | |
| IEEE 802.11 | Diagnóstico de compatibilidade do Wi-Fi já utilizado | |
| Bluetooth | Retoma o Bluetooth Classic real do módulo 6 | Conceito; o rádio Bluetooth não é simulado no Wokwi |
Conectar componentes não é apenas colocar fios. As partes precisam compartilhar regras compatíveis.
Imagine um ESP32 ligado a um display, a outro controlador e a uma rede Wi-Fi. Todos trocam dados, mas não da mesma forma. O display pode usar dois fios e um endereço; outro equipamento pode usar comunicação serial; a rede usa uma pilha de protocolos.
É a forma pela qual partes do sistema se conectam e trocam sinais. Pode envolver pinos, níveis elétricos e funções específicas, como TX/RX ou SDA/SCL.
É um conjunto de regras para a comunicação. Ele define como os participantes organizam e interpretam a troca de informações.
I2C, CAN, RS-232, TCP/IP, IEEE 802.11 e Bluetooth descrevem aspectos diferentes da comunicação. Algumas tecnologias envolvem mais de uma camada. Por isso, neste bloco vamos perguntar sempre: que problema esta tecnologia resolve e em que parte do sistema ela atua?
Antes de comparar meios de comunicação, nosso sistema tem outro problema: várias tarefas precisam avançar sem transformar o programa em um único loop() enorme e bloqueante.
Tempo real não significa simplesmente “muito rápido”. Significa projetar o sistema para responder a requisitos de tempo de forma previsível.
loop() resolveu nossos projetos. Mas imagine ler sensores, atualizar um display e atender a rede ao mesmo tempo. Se uma parte ficar parada esperando, as outras também podem atrasar. O RTOS entra aqui para organizar trabalhos concorrentes sem transformar o programa em uma sequência de esperas bloqueantes.O Ambiente MbB precisa piscar um LED, acompanhar sensores e manter a comunicação funcionando. Se uma parte do programa ficar esperando por muito tempo, outra atividade pode atrasar. Conforme o sistema cresce, precisamos organizar o trabalho.
Um RTOS — sistema operacional de tempo real — oferece mecanismos para organizar tarefas e decidir quando elas recebem tempo de processamento. No ESP32, o ambiente de desenvolvimento da Espressif utiliza FreeRTOS.
Uma tarefa representa uma atividade do mesmo sistema. Várias tarefas podem avançar de forma concorrente, cada uma com sua função e seu ritmo.
Vamos manter o LED externo no GPIO 23, já usado anteriormente. Uma tarefa alterna o LED a cada 1 segundo. Outra escreve uma mensagem no Monitor Serial a cada 2 segundos. O objetivo é observar dois ritmos independentes dentro do mesmo programa.
ESP32 física: reutilize exatamente o circuito-base do módulo 6 e abra o Monitor Serial em 115200. Wokwi: use um projeto ESP32, monte o mesmo LED no GPIO 23 e execute o código; não é necessária biblioteca adicional para este exemplo.
const int LED = 23;
void tarefaLed(void *parametro) {
bool estado = false;
while (true) {
estado = !estado;
digitalWrite(LED, estado);
vTaskDelay(pdMS_TO_TICKS(1000));
}
}
void tarefaMonitor(void *parametro) {
while (true) {
Serial.println("Tarefa Monitor: sistema ativo");
vTaskDelay(pdMS_TO_TICKS(2000));
}
}
void setup() {
Serial.begin(115200);
pinMode(LED, OUTPUT);
xTaskCreate(
tarefaLed,
"LED",
2048,
NULL,
1,
NULL
);
xTaskCreate(
tarefaMonitor,
"Monitor",
2048,
NULL,
1,
NULL
);
}
void loop() {
vTaskDelay(pdMS_TO_TICKS(1000));
}O LED continua mudando de estado em seu ritmo, enquanto o Monitor Serial publica outra mensagem em intervalo diferente. O escalonador organiza quando cada tarefa executa.
xTaskCreate() cria uma tarefa. vTaskDelay() suspende a tarefa pelo período indicado e permite que outras avancem. pdMS_TO_TICKS() converte milissegundos para a unidade usada pelo RTOS.
Usar um RTOS não garante sozinho que qualquer prazo será cumprido. O projeto das tarefas, prioridades, tempos de execução e recursos compartilhados também importa. Aqui queremos apenas compreender tarefas e escalonamento; mutex, semáforos, filas e análise de deadlines ficam para estudos posteriores.
Organizamos o tempo. Agora surge uma questão de conexão: como conversar com um display sem gastar muitos GPIOs?
O LCD 16x2 tradicional usa várias conexões. Com um módulo I2C, o mesmo tipo de display pode ser controlado por um barramento de dois sinais.
Um LCD 16x2 paralelo possui vários pinos de controle e dados. Ao acrescentar uma pequena interface I2C ao display, a comunicação passa a usar principalmente SDA e SCL. Isso economiza GPIOs e permite que outros dispositivos I2C compartilhem o mesmo barramento.
SDA é a linha de dados. É por ela que os bits da comunicação são enviados e recebidos.
SCL é a linha de clock. No nosso uso, o ESP32 atua como controlador do barramento e gera o ritmo da comunicação.
Vários dispositivos podem compartilhar SDA e SCL porque cada participante responde a um endereço I2C. Os endereços mais vistos em módulos de LCD não devem ser adivinhados: primeiro vamos perguntar ao barramento quem está presente.
| Sinal do módulo | ESP32 | Função |
|---|---|---|
| SDA | GPIO 21 | Dados do barramento I2C. |
| SCL | GPIO 22 | Clock do barramento I2C. |
| GND | GND | Referência elétrica comum. |
| VCC | Depende do módulo | A alimentação do LCD e os níveis de SDA/SCL precisam ser compatíveis com o ESP32. |
No simulador, esta ligação é a referência prática. A limitação elétrica dos pull-ups de um backpack real precisa ser tratada separadamente na montagem física.
Para um LCD 16x2 I2C alimentado em 5 V cujo backpack puxa SDA/SCL para 5 V, use um conversor de nível lógico bidirecional compatível com I2C.
| Ligação | Destino |
|---|---|
| ESP32 3V3 | LV do conversor |
| ESP32 5V/VIN | HV do conversor e VCC do LCD |
| GND | GND do ESP32, conversor e LCD em comum |
| GPIO 21 / SDA | LV1 → HV1 → SDA do LCD |
| GPIO 22 / SCL | LV2 → HV2 → SCL do LCD |
Se a documentação do seu módulo confirmar explicitamente que a interface I2C é segura em 3,3 V, siga a especificação do fabricante. Se você não souber, não arrisque a ligação direta: faça esta prática no Wokwi ou use a adaptação de nível.
O scanner percorre os endereços possíveis e mostra quais responderam. Abra o Monitor Serial em 115200 e observe o endereço encontrado.
#include <Wire.h>
void setup() {
Serial.begin(115200);
Wire.begin(21, 22);
Serial.println("Procurando dispositivos I2C...");
int encontrados = 0;
for (byte endereco = 1; endereco < 127; endereco++) {
Wire.beginTransmission(endereco);
byte erro = Wire.endTransmission();
if (erro == 0) {
Serial.print("Dispositivo encontrado em 0x");
if (endereco < 16) Serial.print("0");
Serial.println(endereco, HEX);
encontrados++;
}
}
if (encontrados == 0) {
Serial.println("Nenhum dispositivo I2C encontrado.");
}
}
void loop() {
}Em vez de copiar um endereço de um tutorial, você obtém o endereço do seu módulo. No Wokwi, o LCD I2C padrão deve aparecer em 0x27. Na montagem física, use exatamente o endereço encontrado pelo scanner.
Confira alimentação, GND comum, SDA/SCL, tensão dos sinais e se o módulo realmente está energizado. Um display aceso, mas sem comunicação, também pode indicar ligação ou endereço incorretos.
Arduino IDE: no Gerenciador de Bibliotecas, instale uma biblioteca LiquidCrystal I2C compatível com o cabeçalho LiquidCrystal_I2C.h e com lcd.init(). Wokwi: abra o Library Manager do projeto e adicione LiquidCrystal I2C; o projeto passa a manter essa dependência em libraries.txt.
Depois use no código o endereço encontrado pelo scanner. No Wokwi padrão será 0x27.
#include <Wire.h>
#include <LiquidCrystal_I2C.h>
const byte ENDERECO_LCD = 0x27; // troque pelo endereço encontrado
LiquidCrystal_I2C lcd(ENDERECO_LCD, 16, 2);
void setup() {
Wire.begin(21, 22);
lcd.init();
lcd.backlight();
lcd.setCursor(0, 0);
lcd.print("Ambiente MbB");
lcd.setCursor(0, 1);
lcd.print("Sistema ativo");
}
void loop() {
}Você não apenas leu “I2C usa SDA e SCL”. Você compartilhou um barramento, descobriu um endereço e usou esse endereço para enviar informação a um display.
Ambiente MbB na primeira linha e Sistema ativo na segunda. Esse resultado deve ser reproduzível no Wokwi e, com a adaptação elétrica adequada, no hardware físico.I2C é uma comunicação serial, mas nós já usamos também o Monitor Serial. Isso quer dizer que UART, Serial e RS-232 são a mesma coisa?
O Monitor Serial é um ótimo ponto de partida, mas não deve ser confundido com a interface elétrica RS-232.
Serial.begin(). O cuidado agora é não concluir que toda comunicação serial é RS-232. Primeiro separe a forma de organizar os bits, feita pela UART, dos níveis elétricos exigidos por uma interface RS-232 real.Quando escrevemos Serial.begin(115200) e usamos TX/RX, trabalhamos com uma UART: uma interface de comunicação serial assíncrona. Ela organiza bits, velocidade, bits de dados, paridade e bits de parada.
RS-232 é um padrão de interface serial que define características próprias, inclusive níveis elétricos. Esses níveis não são os mesmos níveis lógicos de um GPIO do ESP32. Por isso, uma porta UART TTL de 3,3 V não deve ser chamada de RS-232.
| Elemento | UART do ESP32 | RS-232 |
|---|---|---|
| Função | Comunicação serial assíncrona. | Padrão de interface serial com características elétricas próprias. |
| Sinais usuais no exemplo básico | TX e RX em níveis lógicos do microcontrolador. | TX e RX em níveis próprios do padrão RS-232. |
| Ligação direta ao GPIO | Somente com outro dispositivo compatível em nível lógico. | Não. É necessário um transceptor apropriado. |
Um circuito transceptor, como o MAX3232, pode fazer a adaptação entre a UART em nível lógico e uma interface RS-232 verdadeira.
Esses módulos são normalmente usados como Bluetooth Classic com interface UART TTL. O fato de transmitirem dados serialmente não os transforma em RS-232.
A montagem física depende do transceptor e do equipamento utilizado. Por isso não vamos criar uma “prática RS-232” ligando TX/RX diretamente: isso ensinaria a interface errada. O resultado esperado aqui é saber explicar onde a UART termina e onde a adaptação elétrica começa.
UART costuma ligar participantes de forma direta. Mas e quando vários módulos de uma máquina ou veículo precisam compartilhar um barramento robusto? É aí que CAN ganha sentido.
Em veículos e ambientes industriais, vários controladores podem precisar compartilhar informações em um ambiente eletricamente exigente.
Imagine uma máquina com um módulo de sensores, outro de acionamento e outro de supervisão. Em vez de criar uma ligação exclusiva entre cada par, os nós podem compartilhar um barramento e trocar mensagens identificadas.
No CAN, os participantes observam o mesmo barramento. As mensagens possuem identificadores que ajudam a indicar conteúdo e prioridade; não é simplesmente “um fio para cada aparelho”.
Quando mais de um nó tenta transmitir, o protocolo possui mecanismo de arbitragem. Isso permite resolver a disputa sem tratar a rede como uma conversa desordenada.
O controlador compatível com CAN clássico do ESP32 é chamado pela Espressif de TWAI. O chip possui o controlador, mas não possui o transceptor físico do barramento integrado. Para uma rede CAN real, é necessário um transceptor externo compatível com a camada física escolhida.
CAN é adequado quando precisamos de comunicação robusta entre vários controladores, com mecanismos próprios para arbitragem e tratamento de falhas.
Neste momento basta compreender barramento, nós, identificadores, arbitragem e a necessidade do transceptor. Uma prática CAN real exigiria pelo menos uma interface física adequada e outro nó para trocar mensagens; não vamos fingir isso apenas com dois fios no simulador. Bit timing avançado, CAN FD e análise detalhada de quadros ficam fora do objetivo desta etapa.
I2C, UART/RS-232 e CAN tratam comunicações próximas ao equipamento. No Bloco 6, porém, o ESP32 já conversou pela rede. O que estava por baixo do HTTP?
Vamos voltar a uma experiência conhecida em vez de começar com uma pilha abstrata de rede.
Quando um navegador acessou a página do ESP32 por um endereço como http://192.168.1.37, vimos HTTP funcionando. Mas a requisição precisou ser transportada e endereçada até o dispositivo.
O nome TCP/IP é usado para uma família de protocolos de rede. TCP e IP cumprem funções diferentes e trabalham em conjunto em muitas aplicações.
Aqui voltamos ao HTTP que já conhecemos, por isso TCP aparece naturalmente. Outros sistemas podem usar protocolos de transporte diferentes. Não precisamos estudá-los agora para compreender o caminho do nosso projeto.
Se o ESP32 possui Wi-Fi, mas não recebeu endereço IP, o navegador não tem como alcançar o servidor usando aquele endereço. Se o IP funciona e a página responde, então várias camadas já estão trabalhando juntas, mesmo que você não as tivesse nomeado antes.
Já usamos Wi-Fi como caminho físico e de enlace. Mas todo Wi-Fi é igual? É hora de entender a família IEEE 802.11.
“Wi-Fi” reúne diferentes gerações e características. O objetivo não é decorar velocidades máximas, e sim compreender diferenças relevantes.
Um notebook moderno pode enxergar redes e frequências que o nosso ESP32 clássico não utiliza. Então a frase “tem Wi-Fi” não informa tudo sobre compatibilidade.
| Padrão | Faixa associada | Leitura prática |
|---|---|---|
| IEEE 802.11a | 5 GHz | Uma das primeiras famílias a operar em 5 GHz. |
| IEEE 802.11b | 2,4 GHz | Teve forte papel na popularização inicial das redes Wi-Fi. |
| IEEE 802.11g | 2,4 GHz | Evoluiu o desempenho mantendo operação na faixa de 2,4 GHz. |
| IEEE 802.11n | 2,4 e 5 GHz | Introduziu recursos para maior desempenho, incluindo MIMO. |
| IEEE 802.11ac | 5 GHz | Ampliou capacidade e desempenho principalmente na faixa de 5 GHz. |
O ESP32 clássico usado neste percurso trabalha com 802.11 b/g/n em 2,4 GHz. Por isso, uma rede disponível somente em 5 GHz não é uma rede compatível para essa placa.
Taxas máximas teóricas variam conforme padrão, largura de canal, número de fluxos e outras condições. Para este módulo, a informação útil é reconhecer família, faixa de frequência e compatibilidade.
Quando o ESP32 não encontra uma rede, não conclua imediatamente que “o Wi-Fi está quebrado”. Verifique se a rede possui 2,4 GHz habilitado, se o nome e a senha estão corretos e se o dispositivo está dentro da cobertura.
Wi-Fi atende bem uma rede local, mas no Bloco 6 também controlamos de perto usando Bluetooth. Agora vamos olhar para Bluetooth como tecnologia de comunicação, e não apenas como ferramenta pronta.
Bluetooth volta ao conteúdo com outro objetivo: antes nós o usamos; agora vamos entender melhor como essa família de tecnologias se organiza.
No Bloco 6, o ESP32 usou BluetoothSerial para receber comandos próximos. Aquela prática utilizou Bluetooth Classic com o perfil serial disponível no ESP32 clássico.
| Bluetooth Classic | Bluetooth Low Energy — BLE |
|---|---|
| É tradicionalmente usado em cenários com comunicação mais contínua, como áudio e perfis seriais. | Foi projetado com forte foco em baixo consumo e comunicação eficiente para muitos dispositivos alimentados por bateria. |
No nosso Bloco 6, usamos uma comunicação do tipo serial com BluetoothSerial. | Aplicações BLE são organizadas em serviços e características, em vez de simplesmente imitar uma porta serial. |
| Módulos como HC-05 e HC-06 são exemplos conhecidos de Bluetooth Classic com interface UART TTL. | Sensores e dispositivos de baixo consumo são usos comuns de BLE. |
O ESP32 clássico deste percurso possui suporte a Bluetooth Classic e BLE. Isso não significa que todo modelo da família ESP32 ofereça exatamente os mesmos recursos; sempre confira o chip usado no projeto.
Um HC-05 pode trocar bytes com o microcontrolador por UART e, ao mesmo tempo, usar Bluetooth pelo rádio. UART descreve a comunicação local entre módulo e placa; Bluetooth descreve a comunicação sem fio com o outro dispositivo.
Ligação com a prática: o módulo 6 já forneceu a evidência de Bluetooth Classic na ESP32 física. No Wokwi, o rádio Bluetooth não é simulado; portanto, aqui não criamos uma falsa prática de rádio para “completar” o tópico.
Nosso sistema agora possui tarefas, dispositivos, barramentos e redes. Quanto mais partes se comunicam, mais uma pergunta se torna inevitável: quem pode acessar, alterar ou usar esses dados e comandos? O próximo bloco entra em proteção de dados pessoais e segurança de sistemas e informações.