• Уважаемые посетители сайта esp8266.ru!
    Мы отказались от размещения рекламы на страницах форума для большего комфорта пользователей.
    Вы можете оказать посильную поддержку администрации форума. Данные средства пойдут на оплату услуг облачных провайдеров для сайта esp8266.ru
  • Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram

Замер потребления RTL00 V1.0

pvvx

Активный участник сообщества
С режимом ST+AP решено.
Пример приема с RTL00 включенного в режим ST+AP и запущенным Web-сервере в Google Chrome.

Прием с ST на роутер, канал WiFi делит и измеритель тока на ESP8266+INA219, по этому трансфер ограничен (для рооутера сказывается наличие устаревшего девайса в сети):
RTL00-ST-1MBS.gif
Прием с AP на USB-WiFi в компе, канал WiFi делит и измеритель тока на ESP8266+INA219, по этому трансфер ограничен (для AP RTL сказывается наличие устаревшего девайса в сети):
RTL00-AP-1MBS.gif
На многие другие устройства включение ESP8266 в зоне их работы WiFi дает падение трансфера до 400 КБ в сек. Иногда это проявляется и на мою связку RTL + роутер. Тут уж как роутер распределит арбитраж. Без ESP в сети - трансфер стремиться за 1.2 МБ в сек... Подробнее про такое есть тут.

В итоге потребление при одинаковом трансфере одинаково, что с AP, что c ST у модуля включенного в оба (ST+AP) режима.
Средний ток в данном режиме без активной передачи данных составляет порядка 60 мА:
RTL00-ST-AP.gif

PS: Для сравнения c ESP8266 есть "Потребление при передаче на скорости к 1 мегабайт в секунду ". Код web-сервера на 90% совпадает.
 
Последнее редактирование:

nikolz

Well-known member
Вот принес ложку ... в Вашу бочку...
---------------------
Значит делаем так.
1) Берем web-свалку от pvvx.
2) заменяем файл main.c
на такой вот примитивный.
--------------------------
#include "device.h"
VOID DeepSleep( IN u8 Option, IN u32 SDuration);
int main(void)
{
DeepSleep (1, 5000);
}
-------------------------------------
Получаем вот такую картинку:

upload_2018-6-24_12-48-42.png

сравним с ESP8266
upload_2018-6-24_12-56-42.png

ИТОГО:
RTL8710 205 мс ток 70 ма.
ESP8266 85 mc ток 50 ма.
----------------------------
Ну и что же лучше?
Что не так?
 

pvvx

Активный участник сообщества
Вот принес ложку ... в Вашу бочку...
ИТОГО:
RTL8710 205 мс ток 70 ма.
Классно!

В SDK ESP8266 при использовании кода из всего одной команды входа в deep-sleep выходит более 250 мс со всеми оптимизациями. Код и получившийся график потребления для такого теста указан тут:
https://esp8266.ru/forum/threads/esp8266-sverxmaloe-potreblenie.3299/#post-50317

В итого имеем: Созданная за пару вечеров сборка среды на RTL00 для Web-сервера с загрузчиком имеющим выбор разных прошивок и ОС (в виде RTOS) побеждает годами оптимизированное тысячами мух SDK ESP без OC и имеющее меньшие возможности.

Спасибо за тестирование.
 

pvvx

Активный участник сообщества
@nikolz :
OpenWRT, на устаревших чипах H2 и последовательной SPI Flash (Orange Pi Zero), путем минимальной оптимизации частот SPI в половину возможностей Flash, загружается и стартует за пару секунд: 3..5 сек, в зависимости от установленных пакетов, что уже перегоняет ESP8266 в Arduino. Более современные дешевые платки c H5 и eMCC от 8GB имеют в разы большую скорость обмена (быстрее SD) и при оптимизации потребление в диапазоне ESP8266…

Пример для проверки на старье: miZy - tiny fast embedded linux for sunxi Orange Pi devices
--------
Памятка для nikolz, в качестве “просветления” зашоренности на ESP8266:

Что влияет на время выполнения стартовой загрузки до исполнения пользовательского кода из глубоких режимов сна в малых WiFi-SoC?

