• Система автоматизации с открытым исходным кодом на базе 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. Они ещё в продаже есть, но по тихому исчезают… :)
 
Сверху Снизу