Что за пример использовался? Если \EVT\EXAM\BLE\SpeedTest_Peripheral то я там ничего не понял. Самое качественное что я видел, это библиотека h2zero/NimBLE-Arduino, но она для esp32.
pvvx у тебя есть этот бенчмарк скорости?А то мне надо будет скоро отзыв оставлять,но нужны пруфы бенчмарка ble CH592F.
Там всё не совсем просто.
Как и описывал - можно нагнать больше. Даже в том-же \EVT\EXAM\BLE\SpeedTest_Peripheral:
В зависимости от приемного адаптера имеем: если адаптер согласует работу c блоками BT5.0+, то передача, к примеру, идет по 247 байт. В итоге модифицированный SpeedTest_Peripheral в теории должен дать Max: 247*3/0.0075=98800 bytes/s, но выжимается до ~85000 bytes/s (247x3 блока в интервал 7.5..9 мс) при счете среднего за минуты передачи.
Если взять другой адаптер и он хочет кушать блоки только по 23 байта данных, тогда теор. мax: 23*12/0.0075=36800 bytes/s, а в реале ~30100 bytes/s (12x23)
Это без проверки что он там реально шлет, а чисто счетчик передачи байт.
И теория отличается от практики, т.к. в эфире при тесте есть помехи (у меня тут вблизи работает около ~50 BLE и ~30 Zigbee устройств (система с HA и 3-мя адаптерами BT + Zigbee координатор, плюс WiFi на рядом лежащем телефоне)...
Были подобраны такие настройки в "config.h":
// BLE_BUFF_MAX_LEN = 251
// BLE_BUFF_NUM=12
// BLE_TX_NUM_EVENT=12
При таких параметрах:
APP_MTU_SIZE (BLE_BUFF_MAX_LEN-4)
// Minimum connection interval (units of 1.25ms, 6=7.5ms)
#define DEFAULT_DESIRED_MIN_CONN_INTERVAL 6
// Maximum connection interval (units of 1.25ms, 100=125ms, 10 = 12.5 ms)
#define DEFAULT_DESIRED_MAX_CONN_INTERVAL 8
// Slave latency to use parameter update
#define DEFAULT_DESIRED_SLAVE_LATENCY 0
// Supervision timeout value (units of 10ms, 100=1s)
#define DEFAULT_DESIRED_CONN_TIMEOUT 100
Такие скорости меня устроили, т.к. это в максимуме более 850000 килобит, что есть максимальная норма для PHY 2M и соответствующих настроек.
И решил испытать вариант приема с I2C с CLK на 1.2МГц и посылки данных данных от туда через данный стек...
И тут начались беды... CPU загружен по прерываниям обработки I2C и для исполнения BLE стека остается меньше времени.
Пример осциллограммы опроса I2C
указан тут (но до такого потока уже не довести - стек жрет немерено производительности чипа - не зря там набухали 150 килобайт, да ещё и во Flash с выборкой не за один такт
)
Т.е. чем больше скорость опроса I2C, тем меньше времени остается CPU для обработки BLE стека и на скоростях потока около 10 килобайт в секунду в передаваемых данных наступает бардак - в поток вклиниваются куски от других блоков передач... А если дальше поднимать поток, то там уже сплошной набор из кусков от нормальных блоков которые были переданы в GATT_bm_alloc() с последующим вызовом GATT_Notification().
github.com
