Самое обидное, что это не регулярная ошибка, а какая то случайная. Модуль может работать не зависая 10-100 коммутаций, а может через 1-2 коммутации
digitalWrite(GPIO,1); delay(50); digitalWrite(GPIO,0); delay(50); //включить/выключить пин.
повиснуть. По твоему совету поставил dеley(50); после digitalWrite(); знаешь, заметил что зависания стали реже, но всё равно остались. Потоков действительно больше 1, т.к у WiFi явно свой поток
Спасибо за подсказку. В этом мануале 700 с лишним страниц. А не подскажете, если вы разобрались, где в данном вашем коде определён 15 пин. Меня уже радует, что компилятор пропустил ваш код без ошибок и ругани
wifi на нулевом ядре, перенеси свой код на 1 ядро
Я думал он по умолчанию на 1 ядре.
Разобрался, блинк заработал. Попробую внедрить в свой. Спасибо.
вроде на 0, но это не точно
тут специалистом по esp32 был @brokly, не знаю живой ли, давно не видел его постов
Для ESP32 есть вариант DirectIO.h для работы непосредственно с пинами.
а ссылку на библиотеку?
Не нашел этой библиотеки. Для AVR есть.
Вообщем поймал что происходит с ESP32 во время якобы зависания. При нормальной работе контроллера, в лупе моргает диод со скважностью 50% раз примерно в секунду. Когда происходит сбой, этот светодиод начинает мигать, точнее гореть 36 секунд, потом пауза 36 секунд, потом опять 36 секунд горит и так по кругу. Короче выяснилось, что похоже частота контроллера очень сильно снижается. Вот теперь стоит задача выяснить, почему это происходит, и как из этого состояния выйти контроллеру самостоятельно (без вмешательства человека). Так же использовал советы от microsystems и от WladDrakula, ни чего не помогло.
Ну есть же старый совет: попробуй сделать минимальный проект, на котором повторяется эффект. Кинь сюда. У меня с 15 января начинается интенсив изучения языка 5 часов в день 5 дней в неделю и 5 месяцев подряд 
, но может вечером смогу что-то посмотреть. Не обещаю, но попробую.
Может и не частота снижается, а высокоприоритетная задача не дает моргать блинку нормально. Скорость CPU можно и в сериал вывести…
конечно это так. Но найти путь преодоление этой херни без примера нельзя.
У меня РОВНО такое было, когда я в одном из потоков забыл прописать делей в for(;;){ /* что-то-там*/}
Нет таких подпрограмм в скетче. Как я уже говорил выше, это WiFi реле. Мне удалось выяснить что происходит на обьекте. Оказалось, что этим реле заказчик управлеяет кроме активной нагрузки (лампочки) ещё и маленький мотор (220 вольт 0,4А) сидит на этом реле. Вообщем если мотор не подключен, то реле работает без проблем. Как только подключают мотор, реле иногда как раз залетает в это не понятное состояние именно в момент выключения. Я понимаю, почему иногда, потому что смотря какая амплитуда синусоиды была в момент выключения (ЭДС самоиндукции прямая зависимость). Сама релюха естественно шунтирована диодом (на опережающий вопрос). С эмулировал данную схему у себя на столе, зависания подтвердились (как на обьекте). Вот вам и написал про понижения частоты предположительно. Вот такая ситуация, пока не решенная. Дракула, попробую сделать минимальный код, чтобы повторить ситуацию, Только вряд ли ты будешь собирать схему, ведь с активной нагрузкой как не щёлкал реле, ну не смог загнать я её в этот глюк. Сама реле питается через блок питания вот такой
реле вот такая
Для заказчика решил вопрос поставил вместо контактов, омроновское твёрдотельное реле, две недели полёт без сбоев. Но мне самому всё равно интересно что происходит то? Ксати, если поставить снаббер (50 Ом 0,1 мкФ), то тоже помогает. Но это не выход со снабером, он выходит габаритным очень, по этому не вариант с ним. Вот такая патовая пока ситуация.
снабер обязан быть
Пересчитать на 0.01 мкФ( всё ж поменьше будет), использовать варистор(вместо или вместе с цепочкой). С омроном тоже может быть не всё гладко. Во первых это наверняка “китайский” омрон, а там МАХ предел 240В. Во вторых - оптореле нелюбят МАЛЫХ индуктивных нагрузок и в один момент при снятии упр. сигнала могут тупо не отключится. И один хрен к ним так же нужен снаббер 
Вообщем эпопея продолжается. Сегодня вернулся к модулю. Решил подключить COM порт, и заметил, что когда при очередном выключении мотора еспэшка выкидывает в порт вот такую надпись: Brownout detector was triggered и после этого ребутится. Но это происходит иногда корректно (да и пусть бы так, если бы это происходило всегда), но не часто, вылетает вообще не известно куда, в порт начинают сыпаться байты с неизвестной скоростью передачи (пробовал до 250000 больше нет не понятно что хочет) и дальше ее из этого состояния можно вывести только жестким ресетом. В лупе крутится только server.handleClient(); ну чтобы управлять осталась возможность через http://191.168.x.x/1
Больше ёмкости богу ёмкости. 
Это к тому, что излишняя ёмкость - то-же зло.(По крайней мере на AVR)
Переведи на русский 
Питание микроконтроллера отделить от общего диодом и не шибко большое( до 1000 мФ). Может и блмку али проходной конденсатор добавить.
Ерерик