Результаты поиска

На случай старта ESP8266 надо грибы? Грибы наверняка растут во рту у =AK=. Тут к дохтуру и ходить не надо. Показаны осцыллы при подводе предельных бытовых пульсиков... На бытовых "банках", без привлечения дохтуров наук, доказано и наблюдается, что не только защищают от ESD, но и ограничивают...

Вас не принуждают ставить варисторы или другие супервизоры для борьбы с помехами и защиты. Если вам надо, чтобы от "теста отверткой" работало стабильно - тогда надо что-то ставить из данного барахла... =AK= не умеет бороться с бытовыми помехами, и это признал. Номиналы +- 200% пофигу. Не на...

Нет защиты "от глупостей в Ардуино". Если вдрух прошьете прошивку с выводом на данные пины PWM, то будет кз на кондер вывода GPIO. При старте и в режиме прошивки на некоторые пины ESP8266 выводит всякую бяку, типа частоты кварца.... В доке писано - до 10 мА на пин. Это 330 Ом при 3.3В. =AK= вам...

Это уже было несколько раз. И исходник давался. Вам давались варианты и с анализом напряжения питания на входе ADC при старте и если менее - deep_sleep. Из одной из версий его вы и взяли код для своего недо-бута. В последний раз это было тут...

По пунктам объясняю ваши ошибки: 61 мс - это минимальное время исполнения загрузки кода в сотню байт, плюс исполнения программы перевода ESP8266 в режим "deep-sleep" с таймером и Flash в режим "sleep". Работа с RTC сопровождается ожиданиями исполнения команд на её тактовой частоте RC генератора...

Ну и что я вам трынжу уже годы? Типа этого: Вам уже писал, что на пакет "probe request" ответ приходит стандартно и что данный пакет принимается всеми WiFi роутерами и прочим барахлом и в них есть встроенные команды логирования этих пакетов, что не требует перевода устройства в режимы снифферов...

Вы про что? 35 мс - это время от старта до конца загрузки rapid-loader-ом стандартного SDK. График и коды для проверки представлены в его репе на git. Далее возможен опрос устройства, если грузился не китай-SDK, а типа meSDK и передача команды отключения питания управляющему устройству. За 2 мс...

Есть ещё варианты :) : Ответ же дал - надо разбежаться до 4 км в секунду. Иначе не будет тока. На вход ADC отверткой не ткнули :) Для тупых все вумные выглядят клоунами. От вони большого идиота =AK= спасает только "вонючка", по аналогии в авто.

Открытый сокет в Arduino может вызывать переполнение стека, а при работе с espconn ресурсы на буфера затрачиваются в 3-х кратном размере. Web свалка позволяет держать десятки одновременно открытых соединений на тесте https://esp8266.ru/forum/threads/web-svalka-na-rtl871x.2403/page-2#post-36109...

Копавшившись тут в своих бэкапах, обнаружил, что у меня давно был недоделанный вариант включения INA219 к клону STlink адаптеров с али за 100 рупь... Доделал - https://esp8266.ru/forum/threads/esp8266-sverxmaloe-potreblenie.3299/#post-50264 USB1.1 впритык... OpenGL из Delphi 7 рулит и на 100500...

Нет. В Arduino ничего не пройдет. "Мало памяти" и так для C++.

Да любой провод можно. Главное правильно распаять общий контакт у всей бадьи... Вам с ним не на войну с импульсными снарядами со спиральными взрывомагнитными генераторами и урановых стрежней-снарядов :) Вот у мене импульсы переходят в механическую энергию в РК кабеле, а у =AK= - в глупость... :)...

Дык в чем проблемс была на другом варианте? USB2UART мешала? Тыкание отверткой на вывод ADC модуля не сбрасывает модуль? В самом модуле вообще нет никаких резисторов подтяжек, кроме одного, и то не всегда... Есть некие зависимости, если говорить о помехах, когда на какой-то пин подаются...

Где? Вы выдумали сами что-то. Проверяйте :p И pdf ваш подтверждает сказанное мной - пачка 10 см серебренных кабелей с антеннюацией в один выход. :p Прям типа автор дурачек - включил бы простой РК-50 и горя бы не знал, слушая =AK= :) :) Но всё равно не получил того что вам задано найти - до 10 нс...

IP в меню TCP2UART, а не WiFi установках... Данная прошивка давно заброшена и не всё там доделано до "нормы", т.к. появились более лучшие модули, с новыми WiFi-SoC... --- Это касается именно соединений с внешними серверами. Много нюансов в дисконектах и прочих перезапросах при плохой связи...

ESP8266_NONOS_SDK_V2.0 из последнего на сегодня UDK, в нем же и собрано. Flash прописана как QSPI, 80MHz. Красный, короткий, аналог действий SDK - загрузка и прямиком в deep_sleep с опцией без запуска WiFi. Наглядно видим, что нам впаривает тут nikolz :) Сдвиг на 33` мс от разницы на 1 символ...

tcp_put_mac(xnetif[WLAN_AP_NETIF_NUM].hwaddr); Правило у SDK получения MAC в дровах: 1) распаковывается* eFuse в структуру настроек WiFi под названием типа eeprom (struct _ADAPTER, eeprompriv). 2) на неё накладываются* значения из Flash сектора по адресу 0xA000. 3) Если все 6-ть байт MAC равны...

Нет, опять не так. ~35 мс - это старт ESP до исполнения любого кода при стандартном типе загрузке "Flash". Примерно, по причине разницы времени старта кварца у разных модулей. Разброс параметров. Выход в deep_sleep у SDK выполняется более 100 мс. Чтобы запустился SDK требуется полная его...

Там стоит примитив - затычка, т.к. неизвестно, что вам надо. "Производители с али" RTL-00 пишут MAC во Flash из стандартной прошивки "AT". Остальные, именно производители модулей, пишут MAC в eFuse. При перепрошивке вы стираете его своим, какой понравится... :)

Очередные ошибки. Вам необходимо привести диаграмму с недо-бут и стандартной SDK? Платите за такие испытания, т.к. интереса это не представляет - заранее известно, что выйдет за 200 мс даже без включения WiFi. В Arduino и более. Только применение хаков, указанных в rapid-loader, meSDK, SDK no...