xvr

Это потребление 'всего' ESP32 в каждом режиме сна. Это и в даташите есть. Нужна разблюдовка по каждому модулю. Для оценки реального потребления при периодическом 'сне' этих данных категорически недостаточно.

Господа, у меня возник один теоритический вопрос. Есть микроконтролер и к него есть какой то sleep режим. В нём он потребляет порядка 10мкА при питании 0.7В. Сам микроконтролер питается от 3.3В и 0.7В получают внутри с помощью LDO. КПД при этом получается около 20%. В теории импульсный понижающий преобразователь мождет дать больший КПД. Бывают ли в принципе импульсные понижающие преобразователи на такие токи? Я имею в виде не законченные микросхема, а хотя бы топологии.

Господа, может у кого нибудь есть какие нибудь экспериментальные данные по потреблению разных узлов ESP32 в различных sleep режимах? Родные даташиты хранят гордое молчание по этому поводу. Есть только общее упоминание списка этих sleep режимов и потребление ESP32 в целом в них. Но как только дело доходит до подробностей, возникают проблемы 😞 Например в deep sleep нам обещают 6.5мкА, но это если только спать. Без пробуждений и каких то действий deep sleep бессмысленнен, ч тем же успехом можно просто вырубить питание. Для опросов в sleep режимах есть ULP (Ultra Low Power coprocessor), но тут начинаются неизведенные земли 😞 Он умеет просыпаться по таймеру, отрабатывать опрос переферии (он для этого и сделан) и снова засыпать. Сколько он потребляет - покрыто мраком (в Интернете нашёл цифру 0.15мА), а сколько потребляет ADC, который может запускаться из ULP - вообще покрыто абсолютным мраком (даже Интернет по этому поводу молчит)

https://www.sourceware.org/gdb/ У вас сорцов нет. gdb в составе toolchain'а поставляется в бинарнике. Просто регистры. Конкретно: mips64-linux.xml mips64-cpu.xml mips64-cp0.xml ну и mips64-fpu.xml

Интересно, а у Qt нет своего инсталятора? На чём то они web install самого Qt сделали

https://www.thethingsnetwork.org/forum/t/esp32-low-power-topic/48346/16

Это я тоже писал - это всё очень общие приближения. Точных цифр в DS нет, потому точно посчитать нельзя. И я не утверждал, что это будет именно 0.1mkA. Я так же говорил, что точную цифру можно получить только замерами. По поводу 6.5mkA - цифра из даташита для типичного применения deep sleep и ULP. Вся аналоговая периферия туда входит, поэтому МОЖНО НАДЕЯТСЯ что реальные цифры будут не сильно отличаться. Это есть в DS - при работе из RTC/ULP скорость оцифровки 200Ksps. А где подтверждения с вашей стороны, что будет гораздо больше? (Если уж от меня вы таких требуете) Обещают цифры такого порядка, если не совпадут - притензии в Espressif Откуда взялся аккумулятор? А вдруг случится чудо и действительно хватит? 🙂 Тут есть подводный камень - LDO нужен не менее чем на сотню другую милиампер и с собственным током потребления в районе микроампер, иначе весь deep sleep от ESP будет неэффективен - LDO сожрёт больше 😞 Ещё момент - BLE beacon может сожрать больше, чем ULP сон с периодическими опросами. Интервал в 1 минуту может оказаться слишком коротким - BT жрёт по полной, там далеко не микроамперы 😞

Его изучили, но нейронные сети (вычислительные) используют ОЧЕНЬ и ОЧЕНЬ упрощённую модель. Она весьма далека от нейрона в мозгу.

Во первых - *.o файлы лишние. Во вторых - собирите release версию и возмите release версии библиотек (без *d в конце имени) Возможно понадобится VC redistributable (проверьте какую версию использует MingW)

Либо выносить этот код в отдельный класс/функцию/файл и считать его реализацию (не интерфейс) платформо зависимым, либо вообще не пытаться делать 'чистую' С++ версию - она у вас не сейчас получилась. Вот это и страшно - даже одной строчки достаточно. Это значит, что вы не сможете просто так взять этот код и откомпилировать на другой фреймворк. Вам понадобится модификация исходного кода. Тут одна строчка, там одна строчка и т.д. И самое неприятное в этом, что где именно эти строчки и сколько их знаете только вы. Если эти строчки вынести в отдельный файл проблема исчезнет - у вас есть ваша библиотека и отдельно платформо зависимый файл, который необходимо адаптировать при переносе на другую платформу.

