У меня в другом проекте ESP-IDF отправляю с есп по 75кб сек(240mtu) по БТ и каких-то проблем это не вызывает, да как грузится канал сказать не могу и как это происходит на физическом уровне.. отправлял и в 2,5 раза больше но уже идут потери пакетов на принимающей стороне.. А вот с временными интервалами какая-то беда.
-
Уважаемые посетители сайта esp8266.ru!
Мы отказались от размещения рекламы на страницах форума для большего комфорта пользователей.
Вы можете оказать посильную поддержку администрации форума. Данные средства пойдут на оплату услуг облачных провайдеров для сайта esp8266.ru -
Система автоматизации с открытым исходным кодом на базе 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 связи. На других типах при выпадении сигнала или занятости канала задержка уже неопределенно увеличивается. Основная причина - работа на одном канале.