У меня в другом проекте ESP-IDF отправляю с есп по 75кб сек(240mtu) по БТ и каких-то проблем это не вызывает, да как грузится канал сказать не могу и как это происходит на физическом уровне.. отправлял и в 2,5 раза больше но уже идут потери пакетов на принимающей стороне.. А вот с временными интервалами какая-то беда.
-
Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram
Пример: bluedroid gatts_table_creat_demo отправляет пакеты с задержками.
- Автор темы SAD_sim
- Дата начала
Попробовал и покрутил настройки NimBLE
лучший результат при 60 пакетах в сек:
2 1 6 2 2 1 2 9 2 1 2 7 2 2 1 20 3 6 15 2 23 6 2 19 17 3 2 1 7 77 9 29 3 3 4 1 2 2 8 16 2 17 2 2 2 2 37 3 3 8 3 2 36 3 2 3 25 3 1 2 30 44 7 9 3 9 2 1 2 1 58 6 11 7 2 1 8 1 7 16 2 1 1 27 2 16 2 25 8 15 1 2 20 8 11 6 20 3 6 1 77 15 2 2 1 2 2 1 65 2 22 2 1 30 3 1 4 2 2 2 7 3 3 1 11 3 2 6 28 7 14 2 23 11 1 2 2 32 2 6 2 35 17 2 2 2 18 29 2 6 13 2
лучший результат при 60 пакетах в сек:
2 1 6 2 2 1 2 9 2 1 2 7 2 2 1 20 3 6 15 2 23 6 2 19 17 3 2 1 7 77 9 29 3 3 4 1 2 2 8 16 2 17 2 2 2 2 37 3 3 8 3 2 36 3 2 3 25 3 1 2 30 44 7 9 3 9 2 1 2 1 58 6 11 7 2 1 8 1 7 16 2 1 1 27 2 16 2 25 8 15 1 2 20 8 11 6 20 3 6 1 77 15 2 2 1 2 2 1 65 2 22 2 1 30 3 1 4 2 2 2 7 3 3 1 11 3 2 6 28 7 14 2 23 11 1 2 2 32 2 6 2 35 17 2 2 2 18 29 2 6 13 2
pvvx
Активный участник сообщества
Это и есть случай, когда данные уже подготовлены и CPU занимается только переключением DMA на новый готовый блок и вообще не задействует XIP (кэш SPI-Flash)...
А в случае, когда вы передаете отдельными пакетами с паузами – это совсем другая ситуация. Для такой задачи CPU необходимо обрабатывать расположенные в разных областях код и у него значительно меньше попаданий в кэш программы и данных XIP, т.к. подключаются другие задачи, расположенные в SPI-Flash, а не только процедуры векторов прерываний в IRAM.
А в случае, когда вы передаете отдельными пакетами с паузами – это совсем другая ситуация. Для такой задачи CPU необходимо обрабатывать расположенные в разных областях код и у него значительно меньше попаданий в кэш программы и данных XIP, т.к. подключаются другие задачи, расположенные в SPI-Flash, а не только процедуры векторов прерываний в IRAM.
pvvx
Активный участник сообщества
А на чем вы делаете проверку?
На старых чипах BT4.2 c внутренним буфером на 23 полезных байта для передачи выходит совсем плохо: при минимальном интервале в 7.5 мс такие чипы передают подряд, между интервалом, всего 4 пакета. Так и выходит, что трафик с подтверждением на них чуть больше или равен UART на 115200 Бод. Причина в том, что в такой интервал укладывается максимум 11 полных пакетов с необходимыми интервалами. 4 переданных – 4 принятых за интервал. И такие ограничения часто прописаны в Apple и прочей фигне…
И тут, как и в USB бывает – иногда стоит чип с лейбой USB3.0 и для этого у него буфер вроде на от до 1600 байт. По этому на USB2.0HS мелкими пакетами за один интервал упираемся в размер буфера такого USB хаба. А дальше он создаст прерывание и одно из десятка ядер CPU на пяток ГГц полезет через все уровни системы на это прерывание, на каждом опустошая (сбрасывая) все кеши ядра на мегабайты, и пошлет команды контроллеру PCI, … За сотни мкс может и доползет… Потом опять заляжет или куда ринется, ожидая отложенной отработки команд по шине PCI...
А тупому МCU на это требуется менее десятки наносекунд с переключением банка регистров при входе в прерывание…
На старых чипах BT4.2 c внутренним буфером на 23 полезных байта для передачи выходит совсем плохо: при минимальном интервале в 7.5 мс такие чипы передают подряд, между интервалом, всего 4 пакета. Так и выходит, что трафик с подтверждением на них чуть больше или равен UART на 115200 Бод. Причина в том, что в такой интервал укладывается максимум 11 полных пакетов с необходимыми интервалами. 4 переданных – 4 принятых за интервал. И такие ограничения часто прописаны в Apple и прочей фигне…
И тут, как и в USB бывает – иногда стоит чип с лейбой USB3.0 и для этого у него буфер вроде на от до 1600 байт. По этому на USB2.0HS мелкими пакетами за один интервал упираемся в размер буфера такого USB хаба. А дальше он создаст прерывание и одно из десятка ядер CPU на пяток ГГц полезет через все уровни системы на это прерывание, на каждом опустошая (сбрасывая) все кеши ядра на мегабайты, и пошлет команды контроллеру PCI, … За сотни мкс может и доползет… Потом опять заляжет или куда ринется, ожидая отложенной отработки команд по шине PCI...
А тупому МCU на это требуется менее десятки наносекунд с переключением банка регистров при входе в прерывание…
pvvx
Активный участник сообщества
NanoPi NEO Plus2, Allwinner H5 с четырьмя ядрами Cortex A53, производит 100000 вызов пустой команды fork() примерно за 53 секунды. Т.е. одна команда fork()в Ubuntu выполняется за 537 мкс. При полном кэшировании ядра в памяти - работает в основном блок MMU – СPU там расставляет битики... vfork() почти в 10 раз быстрее.
Но этого всё равно не хватит обслуживать UART 115200 по одному байту тягая их через запуск нового ядра (или просто нового потока)
А так как все современные ОС давно не real-time, то не следует руководствоваться измерением чего либо быстротекущего на них.
Но этого всё равно не хватит обслуживать UART 115200 по одному байту тягая их через запуск нового ядра (или просто нового потока)
А так как все современные ОС давно не real-time, то не следует руководствоваться измерением чего либо быстротекущего на них.
pvvx
Активный участник сообщества
С использованием стандартных средств:
1. При соединении это можно сделать только за счет минимального "интервала соединения". Будет дискретность 7.5 мс
2. При передаче маяка - у меня выходит 3..7 мс от события до декодирования уже на приемной стороне.
Время передачи маяка по трем каналам - 3 мс. Можно принимать по одному...
Тестировалось на чипах TLSR825x.
1. При соединении это можно сделать только за счет минимального "интервала соединения". Будет дискретность 7.5 мс
2. При передаче маяка - у меня выходит 3..7 мс от события до декодирования уже на приемной стороне.
Время передачи маяка по трем каналам - 3 мс. Можно принимать по одному...
Тестировалось на чипах TLSR825x.
pvvx
Активный участник сообщества
Для USB2.0 будет дискретность 1 мс (к hub подключено одно устройство).
Для WiFi - неопределенно: от 1 мс до секунд. При наличии только 1 клиента у AP, чистейшем радио-эфире, и активном соединении возможны дырки на пару мс на время приема-передачи beacon.
Zigbee - сверх зависимость от топологии сети и т.д. Имеет самую большую задержку среди других протоколов.
Для WiFi - неопределенно: от 1 мс до секунд. При наличии только 1 клиента у AP, чистейшем радио-эфире, и активном соединении возможны дырки на пару мс на время приема-передачи beacon.
Zigbee - сверх зависимость от топологии сети и т.д. Имеет самую большую задержку среди других протоколов.
pvvx
Активный участник сообщества
Если разбирать реальную ситуацию с учетом активности в радиоэфире десятков разных типов устройств, то самый качественный стандартный тип связи по параметру минимальной задержки событие-передача-прием-декодирование является BLE. При выпадении нескольких передач всё равно имеем меньшую задержку, чем у других типов RF связи. На других типах при выпадении сигнала или занятости канала задержка уже неопределенно увеличивается. Основная причина - работа на одном канале.