1. Отключение вывода сообщений стартовой ROM в UART.

ESP8266 не имеет такой возможности, RTL – в битах eFuse.

2. Использовать QSPI для загрузки кода из Flash на номинальной рабочей частоте Flash (100MHz).

ESP8266 использует однобитную загрузку стартового кода из Flash на сильно заниженной частоте SPI, RTL – от 2-х битной и частотами к 100 MHz.

Для загрузки и исполнения, к примеру, кода переводящего чип в режим deep-sleep, требуется загрузка кода в RAM из SPI-Flash.

У ESP8266 процедура перевода чипа в deep-sleep c активным таймером после старта из ROM требует установки и переинициализации десятка регистров с ожиданиями (синхронизацией выполнения переключений тактируемых низкой частотой RTC таймера). У RTL00 – всего трех. В итоге код и время исполнения короче.

Для понижения потребления при переходе в deep-sleep требуется перевести Flash в режим sleep. Время исполнения и затраты энергии на это действие у чипов примерно одинаковы, но RTL имеет API в ROM, что выливается в более короткий код, требуемый для загрузки.

Для серии RTL чипов нет никакого смысла тестов времени исполнения старта с переключением в режим deep-sleep с алгоритмами от устаревшего ESP8266 (с одной единственной опцией – таймер пробуждения on/off). Это как сравнивать какой из чипов загрузит быстрее сотню байт... с безусловным выигрышем RTL00. :p
RTL имеет множество опций просыпания и вариаций в режимах sleep (за счет PMU) и это поддерживается на уровне стартового кода ROM, путем исполнения разной стартовой инициализации частей SoC, c ветвлением и запуском загрузчика с 5-ю точками входа-старта. Разная последовательность инициализации в ROM имеет разное время исполнения. Т.е. повторный старт чипа из sleep с разнообразными опциями дает разное время старта до исполнения пользовательского кода. Минимальная и оптимизированная ветвь повторного рестарта – пару мс. У ESP8266 – всегда не менее 60 мс.

PS: Для реализации энерго-эффективных устройств у RTL серии “B” значительно больше опций и он является более подходящим и заточенным под такие дела, чем RTL серии “A”... У них разные "прелести", но и они уже морально и технологически устарели...
Вам достаточно дубины в своей пещере? У других мир и технологии не стоят на месте...
 
Последнее редактирование:

nikolz

Well-known member
@nikolz :
OpenWRT, на устаревших чипах H2 и последовательной SPI Flash (Orange Pi Zero), путем минимальной оптимизации частот SPI в половину возможностей Flash, загружается и стартует за пару секунд: 3..5 сек, в зависимости от установленных пакетов, что уже перегоняет ESP8266 в Arduino. Более современные дешевые платки c H5 и eMCC от 8GB имеют в разы большую скорость обмена (быстрее SD) и при оптимизации потребление в диапазоне ESP8266…

Пример для проверки на старье: miZy - tiny fast embedded linux for sunxi Orange Pi devices
--------
Памятка для nikolz, в качестве “просветления” зашоренности на ESP8266:

Что влияет на время выполнения стартовой загрузки до исполнения пользовательского кода из глубоких режимов сна в малых WiFi-SoC?

1. Отключение вывода сообщений стартовой ROM в UART.

ESP8266 не имеет такой возможности, RTL – в битах eFuse.

2. Использовать QSPI для загрузки кода из Flash на номинальной рабочей частоте Flash (100MHz).

ESP8266 использует однобитную загрузку стартового кода из Flash на сильно заниженной частоте SPI, RTL – от 2-х битной и частотами к 100 MHz.

Для загрузки и исполнения, к примеру, кода переводящего чип в режим deep-sleep, требуется загрузка кода в RAM из SPI-Flash.

У ESP8266 процедура перевода чипа в deep-sleep c активным таймером после старта из ROM требует установки и переинициализации десятка регистров с ожиданиями (синхронизацией выполнения переключений тактируемых низкой частотой RTC таймера). У RTL00 – всего трех. В итоге код и время исполнения короче.

