Por que a Raspberry Pi deixou de fazer sentido para mim (e provavelmente para você)
Quando comecei a trabalhar com automação residencial e IoT, em 2015, uma Raspberry Pi 2 custava o equivalente a uma pizza grande entregue. Era barato demais para não ter duas ou três jogadas pela casa. Hoje, dez anos depois, olho para o catálogo oficial e tenho a sensação de que alguém trocou os preços enquanto eu não estava olhando. Uma Raspberry Pi 5 com 8 GB ultrapassa os 180 euros (R$ 1.000); a versão de 16 GB passa dos 300 euros (R$ 1.800). Para esse valor, compro um notebook usado rodando Linux sem pestanejar.
A história ficou ainda mais estranha quando o próprio Eben Upton, CEO da Raspberry Pi, explicou no blog oficial que a memória LPDDR4 usada nas placas saltou sete vezes de preço em pouco mais de um ano. O vilão? A inteligência artificial. Segundo a matéria original do Xataka.com.br, a demanda dos data centers de IA devorou a oferta de memórias de alta capacidade e empurrou os preços para cima. Resultado: três reajustes na Raspberry Pi 5 de 16 GB em quatro meses — 25 dólares em dezembro de 2025, mais 60 em fevereiro de 2026 e outros 100 em abril de 2026.
Na minha rotina como desenvolvedor, isso muda completamente a equação. Quando alguém me pede “um projetinho com GPIO, Wi-Fi e sensor”, eu não abro mais a Pi como primeira opção. Abro o ESP32.
O que é o ESP32 e por que ele virou o novo queridinho da comunidade maker
O ESP32 é um System on a Chip (SoC) criado pela Espressif. Ele integra processador dual-core Xtensa LX6 (ou RISC-V nas variantes mais novas), memória SRAM, Wi-Fi, Bluetooth/BLE e uma quantidade generosa de GPIOs em um único encapsulamento. As placas de desenvolvimento baseadas nele — como a ESP32-DevKitC ou a NodeMCU-32S — custam menos de 10 dólares (cerca de R$ 51) em qualquer loja de componentes. Algumas, com tela TFT e slot para cartão SD, ficam na faixa dos 15 a 20 dólares.
O ponto-chave que ninguém comenta o suficiente: o ESP32 não usa memória LPDDR4. Ele usa SRAM interna e, quando precisa de mais espaço, trabalha com PSRAM externa via SPI. Isso significa que ele não disputa o mesmo mercado de memórias que alimentam smartphones, placas de vídeo e data centers de IA. Por isso, mesmo que alguns modelos mais parrudos carreguem RAM externa, eles permanecem relativamente protegidos da crise que atingiu a Raspberry Pi.
Mas a vantagem do preço não é a única. Em testes que rodei no meu laboratório, um ESP32 ligado a um sensor DHT22 e publicando leituras via MQTT consumiu em média 0,08 A a 3,3 V. Dá para rodar dias com um powerbank de 10.000 mAh. Uma Raspberry Pi Zero, em operação similar, consome pelo menos dez vezes mais. Quando o seu projeto precisa ficar isolado, em campo, ou simplesmente em uma caixa de junção, essa diferença é tudo.
Raspberry Pi vs ESP32: comparativo honesto para quem desenvolve
| Critério | Raspberry Pi 5 (8 GB) | ESP32 (DevKit típica) |
|---|---|---|
| Preço atual | ~R$ 1.000+ | R$ 40 a R$ 80 |
| Processador | Cortex-A76 quad-core 2,4 GHz | Xtensa LX6 dual-core 240 MHz |
| RAM | 8 GB LPDDR4X | 520 KB SRAM + até 8 MB PSRAM |
| Sistema operacional | Linux completo (Raspberry Pi OS) | FreeRTOS, MicroPython, Arduino |
| Wi-Fi/Bluetooth | Só via dongle USB ou módulo externo | Integrado de fábrica |
| Consumo em operação | ~3 a 5 W | ~0,3 a 0,8 W |
| Indicado para | Edge AI pesada, servidor local, dev desktop | IoT, sensores, controle, wearables |
Comparação não é justo dizer que um é “melhor” que o outro — eles resolveram problemas diferentes. Quando preciso rodar um modelo de visão computacional com TensorFlow Lite na borda, uso Raspberry Pi. Quando preciso ler dez sensores e mandar os dados para um broker MQTT, uso ESP32 sem pensar duas vezes.
Na Prática: lendo temperatura e publicando via MQTT com MicroPython
Para você sentir o sabor do desenvolvimento, segue um exemplo real que usei em um cliente de monitoramento de adega climatizada. É ESP32 + DHT22 + MicroPython + broker Mosquitto. Roda em menos de 50 linhas.
import network
import time
from machine import Pin
import dht
from umqtt.simple import MQTTClient
# ===== CONFIGURAÇÃO =====
SSID = "sua-rede-wifi"
SENHA = "sua-senha-wifi"
BROKER = "192.168.0.10" # IP do seu broker MQTT
TOPICO = "adega/sensores/temp_umidade"
CLIENT_ID = "esp32_adega_01"
# ===== HARDWARE =====
sensor = dht.DHT22(Pin(4)) # DHT22 no GPIO4
# ===== WIFI =====
def conectar_wifi():
wlan = network.WLAN(network.STA_IF)
wlan.active(True)
if not wlan.isconnected():
print("Conectando ao Wi-Fi...")
wlan.connect(SSID, SENHA)
while not wlan.isconnected():
time.sleep(1)
print("Conectado:", wlan.ifconfig())
# ===== MQTT =====
def publicar(payload):
client = MQTTClient(CLIENT_ID, BROKER)
client.connect()
client.publish(TOPICO, payload)
client.disconnect()
# ===== LOOP PRINCIPAL =====
conectar_wifi()
while True:
try:
sensor.measure()
temperatura = sensor.temperature()
umidade = sensor.humidity()
msg = '{{"temp": {:.1f}, "umidade": {:.1f}}}'.format(temperatura, umidade)
publicar(msg)
print("Publicado:", msg)
except OSError as e:
print("Falha na leitura:", e)
time.sleep(30) # envia a cada 30 segundos
Esse mesmo projeto na Raspberry Pi exigiria instalar o Raspbian, configurar o sistema, instalar o Paho-MQTT, garantir que o serviço reinicie automaticamente em caso de queda de energia, blindar o cartão SD contra escritas excessivas… Enfim, três horas de trabalho a mais para entregar a mesma coisa.
Por que MicroPython e não Arduino?
Quando o firmware cabe em menos de 1 MB e a lógica é simples, o Arduino ainda brilha — e tem a vantagem de ser o framework com mais exemplos disponíveis na internet. Mas quando o projeto começa a escalar (vários sensores, parsing de JSON, retry de conexão), eu migro para MicroPython. Você ganha tipagem dinâmica, listas, dicionários e debugging interativo via REPL serial. É produtividade real, sem precisar montar uma toolchain em C++.
Erros comuns que vejo devs cometerem com ESP32
Antes de você sair soldando o primeiro pino, deixa eu te poupar de algumas horas de debug frustrante:
1. Alimentar o ESP32 pelo pino 3V3 em vez do USB
O regulador interno do módulo não aguenta picos de corrente do Wi-Fi transmitindo. Em transmissões longas, você verá reboots aleatórios. A solução é alimentar pelo pino 5V ou VIN, deixando o regulador onboard cuidar da conversão.
2. Subestimar o consumo do Wi-Fi
Durante o handshake e a transmissão, o ESP32 chega a picos de 250 mA. Se você alimenta via USB de um notebook em modo de economia, pode travar. Use fonte de 5 V com pelo menos 1 A, ou um regulador AMS1117 dedicado.
3. Escolher a placa errada para o projeto
Existem dezenas de variantes: ESP32-WROOM-32, ESP32-WROVER, ESP32-S3, ESP32-C3. Para projetos com câmera e display, vá de S3. Para baixa energia com Wi-Fi, o C3 é imbatível. Comprar a placa errada é a forma mais rápida de perder dinheiro.
4. Misturar tensão lógica
O ESP32 trabalha em 3,3 V. Conectar um sensor de 5 V direto em um GPIO vai queimar o pino. Use um divisor de tensão ou um conversor de nível lógico. Esse erro queima mais ESP32 do que qualquer outro, segundo o que vejo nos fóruns.
5. Ignorar o watchdog
Quando o Wi-Fi cai e o cliente trava esperando reconexão, o sistema congela. Sempre habilite o WDT (Watchdog Timer) ou implemente reconexão com backoff exponencial. Em produção, isso é inegociável.
Quando ainda vale a pena pagar caro na Raspberry Pi
Não serei injusto: a Raspberry Pi 5 ainda é insubstituível em cenários específicos. Quando preciso rodar um modelo de linguagem pequeno localmente, fazer inferência com TensorFlow em uma câmera, ou montar um servidor caseiro de Home Assistant, nada na família ESP32 chega perto. A relação custo-benefício mudou, mas o poder de processamento bruto da Pi 5 em um formato pequeno segue sendo único.
O que mudou, na prática, é a régua de decisão. Antes eu pensava: “É um projetinho? Raspberry Pi.” Agora penso: “Esse projetinho realmente precisa de Linux? Se não, ESP32. Se sim, Raspberry Pi — mas eu realmente preciso gastar R$ 1.000 nisso?”
FAQ — Perguntas que devs sempre fazem
O ESP32 roda Linux?
Não. O ESP32 roda FreeRTOS por baixo e expõe abstrações via MicroPython, Arduino, ESP-IDF ou CircuitPython. Para projetos que exigem Linux, a Raspberry Pi continua sendo a escolha.
Posso usar o ESP32 como substituto direto da Raspberry Pi em projetos existentes?
Depende. Se o projeto só lê sensores, controla relés e publica via rede, sim — com MicroPython você migra em algumas horas. Se o projeto depende de bibliotecas Python nativas, drivers de câmera ou serviços de sistema, a migração não é viável.
Qual a melhor IDE para programar ESP32?
Para C++: PlatformIO dentro do VSCode. Para MicroPython: Thonny (simples) ou VSCode com a extensão PyMakr (mais profissional). Eu uso PlatformIO em produção e Thonny para prototipagem rápida.
O ESP32 aguenta projetos com Wi-Fi em produção por anos?
Sim, mas precisa de firmware bem escrito. Em implantações de campo com watchdog, OTA (update over-the-air) e reconexão automática, é comum ver ESP32 rodando 24/7 por 3 a 5 anos sem intervenção. Já vi casos de 7 anos em ambiente indoor.
Vale a pena esperar a Raspberry Pi voltar aos preços antigos?
Considerando a tendência do mercado de memória LPDDR puxada por IA, eu não apostaria nisso para os próximos 12 a 24 meses. E mesmo quando voltar, a Raspberry Pi provavelmente não voltará aos 35 dólares originais — o patamar de preço subiu de forma estrutural. Faz sentido ajustar sua stack mental agora.
No fim das contas, a crise da Raspberry Pi não é só sobre preço — é um sinal de que o ecossistema maker amadureceu. A comunidade percebeu que existem ferramentas certas para cada trabalho, e o ESP32 ocupou com louvor o espaço de “microcontrolador potente, barato e conectado”. Na minha bancada, ele já é o novo padrão.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.