ESP32 и ESP8266: чем отличаются и что выбрать

Заказ из Китая приехал в пятницу: в одной посылке лежали NodeMCU на ESP8266 за 260 рублей и DevKit на ESP32 за 420, и я честно не помнил, зачем заказал обе. Ответ подсказала практика. Ночник с веб-страницей собрался на 8266 за вечер и с тех пор работал месяц без единого ребута. А вот метеостанция на той же плате захлебнулась на третьем экране: JSON-ответ погодного сервера в два килобайта не влезал в память рядом с библиотекой дисплея, и скетч падал в перезагрузку через час-другой. Я переписывал код трижды, прежде чем признал: дело не в коде, а в плате.

В этом уроке раскладываем по полочкам, чем ESP32 и ESP8266 отличаются на самом деле — не строчкой «быстрее», а числами, которые влияют на проект: ядра, память, радиомодули, аналоговые входы, ток и цена. И соберём правило выбора, которое я теперь держу на стикере над монитором: три вопроса про Bluetooth, объём данных и параллельные задачи — и на каждый ниже дан ответ с числами, а не с прилагательными. Формат простой: сначала таблица с числами, потом подводные камни, потом правило выбора.

Начнём с мозга. ESP8266 — один 32-битный процессор Tensilica L106, который в платах NodeMCU и Wemos D1 mini трудится на 80 МГц с возможностью разгона до 160. ESP32 несёт два ядра Xtensa LX6, каждое разгоняется до 240 МГц. Два ядра — не маркетинг: WiFi-стек живёт на ядре номер 0, а вашему скетчу достаётся ядро 1 целиком, поэтому даже во время передачи пакетов delay() и millis() не плывут и не врут. На 8266 единственное ядро делит такты между вашим кодом и сетью, из-за чего при активной передаче таймеры дают погрешность, а обработка пакетов подтормаживает длинными кусками кода.

Память — главный водораздел в реальных проектах. Под скетч на ESP8266 остаётся примерно 40–50 КБ оперативки: строка ответа на пару килобайт уже дышит на ладан, а String в цикле фрагментирует кучу за сутки непрерывной работы. У ESP32 — 520 КБ SRAM: тот же двухкилобайтный JSON для неё просто число, и ArduinoJson со вложенными структурами ставится без борьбы за байты. Flash тоже крупнее: 1–4 МБ у модулей 8266 против типовых 4 МБ у DevKit, куда помещается прошивка с запасом и файловая система под страницу веб-интерфейса.

Радиочасть: обе платы ходят в WiFi 2.4 ГГц (стандарты b/g/n), а у ESP32 в придачу Bluetooth — и классический, и BLE с низким энергопотреблением. Пульт с телефона, beacon-метки, связка с фитнес-браслетом — всё это на 8266 невозможно физически: в том чипе радиочасти BT просто нет.

Пара слов о ценах и версиях, чтобы вы не растерялись в каталоге. Базовый ESP32 в исполнении WROOM-32 — тот самый DevKit на 30 или 38 пинов за 350–450 рублей; для первых проектов берите 38 пинов, чтобы рука дотягивалась до безопасного набора без перекрёстных проводов. Дальше по линейке идут ESP32-S3 с расширенной памятью и USB OTG для камер и звука, ESP32-C3 — младший брат на одном RISC-V ядре для дешёвых датчиков, и ESP32-S2 без Bluetooth, зато с USB. Логика та же, что в сравнении с 8266: чем специфичнее задача, тем дальше от базовой модели.

После такой таблицы кажется, что 8266 пора выкинуть. Не спешите: у него осталась законная ниша, и она шире, чем видится. Если устройство раз в минуту читает датчик и шлёт три числа по HTTP или MQTT, памяти хватает с запасом: скетч с WiFi-клиентом и датчиком DHT22 укладывается в 30 КБ. Платит такой проект половину цены ESP32, а живёт годами — на моей NodeMCU четвёртый год без перезагрузки работает датчик температуры в гараже: один сенсор, один клиент, ничего лишнего, и предсказуема плата как табуретка. Тот же принцип, по которому мы выбирали между DHT11 и DHT22: не «кто лучше», а «для какой задачи» — сравнение собратьев разобрано в уроке про выбор датчика.

ESP32 обязателен, когда проекту нужно одновременно: BLE-пульт с телефона, разбор ответов по несколько килобайт, HTTPS с настоящим TLS, две независимые задачи или экран с графикой. Плюс целый слой периферии, которого у 8266 нет вовсе: два 8-битных ЦАП на пинах 25 и 26, десять ёмкостных сенсорных входов, ШИМ через LEDC почти на любом GPIO и сопроцессор ULP, который сам следит за датчиком, пока ядра спят в глубоком сне. Для батарейных метеостанций это решающий аргумент: плата, которая спит 99% времени и просыпается на минуту раз в час, живёт на трёх пальчиковых батарейках несколько месяцев.

Первый пункт — аналоговые входы. У ESP32 их громко называют восемнадцатью, но живут они на двух контроллерах: ADC1 — пины 32–39, ADC2 — пины 0, 2, 4, 12–15 и 25–27. Когда WiFi активен, ADC2 отключается целиком: analogRead на пине 14 при поданном 1.65 В вернёт не ожидаемую половину шкалы, а ноль. Правило простое: аналоговые датчики при активной сети вешаем только на 32–39. У 8266 такой ловушки нет — канал один, зато разрядность ниже: 1023 ступени против 4095, ESP32 различает напряжение вчетверо тоньше. Вход тот тоже ровно один — A0, и на NodeMCU перед ним стоит делитель: плата меряет до 3.2 В, хотя сам чип видит лишь 1 В.

Второй пункт — ток. При передаче по WiFi обе платы делают пики потребления: у ESP32 до 300–500 мА на десятки миллисекунд, у 8266 скромнее — до 170 мА, но тоже ощутимо. Питание от USB-порта старого ноутбука или зарядки на 500 мА с тонким кабелем даёт просадки, и плата падает в перезагрузку с сообщением Brownout detector was triggered. Лечится блоком на 1–2 А и кабелем потолще. И логика у обоих 3.3 В: подали 5 В на GPIO — попрощайтесь с пином. Для батарейных проектов есть и четвёртое различие: в глубоком сне ESP32 берёт около 10 мкА против 20 у 8266 — при аккумуляторе на 2000 мА·ч это месяцы разницы в сроке жизни устройства.

Такая самопроверка — мой ритуал после установки пакета плат: тридцать секунд, и ясно, что плата, кабель и порт живы, прежде чем начинать сетевые эксперименты, где причин для тишины в мониторе в десять раз больше: тихий Serial почти никогда не значит сломанную плату, почти всегда — логика, сеть или питание. Пришли с Uno — базовая механика та же, что в первой мигалке, поменялся только номер пина и скорость порта. Дальше двигаемся по разделу: подключаем плату к домашней WiFi-сети в уроке про первый запуск, после которого плату ждёт роль веб-сервера. А в следующем материале — карта выводов DevKit: оба тупика из моей практики случились из-за пинов, а не из-за кода. И это закономерно: код пишется один раз по документации, а пины выбираются руками — руки ошибаются чаще.