Для понижения потребления при переходе в deep-sleep требуется перевести Flash в режим sleep. Время исполнения и затраты энергии на это действие у чипов примерно одинаковы, но RTL имеет API в ROM, что выливается в более короткий код, требуемый для загрузки.

Для серии RTL чипов нет никакого смысла тестов времени исполнения старта с переключением в режим deep-sleep с алгоритмами от устаревшего ESP8266 (с одной единственной опцией – таймер пробуждения on/off). Это как сравнивать какой из чипов загрузит быстрее сотню байт... с безусловным выигрышем RTL00. :p
RTL имеет множество опций просыпания и вариаций в режимах sleep (за счет PMU) и это поддерживается на уровне стартового кода ROM, путем исполнения разной стартовой инициализации частей SoC, c ветвлением и запуском загрузчика с 5-ю точками входа-старта. Разная последовательность инициализации в ROM имеет разное время исполнения. Т.е. повторный старт чипа из sleep с разнообразными опциями дает разное время старта до исполнения пользовательского кода. Минимальная и оптимизированная ветвь повторного рестарта – пару мс. У ESP8266 – всегда не менее 60 мс.

PS: Для реализации энерго-эффективных устройств у RTL серии “B” значительно больше опций и он является более подходящим и заточенным под такие дела, чем RTL серии “A”... У них разные "прелести", но и они уже морально и технологически устарели...
Вам достаточно дубины в своей пещере? У других мир и технологии не стоят на месте...
Опять сплошная демагогия.
Я Взял Вашу сборку и поставил туда пример из SDK для RTL - пример написали разработчики ( ну да они же для вас телепузики)
Неужели нельзя было просто ответить - лучше нельзя на RTL00 которая в 2 раза дороже eSP8266 без АЦП.
Что надо взять следующий чип за 500 руб и там нет гарантии что будет лучше так как даже pvvx лишь показывает фокусы.
Вы два года трындели про RTL а в результате опять куча на свалке и чудеса от pvvx которые реально работают как монстры - много едят и много весят.
 

nikolz

Well-known member
вот так работает ESP8266 со стандартным SDK в mesh
upload_2018-6-25_9-38-32.png
т е за 125 мс обеспечивается передача данных.
А на RTL00 может кто-то без ля-ля показать подобное?
-------------------------------------------------------------------------------------------------
Хотелось бы услышать наконец-то конкретное от начальника транспортного цеха.
 

sharikov

Active member
Вот принес ложку ... в Вашу бочку...
---------------------
Значит делаем так.
1) Берем web-свалку от pvvx.
2) заменяем файл main.c
на такой вот примитивный.
...
Ну и что же лучше?
Что не так?
В амебе просто ничего не делается, только после упорного мудохания в недрах SDK.
При холодном старте вся прошивка копируется в озу и выполняется еще куча инициализаций, это занимает время. Выход из deep-sleep всегда как холодный старт потому что sram отключается. Чтобы сократить время старта нужно не выполнять эти не всегда нужные инициализации для чего предусмотрены возможности вызова разных ветвей старта.
Добавляйте в rtl_boot.c ваш код который будет опрашивать датчик и либо сразу уходить в deep-sleep либо запускать основную прошивку. Готового ничего нет, документации по pmu особо тоже нет да и ненужно это уже никому включая сам реалтек.
Кстати и модули на rtl8195 пропали из продажи совсем а сейчас интересны только они. 8710af тупиковый модуль потому что в нем мало озу.
 

nikolz

Well-known member
В амебе просто ничего не делается, только после упорного мудохания в недрах SDK.
При холодном старте вся прошивка копируется в озу и выполняется еще куча инициализаций, это занимает время. Выход из deep-sleep всегда как холодный старт потому что sram отключается. Чтобы сократить время старта нужно не выполнять эти не всегда нужные инициализации для чего предусмотрены возможности вызова разных ветвей старта.
Добавляйте в rtl_boot.c ваш код который будет опрашивать датчик и либо сразу уходить в deep-sleep либо запускать основную прошивку. Готового ничего нет, документации по pmu особо тоже нет да и ненужно это уже никому включая сам реалтек.
Кстати и модули на rtl8195 пропали из продажи совсем а сейчас интересны только они. 8710af тупиковый модуль потому что в нем мало озу.
Спасибо за конкретный ответ.
Про rtl_boot.c вчера разобрался.
Но максимально куда я смог поставить свой код с deep-sleep
позволило уменьшить время активности с 205 мс до 185 мс.
Дальнейшее приближение к началу старта приводит к краху.
Это очень хреново.
 

