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

https://pvvx.github.io/MJWSD06MMC/ https://pvvx.github.io/LKTMZL02/ https://pvvx.github.io/ZY-ZTH02Pro/ https://pvvx.github.io/TS0201_TZ3000_v1w2k9dd/ ...

Всё верно - вы должны подготовить ответ до приема сообщения :P Аналогично в nFR24 и прочих протоколах связи.

Можно вообще плюнуть на калибровку, уменьшив интервал соединения. Калибровка сказывается только при интервалах соединения более 1 секунды - там набирается уход и соединение будет потеряно. А при коротком интервале % ухода не сильно сказывается на окно приема/передачи.

SYS_DisableAllIrq(&irqv); и SYS_RecoverIrq(irqv); в процедуре Calibration_LSI выполняется на время менее 1 такта RTC. А при BLE соединении всё работает по прерываниям и это не особо мешает, кроме создания дыр, пока CPU находится в процессе Calibration_LSI(). К примеру для UART это вообще не...

Калибровка актуальна при режиме энергосбережения и она выполняется во время передачи маяков. А там хоть секунду занимай CPU - ничего не случится, кроме разряда батареи. И все оптимизации необходимо выполнять с учетом потребления, а не какой-то загрузки. Для этого необходимо исключить все лишние...

Для без паузного обслуживания BLE по типу запрос-ответ, требуется готовый ответ за время до 150 мкс после приема последнего бита сообщения. Т.к. после передачи последнего бита через 150+ мкс ожидается прием. И если его нет (не готов) – следующие транзакции будут через интервал соединения.

Все USB-BT адаптеры сидят на USB2.0FS. Это тайминг опроса в 1 ms. Плюс используется аппаратное FIFO для USB3.0 - это килобайты. И передача данных в пользовательский уровень идет по заполнению или таймауту. То есть только тут вы имеете паузу от 1 ms между приемом и передачей и не можете...

Вы в курсе, что самый крутой CPU на компе не способен обеспечить побайтный прием из UART на скорости 115200 baud? При прерывании низкого уровня опустошается вся кэш CPU и лазание через PCIe с отложенными транзакциями по таймауту UART не позволяют так часто выходить из пользовательского уровня...

Итог с INA228 таков – предел 10 килобайт в секунду. И уже изредка наблюдаются артефакты стека WCH (ляпы кусков от других замеров в передаваемых данных). Функция GATT_Indication()п уже практически непрерывно орет ошибкой 0x16 - blePending: A confirmation is pending with this client При...

Дык никто так не строит протокол. При прямом запрос-ответ вы словите все задержки по всему пути, включая верхний уровень программы на компе.

Подтверждение приема, а так-же прочие тайминги, передает/определяет сам адаптер и внешнее ПО на скорость и объем переданного потока роли не играет. 310 кбод -это всего типа 31 килобайт в секунду - для любого нормального чипа BLE это начальный уровень. Некоторые реализации OTA имеют скорости...

Так же замечено, что иногда у WCH, с нормальным адаптером BT5.0+ проскакивает условно полтора пакета (полтора MTU) в интервал 7.5 мс. А должен быть заполнен весь интервал. Т.е. это ограничение WCH со всех сторон. И более теоретических 507/0.0075=67600 байт в секунду на данных чипах WCH не...

Влезает и более. В итоге BLE_TX_NUM_EVENT лучше ставить от 12. И как будет работать передача - одним пакетом по 500 байт или кусочками - зависит от многих факторов: 1. Кусочками - если BT адаптер прикидывается что он имеет BT5.0+ и какая ОС + дрова у него. Для всех 99% китайских USB-BT данные...

Для Apple всё совсем плохо с BLE (и многим другим). Это связано с тем, что устанавливаются самые старые адаптеры и из-за слабых процов и малой RAM софт сокращен - всё вырезано и обглодано до предела для сохранения хотя-бы какой производительности.

И для Linux учитывайте, что на сегодня в Bluez имеется только частичная поддержка Core specification 4.2.

По качеству софта и дров для BLE: 1. Для Andriod: от 7.5 мс. Advertising Interval до 10 секунд включительно. Andriod имеет самый быстрый стек и поддерживает все новые стандарты Bluetooth SIG (зависит только от времени выпуска вашего устройства) Для соединения требуется прием одного Advertising...

@il-2 всё, описываемое вами, было учтено изначально. Основными настройками в принципе являются: #define HAL_KEY FALSE // отключить обработку этого события по софт-таймеру (незачем тратить время работы CPU и объем таблицы событий) #define HAL_LED...

WCH написал специальный якобы быстрый стек для WCH (SDK, Sample code) и при этом он проприетарный, точнее не стандарта BLE. И там всего 8000 транзакций в секунду по 20 байт. Этим они хвалятся... :ROFLMAO:

Соответственно подключить акселерометр или какое другое устройство, требующее постоянных коротких прерываний, шинкующее на мелкие кусочки в микросекунды работу данного стека не выйдет. У него сразу тормозит TMOS с событиями, т.к. там сотня килобайтов кода для вызова события стека, хотя RF...

В моем тесте время CPU распределено примерно так: Это при потоке с I2C в ~14 килобайт в секунду. Так шинкуется время CPU прерыванием для обработки чтения 2 байтового регистра по I2C и ещё выполняется функция формирующая заголовки блоков по 250 байт. Этот поток и передается стеку. И на работу...