Промты для отладки ESP32 и STM32: как LLM читает логи Serial и находит причину молчания платы

Вы уже второй час смотрите на макетную плату с ESP32, которая должна была отправить данные в MQTT-брокер, но в мониторе порта тишина. Или наоборот: проект только в голове, а вы не знаете, с чего начать скетч для опроса датчика по I2C. В обоих случаях LLM может сэкономить часы, если подойти к ней с правильной стороны.

За последние месяцы я собрал набор промтов, которые реально использую в работе с Arduino, ESP32 и периферией. Они делятся на две большие группы: генерация кода с нуля по описанию задачи и диагностика уже работающего (или почти работающего) устройства по логам, симптомам и схемам. Выбор зависит от того, есть ли у вас физическая плата и что именно сломано.

Ниже — проверенные формулировки с примерами. Каждый промт можно копировать и адаптировать под свой проект. Важно: LLM не заменяет осциллограф и чтение даташитов, но берёт на себя рутину и помогает не упустить очевидное.

Стратегия: от спецификации или от симптома?

Прежде чем переходить к промтам, определитесь с точкой входа. Если у вас нет готового кода и вы только проектируете устройство — идите от спецификации. Если плата уже мигает не тем светодиодом или молчит — идите от симптомов и логов.

В таблице ниже — сравнение двух подходов по трудозатратам и типичным ошибкам.

Промты для генерации скетчей с нуля

Эти промты хороши, когда проект ещё в голове. Они заставляют модель выдавать структурированный код, а не абстрактные советы.

1. Скелет скетча по спецификации

Зачем: получить рабочую заготовку с разделением на функции и без «магических» задержек.

Промт:

Ты — инженер-разработчик встраиваемых систем. Напиши скетч для ESP32 на Arduino framework.
Задача: раз в 10 секунд читать температуру и влажность с датчика DHT22 (пин GPIO4) и отправлять по MQTT в топик home/sensor1.
Требования:
- не использовать delay() в основном цикле;
- подключение к Wi-Fi и MQTT с переподключением;
- вынеси чтение датчика и публикацию в отдельные функции;
- добавь комментарии к неочевидным местам.
Верни полный код с пояснением, какие библиотеки подключить.

Что получите: структуру с millis(), функцию readSensor() и publishData(). Модель обычно предлагает библиотеки DHT sensor library и PubSubClient. Проверьте, что пины и название топика совпадают с вашим брокером.

2. Инициализация периферии с проверкой ошибок

Зачем: новички часто пишут Wire.begin() и не проверяют, подключено ли устройство. Промт заставляет модель добавить обработку ошибок.

Промт:

Напиши функцию initI2C() для Arduino Uno, которая:
- инициализирует шину I2C;
- сканирует адреса от 1 до 127 и выводит в Serial найденные устройства;
- если устройство не найдено, возвращает false и пишет в Serial код ошибки;
- если найдено, возвращает true.
Используй Wire.h. Покажи пример вызова в setup().

Пример вывода в Serial: I2C device found at 0x3C. Если адрес не совпадает с даташитом (например, у OLED-дисплея часто 0x3C или 0x3D), вы сразу это увидите.

3. Перевод логики на конечный автомат

Зачем: уйти от «лапши» из if и delay(). Конечный автомат (state machine) делает поведение предсказуемым.

Промт:

Преобразуй этот код в конечный автомат без блокирующих задержек. Состояния: IDLE, HEATING, COOLING, ERROR. Переходы: по температуре и по таймауту. Выведи диаграмму состояний текстом и полный код на C++ для Arduino.
[вставьте свой код]

Модель предложит enum State и switch-case. Проверьте, что таймауты не переполняются при millis() — используйте unsigned long.

Промты для диагностики: плата не отвечает

Теперь переходим к сценарию, когда устройство уже есть, но ведёт себя не так. Здесь промты строятся вокруг логов и конкретных симптомов.

4. Анализ лога I2C-сканера

Зачем: быстро понять, видит ли мастер-контроллер устройство на шине.