nikolz

Well-known member
Кстати и модули на rtl8195 пропали из продажи совсем а сейчас интересны только они. 8710af тупиковый модуль потому что в нем мало озу.
У меня к Вам вопрос.
Вот почему-то у меня RTL00 дает ток 60-70 ма при начальном пуске и работе на голом металле.
Выходит что изначально WIFI приемник включен или неисправен чип.
Как у Вас с током потребления при старте?
 

pvvx

Активный участник сообщества
У меня к Вам вопрос.
Вот почему-то у меня RTL00 дает ток 60-70 ма при начальном пуске и работе на голом металле.
50+ мА в RTL”A” потребляет CPU на 80+ МГц c включенными основными встроенными контролерами, без выполнения команд для понижения потребления.

20+ мА при 166MГц на CPU с исполнением команд понижения потребления на время ожидания событий RTOS и активными UART, контролером Flash, таймерами и т.д. Для проверки этого состояния запустите RTL в прошивке “AT”, без включения WiFi.

6+ мА при 166MГц на CPU с исполнением команд понижения потребления на время ожидания событий и активными UART, контролером Flash, таймерами, диспетчером RTOS,... Для проверки этого состояния запустите RTL в прошивке “AT” с включенным режимом энергосбережения.

60..70 мА потребляет ESP8266 при работе с включенным кэш Flash, без выполнения команд для понижения потребления.

20+ мА при 50MГц на CPU и непрерывном выполнении команды ожидания прерываний с активным UART, контролером Flash и таймером. Для проверки этого состояния запустите ESP8266 в режиме программирования.

6+ мА потребляет ESP8266 при отключенном всём кроме LDO и RTC таймера. Для проверки этого состояния запустите ESP8266 c активным RESET или в SDK в режиме sleep.


Суслик - asm volatile ("waiti 0;") в void ets_run(void) у ESP8266.
----
Посвящается великому гуру многопоточности nikolz:

Во время инициализации полнофункционального драйвера WiFi с системой управления от Linux с ioctl по standard wireless extensions, реализованной в RTL, производится включение аналоговой части чипа, что несет за собой паузы в ожидании нормализации напряжений и прочие ожидания исполнения команд настроек. Во время данной инициализации и других работ с WiFi, с учетом обработки RTOS, производительности CPU достаточно 10..12 МГц. Вам никто не мешает запустить второй и третий поток, работающий с вашими датчиками или ещё чем, а не ожидать исполнения общей задачи в линеечку, как это принято в Arduino и Lua. Это относится ко всем действиям по решению задачи. Этого нет в ESP8266.

Если у вас нет параллельной задачи, т.е. беда с головой, то укажите системе на время простоев исполнять поток IDLE с командой понижения потребления, а не ваш любимый while(1) {nop} или тупой поллинг процесс на верхнем уровне приоритетов. Создайте флаг готовности средствами RTOS и отдайте время другой задаче…

Если у вам не требуется работа какого-то контроллера на время работы другой задачи, то укажите системе отключать его до события внешней активности на нем или восстановления по требованию. Система сама разберется когда его и как надо восстановить и вызовет необходимый поток.

PS: Наймите учителя по основам программирования, а не показывайте свою полную безграмотность в сравнении того, что вам не понятно и вы в не состоянии освоить, списывая свою некомпетентность на обман вас кем-то другим.
 
Последнее редактирование:

nikolz

Well-known member
50+ мА в RTL”A” потребляет CPU на 80+ МГц c включенными основными встроенными контролерами, без выполнения команд для понижения потребления.

20+ мА при 166MГц на CPU с исполнением команд понижения потребления на время ожидания событий RTOS и активными UART, контролером Flash, таймерами и т.д. Для проверки этого состояния запустите RTL в прошивке “AT”, без включения WiFi.

