У Вас целая секунда на измерение частоты. Если по прерываниям не проходит, то можно путем опроса пина с использованием вероятностного подхода.
Секунды нет, если не разрывать связь WiFi. Связь с AP в стандарте WiFi устанавливается от 2-х до 5 секунд, в зависимости от роутера и установок соединения. Если глушили (отключили) WiFi, то гарантированно связаться получится условно раз в десяток секунд, с паузой отключения для измерения. Все остальные варианты приведут к глушилке местных сетей WiFi, из-за действий в эфире не по стандарту. Станция при связи должна просканировать эфир, найти свою AP, синхронизоваться с её beacon, по умолчанию посылаемый 10 раз в сек, произвести регистрацию на AP, получить IP, передать данные, произвести отключение от AP по протоколу. На это у стандартных бытовых роутеров и уходит не менее 3-х секунд.
Просто включиться и орать в эфир когда захочется по принципу диктуемому в доп. нестандартных протоколах от Espressif - это значит глушить другие местные соединения WiFi.
Тут проще сразу переписать ПО на ESP8266 на такой вариант:
WiFi jammer - YouTube
Если увеличить время следования beacon на роутере, то можно получить увеличенную паузу между ними, объявить станцией что мы спим (пропускаем до 3-х beacon, типа DTIM3). В таком варианте сеть у этого роутера становится "тормозом", но если он служит только для этого соединения, тогда - плевать. Тут главное от станции точно вычислять время между приемами beacon, не терять их. Иначе у станции будут задержки в передаче до приема следующего beacon, определяющего арбитраж.
============
“Вероятностный подход” на ESP8266 будет слишком вероятностным. Любая система, работающая с другой, внешней, должна успевать обслуживать внешние события. В данном случае – это WiFi связь. Т.е. между внешними событиями система должна успеть обработать задачу по ним. Если код написан оптимально, то его время исполнения мало. В случае с SDK Espressif это не так.
Например, имеем, что для поддержания связи по WiFi, пусть за время следования becon (100.24 мс), надо исполнять код в 2 000 000 тактов CPU. За секунду это 20 000 000 тактов (20 МГц). Пусть прерывание по пину отнимает 500 тактов. При штатных 80 МГц CPU имеется всего 80 000 000 тактов. Отнимаем 80 000 000 - 20 000 000 = 60 000 000 свободных. Делим на 500 тактов прерывания – получаем предел в 120 000 Гц. Если более – система рухнет. (Данные взяты с потолка, примерно для моего обрезанного SDK в Web-свалке, для стандартного SDK Espressif они хуже, в Arduino ещё значительно хуже, в LUA, с сиcтемой получения каждого байта данных из Flash по прерыванию защиты - вообще не влезают во время необходимого исполнения роли заявленной поддержки WiFi...)
Это если по прерываниям. Тут вычислять ничего не требуется, кроме деления накопленных за время прерываний и формирования пакета передачи (что тоже требует времени и надо вычесть из общего – это ещё уменьшит максимум частоты прерываний).
По “Вероятностному подходу” вам потребуется переписать всю систему SDK на исполнение в другом треде или по прерываниям, которые будут прерывать ваш цикл опроса. Но, в данном случае у нас не RTOS, приоритеты задач не выставляются и система SDK Espressif не рассчитана на такую работу. Значит вам придется выделять системе время самому, в своем цикле и описать сложную и большую по времени обработки процедуру расчета вероятностей, исполняемую всегда и как можно непрерывнее. Это, обычно, отнимает большее кол-во тактов, чем система работы по прерываниям с целочисленными вычислениями. При вероятностном обязательно потребуются сложные расчеты с плавающей точкой, на что уйдут все "свободные" такты CPU. Как итог всего этого – ужасная выходная точность. Это нормально только для "научного предприятия"
При использовании RTOS системе требуются дополнительные такты на обслуживание. Проверить минимум можно простым понижением частоты CPU. К примеру, на RTL871x система связи с WiFi и RTOS с тиком в 1 мс работоспособна и на 4 МГц, при этом ещё как-то обслуживает передачу файлов и прочее через TCP стек LwIP. Выходит, что для его текущего кода и сохранения работоспособности необходим минимум в 4 000 000 тактов в секунду. При максимуме CPU в 200 МГц - это всего 2%. С этого далее можно посчитать и минимальное потребление… (уже давно известно, что оно во много раз менее чем у ESP8266
). Если увеличить тик системы RTOS, то получим ещё меньше... Но тут палка о двух концах - будет страдать время реакции... По этому, для связи с WiFi применяют другую политику для уменьшения потребления - спят в паузах между beacon, накапливая стек задач, а во время окна приема beacon включают CPU на максимум CLK и исполняют накопленные задачи, затем опять засыпают до следующего beacon. При этом во время "сна" отключается всё по выбору. Можно например оставить работать CPU на 4 МГц для счета внешних событий, или активными некоторые прерывания. А вот ESP не имеет распределений что и как глушить на время "сна" между beacon... Как итог - никакой гибкости системы в ESP нет и пути уменьшения потребления в ней имеются только с отключением всего и потерей синхронизации любых таймеров и других внутренних устройств.
Все проблемы у ESP чисто программные. Espressif имеет закрытый код SDK, рассчитанный только на одну задачу - их пример IoT со связью с их сервером раз в час по его протоколу с передачей пару данных и исправить эту ситуацию вам не удастся. Всё написанное на него "сообществом" сделано вопреки и в виде дополнительной "нашлепки" увеличивающей время исполнения и общее время реакции системы. Т.е. все они уродские и не представляют никакого интереса для дальнейшего развития направления IoT в целом. Аналогично и с ESP-32S.