Промт:

Вот вывод I2C-сканера с Arduino Uno:

I2C scanner
Scanning...
No I2C devices found

Плата: Arduino Uno, дисплей SSD1306, питание 3.3 В, подтяжка SDA/SCL к 3.3 В через резисторы 4.7 кОм.
Что проверить в первую очередь? Дай пошаговый чек-лист из 5 пунктов, начиная с самого вероятного.

Ожидаемый ответ: проверить питание дисплея (не перепутаны ли 3.3 В и 5 В), целостность пайки, адрес (0x3C), линии SDA/SCL. Модель может предложить прозвонить мультиметром — это разумно.

5. Расшифровка «мусора» в Serial

Зачем: когда вместо читаемого текста сыплются кракозябры, причина часто в скорости порта.

Промт:

В мониторе порта Arduino IDE вместо текста выводятся символы вида `ÿÿÿÿ`. Скетч использует Serial.begin(115200). Монитор порта выставлен на 9600. Что происходит и как исправить? Объясни механизм.

Механизм: несовпадение скорости передачи и приёма. Модель объяснит, что при 115200 бод и 9600 бод биты сэмплируются неверно. Решение — выставить одинаковую скорость. Это базовый, но частый случай.

6. Диагностика SPI: устройство не инициализируется

Зачем: SPI сложнее I2C, и ошибки в CS или режиме часто неочевидны.

Промт:

У меня ESP32 и модуль SD-карты по SPI. Скетч не видит карту, функция SD.begin(5) возвращает false. Пины: SCK=18, MISO=19, MOSI=23, CS=5. Питание 3.3 В. Что проверить? Дай список причин и тестовый скетч для проверки целостности линии MISO.

Что получите: проверку CS, режима SPI (Mode 0), наличия карты, форматирования. Тестовый скетч может замкнуть MISO на землю и прочитать — так проверяют линию.

7. Плата не выходит на связь по Wi-Fi

Зачем: ESP32 часто не подключается к сети из-за несовместимости режимов или слабого сигнала.

Промт:

ESP32 не подключается к Wi-Fi. Serial выводит: `Connecting to WiFi...` и через 10 секунд перезагружается. Роутер работает на 2.4 ГГц, WPA2. Скетч использует WiFi.begin(ssid, password). Что может быть причиной? Предложи 3 сценария и способ проверки каждого.

Сценарии: неверный пароль, ESP32 в режиме AP вместо STA, недостаточное питание (просадка при передаче). Проверка — вывод кода ошибки WiFi.status().

8. Анализ зависания после нескольких циклов

Зачем: плата работает 5 минут, потом перезагружается. Причина может быть в переполнении памяти или watchdog.

Промт:

ESP32 перезагружается каждые 2–3 минуты. В Serial появляется `rst:0x8 (TG1WDT_SYS_RESET)`. Скетч использует MQTT и отправляет данные раз в секунду. Где искать причину? Объясни, что означает этот код сброса, и предложи шаги диагностики.

Что означает: срабатывание watchdog таймера. Модель предложит проверить блокирующие операции в цикле, утечки памяти, таймауты MQTT. Хороший ответ укажет на delay() внутри обработчика или долгий publish().

Промты для разбора протоколов и схем

Эти промты помогают понять, как работает периферия, и избежать ошибок в подключении.

9. Разбор даташита простыми словами

Зачем: даташиты на английском и с кучей регистров. LLM может перевести ключевые моменты.

Промт:

Объясни простыми словами, как настроить датчик BME280 по I2C для чтения температуры и давления. Какие регистры нужно прочитать и в каком порядке? Приведи пример кода на Arduino с использованием библиотеки Adafruit_BME280.

Осторожно: модель может перепутать регистры. Сверяйте с официальным даташитом. Но общая логика будет верной.

10. Схема подключения по текстовому описанию

Зачем: проверить, не перепутаны ли пины, до пайки.

Промт:

