Вам удалось исправить драйвера BLE в ESP32?
BLE-библитотека ядра ESP32 очень тяжелая, поэтому я пользуюсь другой, аналогичной и полностью совместимой, но она существенно полегче, и, судя по всему, работает стабильнее - NimBLE-Arduino.
Вы опять чего-то напутали. Видимо пристрастие к Ардуино дает себя знать.
Ваша бабушка не в состоянии принять данные от сотен датчиков...
Обратите внимание на первую строчку комментария в коде процедуры сканирования:Вы опять чего-то напутали. Видимо пристрастие к Ардуино дает себя знать.
Каким фигом АЛУ принимает радиоволны, детектирует и декодирует модуляцию?
Вашей библиотекой от Ардуино? Ногодрыгом?
Вооще-то, в любом нормальном чипе сам процессор не занят приемом, а получает пакеты по прерыванию и DMA. CPU остается только перекинуть блок в пользовательский код. Даже при использовании кривой и тормозной (Ардуино-RTOS) ресурсов на это требуется не более самого тупого Cortex на 5-8 МГц.
/**
* @brief Start scanning and block until scanning has been completed.
* @param [in] duration The duration in seconds for which to scan.
* @return The BLEScanResults.
*/
BLEScanResults BLEScan::start(uint32_t duration, bool is_continue) {
if(start(duration, nullptr, is_continue)) {
m_semaphoreScanEnd.wait("start"); // Wait for the semaphore to release.
}
return m_scanResults;
} // startМне достаточного принять данные от одного датчика но с гарантией и без тупого ожидания следующего рекламного пакета.
Если вам удалось реализовать в своем коде прием рекламных пакетов без ожидания, тогда поделитесь примером кода с неразумной Arduino-школотой...Вы опять чего-то напутали. Видимо пристрастие к Ардуино дает себя знать.
Каким фигом АЛУ принимает радиоволны, детектирует и декодирует модуляцию?
Вашей библиотекой от Ардуино? Ногодрыгом?
Вооще-то, в любом нормальном чипе сам процессор не занят приемом, а получает пакеты по прерыванию и DMA. CPU остается только перекинуть блок в пользовательский код. Даже при использовании кривой и тормозной (Ардуино-RTOS) ресурсов на это требуется не более самого тупого Cortex на 5-8 МГц.
Сделайте расчет пары вариантов, в каком варианте будет более уверенный и более стабильный прием с 3..10 датчиков, при условии импульсной помехи (работа WiFi роутера) и удаления датчиков (с низким уровнем сигнала).
Это статья прыгающая по верхам и совершенно не информативная. Уровня - тупенькое упрощенное описание для детсада про основы BLE.
).
Рекламные пакеты не требуют никакой системной обработки, сборки в стек, кеширования. Об этом указано даже в вашей "статье в мурзилке".
Не знаю как вам еще объяснить. Чтобы поймать в эфире рекламный пакет вам необходимо периодически выделять время процессора и слушать эфир. Либо заниматься только этим и больше ничем. В случае режима подключения обработка пришедшего уведомления происходит по прерыванию, давая возможность процессору решать другие задачи. Вот и вся разница. Кто знает о чем речь, тот поймет.
Кстати, спасибо за прошивку, похоже, что она действительно меньше использует батарею в режиме подключения.
Вам сразу с тяжелого пояснять?
Только при определенных условиях. На практике это не более 20% вариантов реального пользовательского (потребления как рабочее устройство) использования и этот процент уменьшается при работе с ESP32 за счет нескольких факторов заложенных в подходе разработки кода и самого чипа ESP32.
CPU не занимается приемом. CPU однократно заряжает регистры приемника и DMA/fifo. Далее ждет прерывание приема RF фрейма. DMA/отображение FIFO передатчика настраивается на круговую последовательность статических буферов и работает автоматически, вызывая прерывания завершения приема фрейма.
Всё уже понятно, что вы никогда не работали с реальными системными драйверами и прочим ПО. Так сказать начинающий спамер-противоретчик без знаний.
Куда уж нам до писателей двайверовВсё уже понятно, что вы никогда не работали с реальными системными драйверами и прочим ПО. Так сказать начинающий спамер-противоретчик без знаний.
Много умных и красивых слов, но на данный момент реализовано и работает так, как я описал выше. И никто пока лучшего не предложил...Параметры Connect-а: minimum connection interval, maximum connection interval, slave latency, and time-out.
Особое внимание обратите на slave latency. Когда разберетесь, то осознаете, что приемник должен быть готов всегда. Но кроме приемника в BLE должен быть готов и передатчик. И для обоих необходимо подготовить и содержать разные счетчики и два уровня абстракции протокола с декодированием шифрации, масок, анализа перезапросов, передач подтверждений в минимальные фиксированные интервалы и кучу буферов и прочих обновляемых переменных. Это всё ложится на CPU - программный драйвер BLE.
А при приеме рекламы CPU и драйвер обслуживает только прерывание и передачу указателя на принятый фрейм.
Обычный сниффер - в реальности, на практике, принимающий значительно более 300 рекламных пакетов в секунду при ничтожной нагрузки на CPU.
Но реализация вашего Ардуино-драйвера содержит более 95% никчемных действий, т.к. заточено не на работу, а на обучение начальным понятиям. Т.е. пытается разложить, декодировать, разбить на типы пакетов и последовательности, на какие-то временные окна и создать десятки логов, на что уходит производительность двух ядер с более 200 MГц. И то, в реализации ESP32 не справляется с тупой задачей. И т.к. размер кода этой обработки занимает сотни килобайт (!), то там миллионы ошибок и никакой гибкости - никакой возможности оптимизации, т.к. всё повязано друг на друга. Тем более используется алгоритмы с динамическим распределением RAM, плюс C++, что обязательно когда-нибудь вызовет дефрагментацию и отказ системы, т.к. в ESP32 нет MMU.
Т.е. о надежности разговор вообще не идет.
И это вместо того, что решает любой, хоть 8-ми битный CPU на десятку МГц со статическими буферами и одной страницей кода на СИ без наличия каких либо ошибок и неточностей выполнения!
забыли дописать - ... 'на халяву'?