pvvx
Активный участник сообщества
При тестах было замечено, что приложения на новом SDK-IDF запускаются от источника с более высоким сопротивлением, чем у ESP8266. Это свидетельствует о том, что обычного коднера в сотни мкФ в питании для гашения пиков достаточно. Итоговую цену это сильно не меняет.
Первые версии SDK для ESP-32 не запускались и от источника с ограничением пиков в 500 мА.
В новой версии SDK проц заглушили по частоте, включили троттлинг для понижения потребления (в idle RTOS) и сделали из него аналог ESP8266
Теперь с ним можно работать по методу Arduino - опрашивая всё "поллингом" - тупо греть внешнюю среду (т.е. в основе удовлетворить спрос на методы у телепузиков).Замер приема это и показывает - 700..800 килобайт, вместо 1.6 МБ/сек в TCP.
Если все while(условие) заменить на ожидание в sleep прерываний, но оставить 500 МГц общую для ядра, то потребление будет в разы меньше ESP8266 при одинаковой задаче. Т.е. беда в головах, а не чипе.
nikolz уже это продемил - включил таймер с прерыванием, заставив проц на 166 МГц исполнять while(1); в ожидании прерывания и измерив ток потребления такого чуда вывел, что чип жрет больше ESP8266 исполняющего команду wait i
Но жестокая реальность показала, что на тех-же чипах ESP8266 не справился с задачей подготовки и вывода в ШИМ MP3 на два канала и жрет при простой поддержке приема по WiFi те-же 60..70 мА как и полностью отрабатывающий прием и декодирование программно в ШИМ на 6МГц стерео поток МP3 другой чип.После пояснения этого nicolz-у, он вывел - использовать новые чипы сложно и вернулся к устаревшему ESP8266... И до сих пор сравнивает именно в таком контексте потребление чипов - сравнивает ESP8266 с неактивным CH_EN, с другим чипом, выполняющий команду while(1) на всей своей ГГцовой дури.
Последнее редактирование:
