ESP32C3 заглушка DeepSleep перестала исполняться

[pvvx]

Реальные задачи могут содержать множество вызовов отдельных процедур, которые будут кэшироваться по мере их вызова. И скорость выполнения может ещё больше просесть.
В принципе так оно пашет в любой задаче WiFi с MQTT - там кода более мегабайта и он в жизнь не влезает в кэш и ESP тупит по черному.

 

[pvvx]

Поглазел что пишут про deep-sleep в ESP Zigbee SDK...
И указывают тоже-самое - deep-sleep более затратный для ESP чем light-sleep:

• Глубокий сон не используется SDK. Разработчик должен управлять им в своих приложениях. Для получения дополнительных методов пробуждения вы можете обратиться к примеру глубокого сна ESP-IDF. Кроме того, Espressif предоставляет заглушку для обработки пробуждений, что позволяет проводить быструю проверку, и пользователь может решить, просыпаться или продолжать глубокий сон в этой заглушке, как объяснено в примере заглушки глубокого сна ESP-IDF.
• Рекомендуется реализовать стандартное устройство Zigbee Sleepy Device с использованием примера Light Sleep . Deep sleep запускает перезагрузку, и устройству необходимо пройти процесс повторного присоединения для повторного присоединения к сети. Это означает, что после каждого пробуждения из режима глубокого сна требуются дополнительные пакетные взаимодействия. Однако режим Deep sleep может быть выгоден для снижения энергопотребления, особенно когда устройство остается в состоянии сна в течение длительных периодов, например, более 30 минут.

Но опять не указывают время пробуждения SoC.
А картинки с замерами потребления показывают, что из ESP32 можно сделать вечный двигатель - они выдают обратный ток более 20 mA (Горе измерители на Power Profiler за $1000 )

 

[pvvx]

С кэшированием Flash у ESP можно извратиться по полной, написав код в шахматном порядке (команды jmp или вызовы call с ret в сторону уменьшения адресов расположенными с интервалами равными блоку считываемого из Flash контроллером XIP). Тогда на каждый ret или jmp будет читаться блок в кэш из Flash наверно более 8 байт и производительность станет гарантированно ниже 8 Мега-выборок байт в сек на команды.

А код именно так и пишут в СИ и C++, чтобы объявить подфункции до описания основной процедуры их вызова. Т.е. кэш будет дополнительно тормозить, если вы описываете код в классическом стиле, как учат ….
А надо все мелкие процедуры оформлять как inline

 

[pvvx]

Оптимизация компилятора по размеру кода с включением подфункций даст самый большой тормоз в ESP

 

[pvvx]

Проверить качество кода и производительность ESP можно очень просто.

Собираем какой пример с WiFi и RTOS. Для RTOS ставим частоту тиков в 1 мс. Частоту CPU в 16 MHz.
Должен успевать качать и всё делать по WiFi без доп. задержек – т.е. 800 килобайт в сек в TCP.

RTL87xx на Corteх M0 в 16 MHz всё это успевает и не тормозит (в тестах iperf). Порог до торможения где -то на уровне ниже 8..10 MHz CLK.

 

[pvvx]

Так-же смотрим в ассемблере, как располагаются константы и адреса вызовов и данных после сборки сишных исходников.

Константы и адреса располагаются в конце процедуры. Это значит, что кэш должна была выбрать блок по адресу старта процедуры и блок в конце процедуры, чтобы CPU смог исполнить данную часть кода. Это как минимум 2 обращения по SPI к Flash с передачей команды чтения, адреса в 3 байта, dummy байтов и далее чтения блока.
Тактирование SPI Flash у ESP всего 80 MHz и QIO.
Если модуль ESP используют соединение с Flash по DIO - это извращение вообще сразу в помойку.

В итоге и выходит, что ESP это чипы для бедных, не могущих позволить себе более качественные и менее жрущие чипы.

 

[pvvx]

Вот тот-же тест, но в Flash режиме DIO:

И вместо 11 us время исполнения уже 20 us.

 

[pvvx]

Сигнал с ноги /CS у Flash:

На выборку тестовой процедуры потребовалось считать 10 блоков из Flash.

Каждый блок по ~2 мкс с CLK 80 МГц -> 160 тактов DIO.

 

[pvvx]

@nikolz - Стоит ли из-за 2Мега операций с 32-х битными целочисленными значениями в секунду использовать чип с таким диким потреблением?
Это особенно касается всяких Sleep режимов и если идет soft обращение к Flash (любимый у народа диск во Flash), приводящее к сбросу всех кэшей у всех типов ESP….

 