6+ мА при 166MГц на CPU с исполнением команд понижения потребления на время ожидания событий и активными UART, контролером Flash, таймерами, диспетчером RTOS,... Для проверки этого состояния запустите RTL в прошивке “AT” с включенным режимом энергосбережения.

60..70 мА потребляет ESP8266 при работе с включенным кэш Flash, без выполнения команд для понижения потребления.

20+ мА при 50MГц на CPU и непрерывном выполнении команды ожидания прерываний с активным UART, контролером Flash и таймером. Для проверки этого состояния запустите ESP8266 в режиме программирования.

6+ мА потребляет ESP8266 при отключенном всём кроме LDO и RTC таймера. Для проверки этого состояния запустите ESP8266 c активным RESET или в SDK в режиме sleep.


Суслик - asm volatile ("waiti 0;") в void ets_run(void) у ESP8266.
----
Посвящается великому гуру многопоточности nikolz:

Во время инициализации полнофункционального драйвера WiFi с системой управления от Linux с ioctl по standard wireless extensions, реализованной в RTL, производится включение аналоговой части чипа, что несет за собой паузы в ожидании нормализации напряжений и прочие ожидания исполнения команд настроек. Во время данной инициализации и других работ с WiFi, с учетом обработки RTOS, производительности CPU достаточно 10..12 МГц. Вам никто не мешает запустить второй и третий поток, работающий с вашими датчиками или ещё чем, а не ожидать исполнения общей задачи в линеечку, как это принято в Arduino и Lua. Это относится ко всем действиям по решению задачи. Этого нет в ESP8266.

Если у вас нет параллельной задачи, т.е. беда с головой, то укажите системе на время простоев исполнять поток IDLE с командой понижения потребления, а не ваш любимый while(1) {nop} или тупой поллинг процесс на верхнем уровне приоритетов. Создайте флаг готовности средствами RTOS и отдайте время другой задаче…

Если у вам не требуется работа какого-то контроллера на время работы другой задачи, то укажите системе отключать его до события внешней активности на нем или восстановления по требованию. Система сама разберется когда его и как надо восстановить и вызовет необходимый поток.

PS: Наймите учителя по основам программирования, а не показывайте свою полную безграмотность в сравнении того, что вам не понятно и вы в не состоянии освоить, списывая свою некомпетентность на обман вас кем-то другим.
Понятно, что Вы были бы не Вы, если бы в ответе не было бы дерьма.
Но все равно, спасибо за кое-какую информацию.
----------------------------------------
Про ESP8266 у вас что-то не все либо что-то не так.
при 80 мГц и без WiFi ток 15 ма, а не 20.
Есть еще четыре режима, которые Вы не указали.
1) это deep-sleep ток 20 мка.
2) EN=0 , ток 3-7 мка (точнее замерь не могу)
3) легкий сон при управлении питанием и ожиданием прерывания от пина (мой) 2 ма
4) легкий сон при управлении питанием и ожиданием прерывания от пина( SDK ) 0.5 ма.
---------------------------------
Ну и что же лучше: "50+ мА в RTL”A” потребляет CPU на 80+ МГц " и 15-20 ма ESP8266 при 160 мГц !!!
----------------------------------
А кто-то в захлеб трындел два года назад о скорой смерти ESP, а оказалось что смерть постигла RTL00.
------------------------------
Ну признайтесь же, что сели в лужу со своим пиаром RTL00, или слабо?
 
Последнее редактирование:

nikolz

Well-known member
50+ мА в RTL”A” потребляет CPU на 80+ МГц c включенными основными встроенными контролерами, без выполнения команд для понижения потребления.

20+ мА при 166MГц на CPU с исполнением команд понижения потребления на время ожидания событий RTOS и активными UART, контролером Flash, таймерами и т.д. Для проверки этого состояния запустите RTL в прошивке “AT”, без включения WiFi.

6+ мА при 166MГц на CPU с исполнением команд понижения потребления на время ожидания событий и активными UART, контролером Flash, таймерами, диспетчером RTOS,... Для проверки этого состояния запустите RTL в прошивке “AT” с включенным режимом энергосбережения.

