Comments 55
Внутреннее устройство чипа и его периферии являются чёрным ящиком. Производитель не предоставляет документацию по низкому уровню, а для взаимодействия со всеми ресурсами, такими как ОЗУ, ПЗУ и периферийные устройства, предлагается использовать функции SDK.
Есть официальная документация на основную перифирию и возможность прямого обращения к ее регистрам. Чем люди успешно пользуются, когда реализованных возможностей функций SDK не достаточно.
S2 более дешёвой упрощённой одноядерной альтернативой
Зато больше всего доступных ног ввода-вывода и поддержка встроенного flash или psram.
таким образом его логические уровни считаются трёхвольтовыми, и он может работать с другими трёхвольтовыми устройствами напрямую.
Некоторые ноги можно перевести на 1.8В
Отдельным пунктом программы хочу рассказать про восходящую звезду в мире ESP — чип ESP32-C3, выпущенный Espressif в 2020 году в качестве современной, более сбалансированной по цене и возможностям альтернативы для ESP8266.
Как прямая альтернатива ESP8266 вроде идет ESP32-C2. Там даже модули такого-же формфактора есть. Хотя сраванивая ESP32-C2 с ESP32-C3 по возможностям в них трудно найти большие отличия.
нахождение портов GPIO на более медленной шине периферии, работающей на частоте 80 МГц независимо от тактовой частоты ядра, снижает способности контроллеров в области заморского bit-banging, или исконно русского «дрыгоножества»
В ESP32-S2 и ESP32-S3 (настчет простого ESP32 не знаю) - есть возможность прямого доступа ядра к портам GPIO через спец-команды на макисмальной частоте перифириии 80Мгц.Так что дрыгоножить там можно довольно быстро.
Всё перечисленное, а также нахождение портов GPIO на более медленной шине периферии, работающей на частоте 80 МГц независимо от тактовой частоты ядра
Не совсем независимо от частоты ядра, скорее равна 80Мгц, либо частоте ядра, если его частота ниже 80Мгц. Во всяком случае в S3, который сейчас использую этот так.
Самое главное и не сказали. В ESP32-C3, ESP32-C6, ESP32-H2 и ESP32-S3 есть встроенные USB-JTAG отладчики. Я других чипов с такой возможностью не видел. Чрезвычайно удобно вычитывать память, обмениваться данными по RTT, пошагово отлаживать код. Или ардуинщики не пользуются отладчиками?
Да, отладчик завезли только в IDE второй версии, которая не очень-то популярна. А в первой никакой отладки, только консоль и Serial.print.
А кто-нибудь пробовал собрать прошивку OpenOCD for ESP32-S3?
https://github.com/espressif/openocd-on-esp32
У меня лежит ESP32S3 mini и SuperMini nRF52840 Pro Micro с окирпиченным загрузчиком.
Покупать отдельный JTAG-адаптер для прошивки загрузчика жаба душит, а тут вроде можно воспользоваться ESP32S3 в качестве OpenOCD программатора по аналогии с JTAG.
Но как не пытался скомпилировать прошивку под ESP32S3, всё время натыкался на ошибки при сборке проекта.
У nRF52840 есть интерфейс SWD, достаточно копеечного st-link китайского или DAPLink (по 150 рублей на али продаются). Можно использовать такой проект: https://gitee.com/LI1669063251/ESP32-DAPLink
Изучу, спасибо за ссылку
это смотря как 52840 окирпичен, есть такой вариант когда у него vcc 1,8В а на res - близко к 0В. нужен swd/jtag который умеет 1,8В
Прошивка ESP USB Bridge для esp32s3 прекрасно собирается в родной Espressif-IDE, idf v.5.3.1, там и openocd-on-esp32 собранный и отконфигурированный
еще можно на usb UART FT232H сделать адаптер
в текущей версии ESP32-DAPLink немного попутано с версиями tinyusb н и ей по умолчании флешку надо на 16 мег. но я собрал это под esp32S3 с 4MB встроенными
мне не понравилось что ESP32-DAPLink при старте обязательно надо подключиться к точке доступа wifi. и, удивительно, но для нее подходит вот эта утилита https://github.com/wuxx/ESPLink/ которая работает через hid, в то время как в ESP USB Bridge это отломали.
В эмбеддед - как в квантовой физике: наблюдение воздействует на результат. Не то чтобы я был против отладчика - например, смотреть дампы в кольцевых буферах. Но в реальности - намного полезнее отладчика - иметь логический анализатор с расшифровкой протоколов. А останавливать прошивку и именно отлаживать ее - имеет смысл в очень редких случаях: прерывания пропускаются, ноги с нужной частотой не дрыгаются, а если к этому еще и силовые ключи подключены и dead-time задается программно - можно и "бдыщ" устроить...
Да и вообще прошивки под эмбеддед пишутся обычно так, что отладчиком там смотреть нечего: в не реал-тайм части прошивки ничего особо не происходит - даже динамического выделения памяти нет; а на реал-тайм часть смотреть нельзя, иначе оно под отладчиком будет работать, а без него - нет. :-)
Даже если не пользоваться отладкой, очень удобно логи забирать через RTT. Или и вовсе, двунаправленный обмен вести
А останавливать прошивку и именно отлаживать ее - имеет смысл в очень редких случаях
Когда код ведет себя неадекватно (на esp32 сталкивался) и printf в терминал не помогает - отладчик очень нужен.
Нет никакого RTT в ESP32, поскольку нет SWO.
JTAG по сравнению с SWO и по сравнению с настоящей трасировкой весьма неэффективный канал отладки.
Поэтому думаю разработчик на ESP будет процентов на 100% тратить больше времени на отладку, чем разработчик на любом ARM Cortex M
Как это нет RTT? Я сам им пользуюсь. RTT и SWO вообще разные вещи. Для RTT нужен отладчик (SWD или JTAG), способный читать область в памяти. Микроконтроллер пишет данные в кольцевой буфер, хост их читает отладчиком.
А вот и пруфы:
https://github.com/okhsunrog/esp_hal_snippets/blob/rtt_target/src/main.rs
Этот код выводит данные через RTT с ESP32-C3, через встроенный usb-jtag. Для отправки с esp32-c3 используется крейт rtt-target, для получения логов на хосте использую probe-rs. Вообще, RTT очень популярен в embedded rust экосистеме, именно из-за defmt, probe-rs, rtt-target. И на ARM чипах работает, и на RISC-V, и на Xtensa
Понимаю. Походу Segger сам дал этой технологии широкое толкование.
Но вот тут я описал какая связь между SWO и RTT.
А у вас через RTT через JTAG, по честном это и есть тот медленный semihosting.
JTAG - это медленно и неэфективно. Быстро - это когда в чипе есть ARM CoreSight DAP.
Насчёт неэффективного канала отладки:
Сравнение скорости RTT и SWO
И больше ссылок с информацией:
https://kb.segger.com/RTT
https://www.segger.com/products/debug-probes/j-link/technology/about-real-time-transfer/
Восходящей звездой я бы назвал всё же ESP32-P4, анонсированный ещё в прошлом году, но до сих пор недоступного для заказа. Полноценной поддержкой SIMD мало какие МК могут похвалиться. Но цена за это тоже значительна - отказ от радиомодуля (WiFi и BT).
Только что-то мне говорит, что цена на ESP32-P4 будет очень кусачая и неприятная. Тут уж лучше взять какой-нибудь Rockchip RV1103, будет сильно жирнее чип и дешевле. Их по 4 доллара на LCSC продают, а если брать оптом большую партию – то меньше 3 долларов за чип.
RV1103 для мобильных устройств или батарейного питания хуже пригоден, чем ESP32-P4, который специально оснащен третьим ядром с низким потреблением.
Ну и отдельный вопрос о потенциальном преимуществе RISC-V перед ARM при суперскалярности. Полный отказ от CNZV состояний (флагов) сильно снижает зависимость команд друг от друга. Кто знает, может Espressif сумел в новых ядрах это потенциальное преимущество сделать наконец то реальным?
А о ценах пока остается лишь гадать. До сих пор Espressif выводил на рынок SoC с явно более низкими ценниками, чем у конкурентов. Сохранится ли эта тенденция? Я думаю, скоро узнаем.
RV1103 ориентирован прежде всего на программирование под linux - немного другая весовая категория микроконтроллеров и специализация программистов.
Да, это очень интересный вариант, жду его. Но насчёт цены, конечно, большие опасения.
Отладочные платы за ~12к руб. уже есть на Ali. Но по описанию чипы там пока "сырые" и не все работет.
А если лепить самоделку, как это всё интегрируется в Home Assistant и подобное, через MQTT?
Напрямую, но через esphome
Можно и через MQTT или даже веб-хуки. Любой доступный способ ээээ связи.
Но зачем? Разве что если очень хочется кодировать, или принципиально не хочется, чтобы кастомный сенсор или еще какой-то компонент был доступен через yaml.
MQTT более универсален. Я пользуюсь Homeassistant только в качестве вебморды, а писать сценарии мне намного больше нравится на Nodered. MQTT это клей, что все это связывает.
MQTT более универсален
MQTT очень тяжело использовать в serverless конфигурации. Тем более в EPS32-Mesh-Lite. Некоторые костыли имеются, но устойчивость к расщеплению у MQTT очень низкая, причем в ущерб к соблюдению стандарта.
Я уже молчу о случаях, когда необходимо прямое управление устройством с любого ПК или смартфона. Тут альтернатив веб-серверу на ESP32 просто нет.
писать сценарии мне намного больше нравится на Nodered
На Node-red можно писать только очень примитивные сценарии для ESP32. Даже встроенный в ESP32 ADC на нем по DMA не прочитаете. А в случае PCF8591, легче сразу на C или Rust будет написать код, чем доставать левое ухо правой ногой при помощи Node-red через Arduino.
Mqtt для этого не предназначено, тут совсем другой уровень абстракции. MQTT это командный интерфейс, имплементация комманд, естественно, пишится на том же С в самих устройствах.
Тоже самое с Nodered - я не вижу никакого смысла читать здесь ADC. Тут должно передаваться конкретное значение, температура, давление, неважно что, а как это реализуется, находится на более низком уровне, в в устройстве. Это гарантирует взаимозаменяемость - я могу заменить тот же датчик температуры на совершенно другой без изменений на уровне mqtt и Nodered. Nodered задаёт логику умного дома и не заботится о low level реализации. В этом весь смысл.
Кстати, в чем проблема с управлением со смартфона? Вполне есть клиенты mqtt. А если уж поднимать на esp вебсервер, то это уже не серверлес. Проще поднять центральный сервер, который раздаёт команды на отдельные устройства через MQTT.
Разговаривать с каждым esp отдельно IMHO чаще всего плохая идея. А если вы через пару лет заменить захотите систему (поддержки больше нет, вышли из строя и замена недоступна, появились более лучшие варианты,..) ? Я пару лет назад выбросил все самоделки на основе MySensors и заменил их готовыми устройствами zeegbe и shelly и немного самодельный на esphome. В Nodered логике изменений не потребовалось вообще, только топики mqtt и формат (на json перешёл).
Mqtt для этого не предназначено
Именно это я и указал. MQTT - далеко не универсален, когда дело касается МК.
Тоже самое с Nodered - я не вижу никакого смысла читать здесь ADC.
Для Вас может смысла нет, а огромное количество задач без этого решить невозможно.
неважно что, а как это реализуется, находится на более низком уровне
Как раз важно. Не боги горшки обжигают. Даже в esp-idf-hal мне приходилось коммитить. А уж на уровне HAL часто приходится кодировать.
Это гарантирует взаимозаменяемость
HA тоже гарантирует взаимозаменяемость. Но не ограничивает возможность создания и модификации произвольных компонентов средствами esphome.
Кстати, в чем проблема с управлением со смартфона? Вполне есть клиенты mqtt.
Попробуйте объяснить гостю, как открыть шлагбаум с WiFi модулем на въезде в деревню, до которого от Вашего дома километр. Передать гостю пароль от точки доступа и ссылку на веб-морду я представляю как. А вот как это сделать в случае MQTT - хотелось бы услышать от Вас.
Проще поднять центральный сервер
Не проще, если связь с сервером надо пробрасывать даже всего лишь на километр, как в случае выше.
Речь шла не о отдельном мк, а о целой системе умного дома. Nodered совершенно не предназначено решать задачи в пределах одного устройства - это инструмент интеграции устройств в "умную" систему - и здесь mqtt и Nodered отлично справляются.
Ещё раз - низкоуровневые вещи естественно нужны, но не на уровне интеграции, а на уровне устройства - наружу должен быть виден сервис (открыть ворота, считать температуру), а не "считай пятый бит порта X".
HA очень неудобен при написании сценариев. Написанные сценарии очень не наглядны. А хорошо сделанные графики Nodered вполне можно (в общих чертах) объяснить даже ребёнку.
С помощью mqtt можно очень просто объединить несколько различных сервисов - у меня например есть инстанция fhem (где мне проще подключить некоторое оборудование), HA и Nodered - все прекрасно общается между собой одинаковым образом через mqtt. Это чрезвычайно удобно. И много проще заменяемо - не только в границах esphome.
Шлагбаум это не умный дом, это более менее одно изолированное устройство, тут вполне оправдано поднять сервер на esp. А если у вас система доступа с десятком-другим точек? На каждой независимый сервер поднимать? Или лучше сделать центральный сервис с проверкой прав доступа, логированием, контролем нештатных ситуаций?
Мы просто о разных вещах говорим.
Речь шла не о отдельном мк, а о целой системе умного дома.
Где? Еще раз перечитал обсуждаемую статью и такого утверждения не нашел.
С помощью mqtt можно очень просто объединить несколько различных сервисов
Покажите пример использования MQTT устойчивого к расщеплению в mesh сети и с соблюдением стандарта.
Шлагбаум это не умный дом, это более менее одно изолированное устройство, тут вполне оправдано поднять сервер на esp
Так про то и речь, что "умный дом" - это лишь малая часть применения МК, обзор которых был в статье.
А если у вас система доступа с десятком-другим точек?
Если это действительно система доступа, то недопустим выход её из строя при аварии на брокере MQTT или WiFi AP.
А если у меня система даже не из тысяч, а сотен точек, то до свидания MQTT и здравствуй LwM2M.
А если точки не стационарны, и это, для примера, рой дронов, то опять до свидания MQTT и здравствуй mesh.
MQTT - современный протокол с достаточно широкими возможностями. У него есть своя область применения. Но она сейчас сужается с развитием mesh-сетей, как существенно более надежного решения без единой точки отказа, да еще и более дешевого. Как минимум, со смартфона до ESP32-Mesh точно достучитесь, даже если WiFi роутера нет или он не работает.
Есть ещё готовые DIY платформы на базе ESP32 от LILYGO: с дисплеями, LoRa-чипами, в корпусах типа коммуникатора с qwerty-клавиатурой, в виде умных часов.
Расскажите, как у этих контроллеров дела с энергопотреблением ? Понятно, что Ардуино+энергопотребление это немного смешная тема - но те же голые AVR контроллеры - весьма энергоэффективны, и имеют много разных способов вывести глубоко спящий контроллер обратно в рабочее состояние. Экосистема ESP - это только питание по проводу от 5 вольт, или в батарейном питании оно тоже живет ?
Довольно неплохо. Я делал плеер с питанием от одного 18650 напрямую, без повышения до 5 вольт. Потребление на 160 МГц вместе с усилителем для наушников и OLED дисплеем было 85-100 мА (Wi-Fi неактивен). Для голого ESP-12 среднее потребление около 70 мА. ESP32 на 240 МГц с активными беспроводными интерфейсами берёт что-то около 250 мА. Спящие режимы есть, в глубоком спящем режиме у ESP8266 что-то около 10 мкА.
А как у него с методами просыпаться из глубокого сна ? Есть какой-то таймер типа watchdog который сам тикает (хотя и не очень точно) даже при снятии основных тактовых сигналов ? Аппаратные прерывания по изменению состояния ног - я думаю должны быть. Аппаратные счетчики которые продолжают считать входящие импульсы при отключенном тактировании ? Прерывание от компаратора ? Какие-нибудь особые фишки типа опознавания активности на i2c в режиме слейва когда адрес совпадает с заданным в регистре ?
Есть таймер RTC модуля (хотя настоящих часов RTC в ESP-ках нет - они там полукостыльные) работающий в режиме глубокого сна. Еще есть низкопотребляющее ядро в сериях ESP32, программируемое отдельно от основных ядер, ему доступна часть выводов и перефирии. В режимах сна также некоторые выводы доступны для просыпания по уровню сигнала. По счетчикам в спящем режиме - вроде нет, возможно можно как-то использовать малопотребляющее ядро. Прерывание от АЦП в основном режиме - есть, но возможно придется "вручную" настраивать регистры (готовые функции SDK позволяют не все).
Я бы наоборот сказал, что все довольно плохо. Если вы используете вайфай, то это в любом случае секунды на подключение, установление соединения, отправку данных, и все это время потребление за 200 мА. Если использовать блютус, то там тоже потребление на этом же уровне, и для этой цели есть гораздо более экономичные чипы, специально заточенные под BLE и низкое потребление. Если же не использовать беспроводную связь, то непонятно, зачем тогда ESP. К тому же, даже с выключенным радиомодулем ESP все равно потребляет десятки мА, тогда как другие МК будут потреблять единицы.
У Espressif в линейке только один МК, заточенный под малое потребление, ESP32-H2, но он как-то тоже не сильно впечатляет, да и он заметно дороже, чем ESP32-Cx, например..
Тем не менее, по части экосистемы, полно готовых плат с ESP32 и возможностью питания от литиевой батареи, выше про LILYGO писали, например.
Оно умеет в несколько разных режимов сна, а на платах обычно выведена не только ножка с +5, но ещё и +3.3, которая идёт прямо в чип.
Другое дело что с активной вафлей аппетиты у есп вроде как до 100мА (по другим данным- 300 и выше), так что кажется что батарейки может и не хватить. Ещё момент - при напряжении ниже какого-то порога запись во флеш может этот самый флеш убить
А никто не собирал на ESP32C6 (автор, упущение в ESP ))) что-то работающее с Zigbee?
А то все примеры, которые собираются, у меня вызывают ошибку при исполнении (((
А ещё у меня есть другие коробки, и в них тоже можно найти, о чём рассказать.
Интересно было бы посмотреть коробку с FPGA.
Важная особенность ESP8266 и ESP32, которой стоит уделить внимание — трёхвольтовость.
Для ESP8266 (и, в несколько меньшей мере для ESP32) на практике есть совместимость с пятивольтовой (TTL-уровни) логикой. Вот кусочек даташита из которого видно, что выходные уровни 0 - не более 0.1 напряжения питания и 1 - не менее 0.8 напряжения питания. То есть при питании от 3 до 3.6 вольт выходные напряжения совместимы с TTL-уровнями (0 - <= 0.4в, 1 - >= 2.4в).
Входной уровень нуля (<= 0.25 напряжения питания) совместим с TTL-уровнями при любом допустимом напряжении питания. Вопрос только во входном напряжении логической единицы. Согласно даташиту ESP8266EX не допускает напряжения на входах > 3.6 вольт. Однако CEO компании Espressif в свое время написал:
![я могу официально ответить тут, он [ESP8266 прим. мое] допускает 5V уровни ввода-вывода при напряжении питания 3.3 вольта](https://habrastorage.org/getpro/habr/upload_files/1f6/c72/d71/1f6c72d711c4950a4a039af7b2b3b076.png "я могу официально ответить тут, он [ESP8266 прим. мое] допускает 5V уровни ввода-вывода при напряжении питания 3.3 вольта")
По поводу ESP32 он писал похожее. А неленивый человек провел серию экспериментов и проверил совместимость. Пишут, что существовала даже версия даташита на ESP8266 в которой была явно указана совместимость с 5-вольтовой логикой, но в последующих версиях ее убрали. Наверное потому, что совместимость обеспечивается, но с оговорками. Не во всем допустимом диапазоне напряжений питания (даже для ESP8266, а для ESP32 который может питаться от 1.8 вольт, и подавно). И, кажется, не при любых состояниях входов. Я находил упоминания, что вход запрограммированный как аналоговый вход может быть не 5в-толерантным (домашнее задание: кому интересно, поищите сами). Возможно, они так же не хотели себя связывать обязательствами поддержания совместимости с 5в уровнями в будущих версиях этих чипов. Но для домашнего, не особо ответственного применения, можно принять это к сведению, забить на даташит и исключить лишнее муторное согласование уровней с пятивольтовой периферией. CEO разрешил.
Решение этой проблемы оказалось надёжно закопано в глубинах интернета, но оно есть. Потребовалась программа с подозрительным названием Zadig. С её помощью устанавливается драйвер USB Serial (CDC) для USB JTAG/serial debug unit (Interface 0) и WinUSB для USB JTAG/serial debug unit (Interface 2). После этого в системе появляется COM-порт и становится доступна загрузка через Arduino IDE.
Также есть отзывы, что даже при наличии видимого в системе COM-порта скетч не загружается по причине неизвестной ошибки в esptool.
Можно решить проблему без Zadig.
Надо лишь как и ESP12 подключить адаптер UART-USB к пинам UART. После этого программировать ESP32 любым загрузчиком также, как и ESP12(ESP8266)
По теме ничего умного написать не могу, но за название статей, спасибо. Улыбнуло =)
З.ы люблю футураму 8)
«остаётся около 45 килобайт ОЗУ, и ещё немного можно освободить, отключив Wi-Fi»
Это ещё сколько-то десятков миллиампер освобождает. Встречал проект люксметра или чего-то подобного с выводом на SSD1306, где рекомендовано это сделать. Всего одной строкой в коде.
Ооо, мои любимые платки для интеграции с Home Assistant!
Ни слова про onboard Debug.
Все мои Ардуинки: часть третья, ESP8266 и ESP32