У меня Arduino Nano, модуль реле на 5 В и кнопка. Реле управляется пином D2, кнопка подключена к D3 с подтяжкой к земле. Нарисуй текстовую схему соединений и проверь, нет ли конфликта пинов. Если есть — предложи альтернативу.

Модель выдаст список соединений. Проверьте, что D2 и D3 не используются другими модулями (например, Serial).

11. UART: обмен данными между двумя платами

Зачем: когда нужно соединить ESP32 и Arduino по последовательному порту.

Промт:

Напиши скетч для обмена данными между ESP32 (Master) и Arduino Uno (Slave) по UART. ESP32 отправляет команду `LED_ON`, Arduino включает светодиод на пине 13 и отвечает `OK`. Скорость 9600. Учти, что у ESP32 три UART, используй UART2 (пины 16, 17).

Что получите: код с Serial2.begin(9600) на ESP32 и Serial.begin(9600) на Arduino. Проверьте, что линии TX/RX перекрещены.

Промты для отладки кода и рефакторинга

12. Поиск утечки памяти

Зачем: ESP32 имеет ограниченную память, и утечки приводят к сбросам.

Промт:

Проверь этот скетч на утечки памяти. Обрати внимание на динамическое выделение и работу со строками. Предложи, как переписать без String, если это возможно.
[вставьте код]

Модель укажет на String и new без delete. Замена на char[] часто решает проблему.

13. Оптимизация энергопотребления

Зачем: для батарейных устройств важно снизить потребление.

Промт:

Мой ESP32 работает от батареи 18650. Скетч опрашивает датчик каждые 5 секунд и отправляет данные по MQTT. Как снизить потребление? Предложи режимы сна и оцени, на сколько вырастет время работы. Учти, что Wi-Fi должен просыпаться для отправки.

Совет: модель предложит deep sleep с пробуждением по таймеру. Оцените сами: ток в активном режиме ~120 мА, в сне ~10 мкА. Время работы можно посчитать.

14. Чтение схемы по картинке (осторожно)

Зачем: если есть фото макетной платы, можно попросить модель проверить соединения. Но это ненадёжно.

Промт:

На фото макетная плата с ESP32 и датчиком. Опиши, какие пины задействованы и нет ли ошибок в подключении. Если не уверен — скажи, что нужно проверить вручную.

Предупреждение: LLM плохо распознаёт мелкие детали. Используйте только как подсказку.

Промты для документации и тестирования

15. Генерация тестового сценария

Зачем: проверить логику до прошивки.

Промт:

Напиши тестовые сценарии для функции управления насосом по датчику влажности. Функция должна включать насос при влажности ниже 30% и выключать при выше 60%. Учти гистерезис. Опиши шаги проверки без реального оборудования.

Модель предложит эмуляцию с подменой значений датчика.

16. Комментарии и README для проекта

Зачем: когда код готов, но нужно оформить.

Промт:

Сгенерируй README для этого скетча: опиши назначение, подключение, необходимые библиотеки и как проверить работу. Добавь комментарии в код, если их не хватает.
[вставьте код]

Экономит время на документацию.

Как не попасть в ловушку галлюцинаций

LLM может выдумать название библиотеки или метода. Всегда проверяйте скомпилированный код на реальной плате. Если модель предлагает «библиотеку XYZ», поищите её в менеджере библиотек Arduino.

Ещё один приём: просите модель давать ответ в формате «причина — проверка — ожидаемый результат». Так проще отсеять догадки.

Что в итоге

Промты для Arduino и IoT с LLM экономят время, но требуют дисциплины. Начинайте с чёткой спецификации или лога, указывайте модель платы, пины и напряжение. Проверяйте каждый сгенерированный фрагмент на компиляцию и реальной плате.

Если хотите углубиться в смежные темы — посмотрите промты для Docker и Kubernetes, они помогают с инфраструктурой вокруг IoT. А для тестирования кода пригодятся юнит-тесты на Python с LLM.

Главное — не слепо копировать ответ, а использовать модель как толкового напарника, который всегда под рукой.