60..70 мА потребляет ESP8266 при работе с включенным кэш Flash, без выполнения команд для понижения потребления.
Т е Вы сами себе противоречите.
Раньше Вы писали, что WiFi приемник изначально выключен (мол если драйвер WIFi не загружен, то он выключен)
а теперь утверждаете что изначально 50 ма(у меня получается 67 ма) при 80 мгц - это без wifi? а сколько тогда с wifi? столько же?
прикольно.
 

pvvx

Активный участник сообщества
Т е Вы сами себе противоречите.
Неа. Всё измерено и выложено, в отличии от ваших бредний.
Есть еще четыре режима, которые Вы не указали.
Их больше. А писал об основных.
До этого тему посмотрите, пока она короткая и не распухла от вашего спаму, в сообщении, где написано RUN/IDLE/SLP.
Ну и что же лучше: "50+ мА в RTL”A” потребляет CPU на 80+ МГц " и 15-20 ма ESP8266 при 160 мГц !!!
В данном сравнении - RTL"А" с 5..6мА при 166МГц и ESP c минимумом 21 мА на 50МГц.
Как измерять указано, в режиме ожидания приема символа по UART. Это ESP в режиме "программирования" и RTL в прошивке "AT".
А кто-то в захлеб трындел два года назад о скорой смерти ESP, а оказалось что смерть постигла RTL00.
------------------------------
Ну признайтесь же, что сели в лужу со своим пиаром RTL00, или слабо?
ESP8266 так и не родившись для эмбеддеров окончательно скончалась более 3-х лет назад. Не вижу решений ни одного решения на ESP8266 в продаже, кроме как на али для игры в Arduino.
А RTL ещё жив. У RTL всего два типа - RTL8195AM и RTL871xBN. Остальные - изначальная печалька непонятно для кого :)
RTL8195AM так и не догнали даже с ESP-32...
У китайцев всю эту мелочь сменила серия RDA, на что вам указывалось. :p
Не все такие бездарные как вы и им не нужна эмуляция бескорпусного чипа типа wireless клавиатуры с передачей 1000 символов в сек на USB приемник 2.4 ГГц. Представляете - оно кушает во много раз меньше, чем ваше решение и питается от одной AAA годами. :p Ну и реакция у неё получше...

У меня есть и серия 580 советских чипов. Они до-сих пор пользуются спросом и можно купить в магазине. :p :) :)
----
Какие у вас там ещё непонятки?

Время исполнения старта пользовательского кода для моего решения с Rapid-Loader? Ну не писал я аналога на RTL”A” – нужды не было и не будет. Для понижения потребления у RTL не требуется применение исключительно единственного решения через deep-sleep возможного у ESP8266. Там есть масса других вариантов sleep, дающих лучшие итого для решения реальных задач.

И как-то неохота сравнивать своё древнее решение на ESP8266 с множеством возможных, своих-же и новых. Основа там одна – время старта до исполнения любого пользовательского кода у ESP8266 от 65 мс, а у RTL – до пары мс. :p
Вы уже освоили мои решения из Rapid-Loader в "своем" лоадере? По картинке видно что не окончательно. Подождать ещё пару лет? :)
 
Последнее редактирование:

nikolz

Well-known member
Неа. Всё измерено и выложено, в отличии от ваших бредний.
Их больше. А писал об основных.
До этого тему посмотрите, пока она короткая и не распухла от вашего спаму, в сообщении, где написано RUN/IDLE/SLP.

В данном сравнении - RTL"А" с 5..6мА при 166МГц и ESP c минимумом 21 мА на 50МГц.
Как измерять указано, в режиме ожидания приема символа по UART. Это ESP в режиме "программирования" и RTL в прошивке "AT".
ESP8266 так и не родившись для эмбеддеров окончательно скончалась более 3-х лет назад. Не вижу решений ни одного решения на ESP8266 в продаже, кроме как на али для игры в Arduino.
А RTL ещё жив. У RTL всего два типа - RTL8195AM и RTL871xBN. Остальные - изначальная печалька непонятно для кого :)
RTL8195AM так и не догнали даже с ESP-32...
У китайцев всю эту мелочь сменила серия RDA, на что вам указывалось. :p
Не все такие бездарные как вы и им не нужна эмуляция бескорпусного чипа типа wireless клавиатуры с передачей 1000 символов в сек на USB приемник 2.4 ГГц. Представляете - оно кушает во много раз меньше, чем ваше решение и питается от одной AAA годами. :p Ну и реакция у неё получше...