[pvvx]

К переферии ESP8266 у меня нет претензий I2C у ESP8266 работает со скоростью 2 Mb/s

Безусловно , так как тактирование GPIO и шины у ESP8266 всего 26МГц, то ногодрыгом можно добиться в пределе 13 МГц - два такта - вывод "0" и "1". Но на изменение SDA надо ещё такт шины, и имея 3 такта с кривым SCL получим 8.7 MГц. Но надотъ уметь это писать на ASM с опциями компилятору не ставить "memw" или "extw" и не забывать о FIFO на этой шине...
Вот только во время этих действий CPU ESP8266 ничего не может, кроме увеличения тока по сигналу ожидания длящегося 6 тактов CPU (или 12 при CLK CPU x2) от шины. А должно быть уменьшение, т.к. CPU ждет...

 

[nikolz]

Кто-то там говорил о производительности ESP32-C3.
Попробуем посчитать реальную производительность ESP32-C3 для больших объемов кода или для задач, где фигурирует чтение-запись Flash (вызывающая полное опустошение кэша CPU).
Итог:
Среднее время выполнения одной операции целочисленной числодробилки на ESP32-C3 равно 260 нс.
= 3846154 операций в секунду.
Т.е. производительность ESP32-C3 на CLK в 160 MHz не более чем у CPU в 4..6 MHz типа Cortex M0.

Но Вы не доказали это, так как нет аналогичного теста на CPU в 4..6 MHz типа Cortex M0.

 

[nikolz]

@nikolz - Стоит ли из-за 2Мега операций с 32-х битными целочисленными значениями в секунду использовать чип с таким диким потреблением?
Это особенно касается всяких Sleep режимов и если идет soft обращение к Flash (любимый у народа диск во Flash), приводящее к сбросу всех кэшей у всех типов ESP….

Я с Вами согласен, поэтому пока и не определился что использовать.
----------------
получил TLSR8208 UART Хочу потестить их вместо встроенных Приемопередатчиков.
получил СH592F тоже хочу потестить.

 

[pvvx]

Но Вы не доказали это, так как нет аналогичного теста на CPU в 4..6 MHz типа Cortex M0.

https://developer.arm.com/documentation/ddi0432/c/programmers-model/instruction-set-summary

По 1 такту на использованные арифметические функции.
Flash имеет доп. такт ожидания на старых чипах при работе CLK CPU более 80 МГц. Там Flash не SPI.

 

[pvvx]

Если взять самые дешман MCU (от WCH, типа CH32V2xxx/3xxx), то даже подключаемая внешняя память там 16-ти битная. Все внутренние RAM/Flash на 144МГц дают макс 1 такт задержки на некоторые команды.
Или пусть RTL87xx со встроенным кристаллом DRAM на 2 МБайта и мы туда запихали исполняемые команды -> Типовой чип DRAM дает random поток выборки в 70 нс по 16 бит.

 

[pvvx]

Но Вы не доказали это, так как нет аналогичного теста на CPU в 4..6 MHz типа Cortex M0.

В ESP вам указано на осциллограмме, что для выборки тестовой процедуры ему потребовалось более 10 чтений блоков SPI Flash на DIO c до 160 тактов на 80 МГц. Более, т.к. для чтения Flash применяются промежуточные паузы для сигнала CS чипа между выборками.

Это поток не более 17 Мегабайт в сек. А у RISC-V Фиксированный размер командного слова — 32 бита (4 байта).

Итого выборка команд из Flash для CPU составила 17/4=4.25 Мега-команд в сек как максимум.

И выходит, что время на исполнение одной команды с такого потока для CPU составит около 0.235 мкс.

По замерам на осциллограмме для DIO получаем около 0.47 мкс на одну целочисленную арифметическую операцию в процедуре теста. (20 мкс / 42)
Т.е. примерно 2 команды CPU на одну целочисленную арифметическую операцию (+запись результата). Что четко сходится, с учетом не сверх точности измерений.

 

[pvvx]

В итоге производительность кода ESP из Flash при первом исполнении (кэш была пуста) при:

• DIO составляет 8.5МГц для RISC-V
• QIO составляет ~16МГц для RISC-V

И далее тащимся от ESP32 с двумя ядрами с тактированием на 480МГц... --- по 4 МГц на ядро