Ну он как бы не совсем 'чистый' - там используется Qt класс Comm порта вместе с его особенностями подключения - connect и слот. И без Qt это работать не будет. Поэтому ценность С++ версии под вопросом - её 'чистота' была нарушена 🙂

Возможно. Думую это только ТС может выяснить, причём экспериментально 🙂

Включать и выключать конечно. Иначе он весь power бюджет сожрёт 🙂 Разумеется Небольшой конденсатор прямо на выход переменника вполне сойдёт, я думаю. PS. Только это всё надо не мне советовать, а ТС 🙂

Update: Нашел в DS скорость ADC (в RTC режиме) - 200Ksps Так что среднее потребление будет 0.1mkA (я ранее слегка преуменьшил, посыпаю голову пеплом 🙂 )

Для любителей спорить с даташитами в стиле Станиславского: ещё раз повторяю (возможно с третьего раза дойдёт) - АЦП не работает непрерывно, он просыпается 1 раз в 100ms и делает одно измерение, после чего отключается. Даже если он в активном состянии потребляет те самые 2mA, среднее потребление будет 0.023mkA (считаем, что работает он от тех же 8MHz, что и ULP, и режим на 9 бит). Для неверующих - ESP32 Technical Reference, 31.3.8 Power-Gating Implementation ADC входит в 'sensor controllers', и в RTC Sleep он выключен. Мне сюда весть Technical Reference приатачить?

Когда поймут, вот тогда и можно будет говорить об истинном ИИ 🙂 А если серьёзно, то во первых нейрон мозга гораздо сложнее, чем условня ячейка м нейронной сети. Во вторых количество их в мозгу гораздо больше, чем в любой современной нейронной сети. Ну и в третьих - мозг это скорее аналоговая вычислительныя машина. Сигналы передаются в аналоговом виде и порог срабатывания плавает в небольших пределах. Это вводит момент недетрминированности, чего современные нейронные сети лишены (хотя это может быть легко сэмулированно, кто знает, может уже и ест какая нибудь недетерминированная сетка 🙂 ) Ну и в целом, никто толком не знает, как работает мозг. Нейронные сети лишь краешком захватили то, что мы сумели пока понять.

Интервал между просыпаниями - 100ms (из сообщения ТС). Сколько ULP понадобится для обработки ADC - не знаю. Пусть 2ms. Сон 1/50 Он собирался пробуждать основной процессор, а не ULP. А это две большие разницы. С чего бы вдруг? И ADC вполне сюда уложится (ну добавит ещё 0.5mkA)

ОБЯЗАНА быть нелинейная функция, иначе последовательность умножений матриц сведётся к одной матрице. Будет конечно. В неросетях ПОСЛЕ ОБУЧЕНИЯ нет каких либо недетерминированных процессов. Что не мешает им работать и успешно симулировать ИИ

Сам, собирает из кусочков. А мог бы получать сразу полное сообщение. Это черевато. 'Мусор' от соседнего протокола может поломать другой протокол. Не стоит насиловать средства обнаружения и коррекции ошибок протоколов заливая им широким потоком мусор, в надежде что они его отфильтруют 🙂 У Qt эти буфера уже есть и встроенны в connect систему. Если вам очень хочется добавить ещё один - свой, то вам этого конечно никто запретить не может. Вполне для Qt решение.

ADC вместе с ULP будет преимущественно 'спать'. Они при этом практически не потребляют. Данные из Technical Reference Manual, параграф 31.3.9 Predefined Power Modes Параграф 31.3.10 Wakeup Source / Таблица Table 139: Wake-up Source WAKEUP_ENA Wake-up Source Light-sleep Deep-sleep Hibernation Notes* 0x1 EXT0 Y Y - 1 WAKEUP_ENA Wake-up Source Light-sleep Deep-sleep Hibernation Notes* 0x2 EXT1 Y Y Y 2 0x4 GPIO Y Y - 3 0x8 RTC timer Y Y Y - 0x10 SDIO Y - - 4 0x20 Wi-Fi Y - - 5 0x40 UART0 Y - - 6 0x80 UART1 Y - - 6 0x100 TOUCH Y Y - - 0x200 ULP co-proccesor Y Y - - 0x400 BT Y - - 5 Как видим в Deep Sleep ULP может пробуждать основной процессор, значит сам ULP работает (вместе со всей доступной ему периферией, ADC туда входит)

Да, если включить.