У меня есть и серия 580 советских чипов. Они до-сих пор пользуются спросом и можно купить в магазине. :p :) :)
опять словесный понос.
Что молчите про
1) 50+ мА в RTL”A” потребляет CPU на 80+ МГц c включенными основными встроенными контролерами, без выполнения команд для понижения потребления.
и про 60 ма при старте и как вы говорите это без WIFI
а с WIFI тогда сколько?
-----------------
2) Я вам в доказательство выложил, как Вы и трындели, код на голом металле без wifi. RTL жрет 60-70 ма при его исполнении. Докажите что это не так. Опять заткнулись.
вот Вы в это весь и есть. нагадите и в кусты трындеть про свои заслуги.
Вы же RTL00 хвалили во весь форум. Теперь слились. Признали что зря трындели.
Теперь славите решение которое в 10 раз дороже ESP, соединяется с роутером от 3 до 8 секунд , не имеет нормальной документации и реальных решений IOT, кроме вашей свалки и ваших фокусов с измерениями в надуманных режимах, которые реально никто не реализовал.
Так держать вездессущий Вы наш .
 

pvvx

Активный участник сообщества
опять словесный понос.
Что молчите про
1) 50+ мА в RTL”A” потребляет CPU на 80+ МГц c включенными основными встроенными контролерами, без выполнения команд для понижения потребления.
и про 60 ма при старте и как вы говорите это без WIFI
а с WIFI тогда сколько?
При старте, судя по вашему графику у RTL - 10..20 мА. Или опять что-то не так вы нарисовали в фотошопе?
С WiFi вроде у RTL"A" было в DTIM(n) - до 6 мА и в среднем 15 мА. Тесты выложены.
2) Я вам в доказательство выложил, как Вы и трындели, код на голом металле без wifi. RTL жрет 60-70 ма при его исполнении. Докажите что это не так. Опять заткнулись.
Не - я ушел из данной темы. А сча смотрю, чего вы там достигли... Проверка типа.
Так держать вездессущий Вы наш .
Espressif спустя 3 года после указания исправило функцию входа в deep-sleep для автономных устройств в новых версиях SDK? Или ещё нет? Вы так и пользутесь моем вариантом? :)
Всё вам расскажи и покажи как надо делать. Сами то что хоть раз предложите?

PS: Без меня не можете накалякать тест, в разы с меньшим потреблением и временем исполнения в сравнении ESP к RTL? Говорите не знаете как и всё умирает? :) Вот оно и доказательство.
 
Последнее редактирование:

nikolz

Well-known member
При старте, судя по вашему графику у RTL - 10..20 мА. Или опять что-то не так вы нарисовали в фотошопе?
С WiFi вроде у RTL"A" было в DTIM(n) - до 6 мА и в среднем 15 мА. Тесты выложены.
Не - я ушел из данной темы. А сча смотрю, чего вы там достигли... Проверка типа.

Espressif спустя 3 года после указания исправило функцию входа в deep-sleep для автономных устройств в новых версиях SDK? Или ещё нет? Вы так и пользутесь моем вариантом? :)
Всё вам расскажи и покажи как надо делать. Сами то что хоть раз предложите?
Вы все перепутали.
Я выложил два примера и по каждому свои вопросы.
-------------------
Первый пример - это сон без перезапуска. Там то сначала 10 ма а потом становится 70 ма. И принудительное выключение wifi (функция wifi_off())
ничего не меняет. Вопрос был про эти 70 ма и почему они и как их убрать.
------------------
Второй пример - это deep-sleep. там ток 70 ма и выключение wifi тоже ничего не дает.
вопрос был как уменьшить этот ток и как уменьшить время активности (у меня меньше 180 мs не получается)
-------------------
оба примера я сделал на вашей свалке. Т е просто поставил в майн три оператора.
-------------------------
В своих сообщениях я просил не заниматься ля-ля, а показать хотя бы картинки с лучшими результатами именно в такой постановке задачи. Либо показать что у меня не так в коде. Демагогии не надо.
----------------------------------
вы на прошлой недели в переписки просили код
я его выложил Вы развели демагогию про своего друга который что-то впарить хочет кому-то. и Все
 