2 TC: потребление ESP32 в режиме deep sleep обещают в районе 6.5mkA. ULP при этом работает (точнее изредка просыпается) и может опрашивать ваши кнопки, реостат и батарейку. Режим hibernation (это максимум) обещают в районе 4.5mkA, но ULP в нём не работает - просыпаться можно только по таймеру. Решайте сами - вас устроят эти цифры?

Повесьте опрос кнопок и потенциометра на ULP. Он будет просыпаться сравнительно часто (те же 100ms), опрашивать всё и будить основной процессор, если надо. А основной будет спать в deep sleep режиме всё время. Правда опрос придётся на ассемблере писать 🙂 PS. А для BLE не надо преиодически просыпаться? Что бы из сети не вывалился? Так, для сведения: DAC в ESP32 сделан на основе резисторной цепочки (8 битов). Так что потреблять он мало не может (в DS данных нет 😞 ). И точности ТС может не хватить. В любом случае тут нужны натурные эксперименты 😞

Не совсем поллинг. Скорее чтение с блокировкой. Тут возможны 2 модели обслуживания порта и протоколов - push и pull. В push модели инициатором процессов является источник данных - ком порт. Он собирает буфер и вызывает callback/виртуальный-метод/сигнал(в слот). Следующий уровень принимает данные, обрабатывает и отпалвет дальше (тем же способом). Это ваш подход. В pull модели инициатором событий является приёмник. Он вызывает метод get нижнего уровня, который вызывает get дальше и так до самого низе (ком порта), где этот вызов блокируется до прибытия данных. В таком подходе всё это необходимо запускать в отдельной нити и результаты из неё передавать в GUI уже в push модели. Этот метод проще в реализации, т.к. каждый уровень сам определяет когда он собрал всю необходимую ему информацию и полностью управляет процессом её обработки. В push модели данные приходят на уровень так, как их собрал нижний уровень и текущему приходится к этому адаптироваться (он не может управляеть приёмом). Приходится либо делать уровни на основе машин состояния и/или применять промежуточную буферизацию. Обе модели могут легко переходить друг в друга посредством потока и очереди (самописного кольцевого буфера или std::deque - если не хочется изобретать велосипед) Т.е. протоколы сами разбираются - из это данные или нет? В этом случае они ВСЕ должны знать о формате данных друг друга, что видится несколько ... (как бы это без мата сформулировать ...) в общем у меня нет слов 😞 Либо формат у них должен быть один - но в таком случае это НЕ разные протоколы. Либо в формате есть структура некоего контейнера, и протоколы извлекают оттуда свои данные (каждый из своего места). В таком случае у вас неправильно построе приём - у вас де факто 2х уровневая струкутра данных (контейнер + разные данные) и обрабатывать её должен 2х уровневый обработчик - разбор контейнера (1 протокол) и пачка протоколов нижнего уровня - туда протокол верхнего будет отправлять разобранные данные Ну если вам так хочется устраивать закат солнца вручную, то можно и так. По сравненю с push моделью в отдельном потоке это КУЧА лишнего кода. А где собственно поля protocol_1 и protocol_2 в которые вы пытаетесь писать из конструктора? Да, про 'закат солнца' я уже писал 🙂 Нет, Нет. Исключение - очень дорогая операция, и в С++ нет портабельного метода обрабатывать такие исключения (они не пересекаются с С++ exception'ами) PS. callback и витруальная функция (как вам её предлагают) по сути одно и тоже. Только виртуальная функция - это OOP сущность, а свободная функция callback - нет. Кстати, метод класса (я надеюсь, что обрабтчики протоколов у вас классы, а не отдельные функии?) нельзя передать в качестве свободной callback функции - у них разные способы вызова.

Вы его должны написать сами (или поискать где то на стороне готовый), а потом подсунуть gdb через его команду set tdesc Технология простая - в gdb встроенна поддержка архитектуры по максимуму, но так как поддержка тех или иных фич архитектуры отличается от процессора к процессору, то конкретное подмножество поллерживаемых фич (и разновидностей архитектуры) описывается в tdesc файле. В gdb есть встроенные, используемые по умолчанию (они далеко не самые полные), но он может после подключения к конкретному камню запросить у адаптера (который к камню подключал - например у OpenOCD) tdesc файл под процессор. Но адаптер может это и не поддерживать. Тогда можно этот файл скормить прямо в отладочной сесии через set tdesc PS. В сорцах gdb эти файлы лежат в дире binutils\gdb\features\ Для MISP там есть: mips64-linux.xml mips-linux.xml mips64-dsp-linux.xml mips64-linux.xml