pvvx

Активный участник сообщества
Вы все перепутали.
Неа. Ничего не перепутано. Вы сами об этом пишите:
Я выложил два примера и по каждому свои вопросы.
-------------------
Первый пример - это сон без перезапуска. Там то сначала 10 ма а потом становится 70 ма. И принудительное выключение wifi (функция wifi_off())
Дык "в начале" 10 мА? А пишите что 70, когда включаете WiFi. :)
Исходников то нема.
я его выложил Вы развели демагогию про своего друга который что-то впарить хочет кому-то. и Все
Ныне я могу рассказать про более новый хлам, например по 2D GSM модемы, валом наполнившие рынок али и прочие свалки, в связи с закрытием старых типов сетей в США и Eвропе. В модулях этих модемах мозгов больше чем у максимальной dev-board с ESP-32 со всеми прибамбасами, а цена этого хламу ниже чипа ESP8266. :)

Или о модулях на AMR c минимум 4-х ядрами на ГГц-ы, с еММС и DRAM на GB? Ну жрут они как ESP-32. Можно и меньше, т.к. ARM врожденная заточка под энерго-эффективность, в отличии от 386 и ESP…

Ну и т.д. А тараканы типа ESP8266 давно закончили свой жизненный цикл в любой сфере применения…
Так-что сами барахтайтесь в мертворожденных ESP, если вам не освоить уже устаревшие и RTL.
Вечной нянькой по малым WiFi-SoC я не нанимался.
 

nikolz

Well-known member
Неа. Ничего не перепутано. Вы сами об этом пишите:

Дык "в начале" 10 мА? А пишите что 70, когда включаете WiFi. :)
Исходников то нема.
Так фокус-то в том что я не включаю wifi вообще а наоборот пытаюсь его еще и выключить.
как это нема исходников?
Я написал код в блоге.
Там правда всего три оператора в первом и 2 во втором примере.
Понимаю, что код сложный, если надо, то выложу снова.
 

nikolz

Well-known member
Н
Вечной нянькой по малым WiFi-SoC я не нанимался.
Вы очевидно забыли, как трахались с кодом ацп ESP пока я не выложил код от китайцев.
Вы его конечно обгадили, но исправно себе переписали в свалку.
---------------------------
Вы сами себя вечно записываете, то в няньки, то в всезнающего и всевидящего, то в единственно знающего.
---------------------
что же касается вашего бахвальства про вашу свалку чипов с которыми вы испражняетесь, то это Ваша фобия.
--------------
Я вам уже пытался объяснить в переписке , что мир IOT много сложнее чем вы его пытаетесь изображать.
меня не интересуют монстры с WIFI, потому что я делаю не устройства с картинками на сайте а носимые приборы
которые кроме низкого потребления должны иметь и малую стоимость так как предназначены для людей с ограниченными возможностями либо с тяжелыми хроническими заболеваниями.
А такие люди как правило не могут позволить себе роскошь покупать ваши крутые разработки.
но вам это не понять.
 

pvvx

Активный участник сообщества
Так фокус-то в том что я не включаю wifi вообще а наоборот пытаюсь его еще и выключить.
как это нема исходников?
Я написал код в блоге.
Там правда всего три оператора в первом и 2 во втором примере.
Понимаю, что код сложный, если надо, то выложу снова.
Опять няньку требуете разбираться в ваших непонятках? Стратегия вам описана - мелочи поправите сами.
Вы были назначены Начальником траспортного цеха и разгребать ваши и чужие непонятки теперь вам, как самому заядлому любителю устаревших чипов. :) А моё дело посмотреть исполнение пророчества – полного заката этой тематики, для поправки статистики, как это произошло со многими темами, к примеру... пусть с STM8. Они ещё в продаже есть, но по тихому исчезают… :)
 
Сверху Снизу