CH582M (СH581, CH582, СH583)

[pvvx]

GitHub - pvvx/SimplePowerProfiler: Simple PowerProfiler on INA219, INA226, INA231, INA3221, INA228

Simple PowerProfiler on INA219, INA226, INA231, INA3221, INA228 - pvvx/SimplePowerProfiler

github.com

 

[pvvx]

У CH582/CH583/CH592 в BLE firmware предоставленном WCH существуют проблемы.

Пропускная способность (функций Notify()) имеет множество ограничений.

Даже при PHY 2M после изменения файла конфигурации (увеличения до пределов блоков данных и объема памяти для BLE стека) нет возможности достичь передачи данных более десятка килобайт в секунду. При превышении возникают баги – дублирующиеся блоки и пропуски.

Поток можно разогнать и боле десятка килобайт в секунду, но с багами. Китайцы…

 

[pvvx]

Наверно по этому, к примеру, в примерах \EVT\EXAM\BLE\SpeedTest_Peripheral, вызов передачи блока производится раз в час. Такие вот китайцы и их blob BLE стека для данных чипов…
Своровали и сами не знают что, и для примера теста производительности накрутили бреда…
В ROM вообще полный бардак, а патч в бинарном виде BLE стека занимает к 150 килобайт.

 

[pvvx]

Наверно именно из-за этого данные чипы были выкинуты на али по себестоимости печатной платы. Аналогично ESP8266... Но у ESP8266 толпа аппаратных багов и тупонин первый нанятый программист-дошкольник (жадность конторы) , а тут soft баги.

 

[pvvx]

В итого в blob библиотеке BLE нет стандартных и всем необходимым функций. К примеру запроса изменения MTU у клиента.

OTA вообще написано лишь-бы отвязались. Функционал OTA построен на примитивах записи запросов-ответов записи, стирания, верификации блока Flash.

То есть всё это, чтобы создать более-менее нормальный продукт, необходимо переделывать с нуля. Но исходников BLE либы WCH не дают.

От этого бардака готовых массовых продуктов на данных чипах нет и пока не привидится. Что и наблюдается. Видимо в маркетинге WCH полные дебилы.

 

[pvvx]

Как ныне принято описывать – Как тебе такое Илон Макс, что предложенные функции в SDK используют запрет прерываний на десятку ms как пинг будущего бесплатного интернет для всех в Старлинк, объявленного Илоном для запуска на начало 2026 года для обрушения местячковых запретов в некоторых странах, с ценой “тарелки-приемника” до $20 и рассылкой даже бесплатно в качестве гуманитарной помощи в некоторые отсталые страны?

 

[pvvx]

Пример, что максимально может предоставить blob либа WCH для данных чипов по трансферу:

(прием на СВЧ диод радом с антенной)
Т.е., при связи с Windows, и адаптеру с BT5.0+, при максимуме размера MTU для WCH, передача идет до 5-ти блоков. И минимальный интервал соединения равен 7.5 мс (стандарт Bluetooth SiG – менее незя, у Apple свой стандарт и незя менее 10 ms). И множестве ухищрений, но до патча bloob либ.

Это типа до 125 блоков в секунду до 250 байт. Теор.расчет с такими показаниями дает всего до 32000 байт в сек. А реальная норма для BLE PHY 2M для нормальных чипов распространяется за 60000 килобайт в секунду (более 600 килобит при радио 2 мегабита).

Но и эти теор.значения в WCH ПО уже натыкаются на баги ...

 

[dzanis]

WCH, похоже, настолько не умеют на C программировать, что решили ble стек сразу в бинарниках писать , чтобы никто не догадался, что там внутри вообще не код, а набор goto и while(1)
А я уже заказал CH582F и CH592F. Теперь только остаётся использовать их вместо подставки под паяльник…Или может развернуть их на пол пути.
В общем заказал их поиграться, хобби у меня такое. А mp3 до 128 Kb/s можно передавать на этих чипах?
По силам аналоговый сигнал с микрофона кодировать в mp3 и отсылать на лету?

 

[pvvx]

У меня, с чем помучался и пока не решено, CPU занят на более 50% моей задачей стабильно и мелкими вызовами по прерыванию таймера. То есть очень мелко нарезает работу BLE с шагом в сотни мкс и длительностью до 50 мкс – типа понизили частоту CPU. Осел не находит джиттера обработки этого прерывания на более пары мкс.

Остальное время отдано стеку BLE. В конфигурации указывал до 16 блоков передачи за раз и увеличенный объем памяти для стека и т.д. в предел размера RAM чипа...

При превышении порога около 10 килобайт в секунду начинают наблюдаться редкие артефакты в виде дублей кусков кода в блоке передачи. Процесс стихийный, наверняка связан с дублированием передачи, если не прошло подтверждение приема и идет полная загрузка по производительности чипа. Выловить причину сложно – лень лезть так глубоко в blob либу стека…

Предел потока передачи сильно зависит от приемного BT адаптера. Разница может достигать более 5 раз. Т.е. чип может передать и 60 килобайт в секунду, но что там будет в этом потоке - я не проверял.
Но с моей задачей стабильность сохраняется до 10 килобайт в секунду с разными адаптерами. Тут зависимость от адаптера минимальна - десяток %.

В SDK существует единственный алгоритм вызова процедуры передачи данных через Notify() и вашей обработки чего-либо только через события TMOS. Код менеджера памяти закрыт, как там и что наслаивается и распределяется при максимальной загрузке – неизвестно. Но похоже там и закралась лажа…

 

[pvvx]

Эту же задачу делал на других чипах. Там всё в норме до пределов сколько может принять внешний адаптер и следующие проблемы уже только в ОС, на которых установлен данный адаптер BT.

Худшие OC для BLE по производительности как всегда – Linux, все Apply, далее идет Windows. А в Android всё, что связано с BLE не вызывает никаких проблем.

Дык чипы BLE с более низкой производительностью CPU без проблем справляются гнать потоки за 60 килобайт в сек, даже если отнять 60..80% времени работы этих CPU.

Но с CH582/592 какая-то лажa, хотя у его CPU есть "WCH-Interrupt-fast", который действительно Fast. Т.е. аппаратно он круче, но ...

 

[pvvx]

Популярное описание что необходимо для получения максимального потока в BLE:
Источник <https://www.novelbits.io/bluetooth-5-speed-maximum-throughput/>

Оптимизация для максимальной пропускной способности данных

Основываясь на факторах, которые мы рассмотрели, мы можем отметить следующее при оптимизации для высокой пропускной способности данных:

Всегда включайте DLE.
Очевидно, что если вы используете Bluetooth v4.1 или более ранней версии, это недопустимый вариант. В целом, однако, убедитесь, что вы включили DLE, чтобы максимизировать эффективность передачи данных от пакета к приложению.

Используйте LE 2M PHY
Если вы знаете, что устройства на обоих концах поддерживают Bluetooth 5, то использование LE 2M PHY - один из лучших способов максимизировать пропускную способность данных вашего приложения. Использование LE 2M PHY также поможет снизить энергопотребление, так что вы попадете в двух зайцев одним выстрелом!

Используйте уведомления и записи без ответов.
Их использование поможет удалить все ненужные передаваемые пакеты (по сравнению с индикациями и обычными записями, которые требуют, чтобы принимающая сторона подтверждала каждый полученный пакет).

Выберите значение ATT MTU не менее 247 байтов.
Это позволит минимизировать любые накладные расходы в байтах пакета.

Выберите интервал соединения, который учитывает максимальное количество пакетов на интервал соединения.
Но помните, что интервал соединения влияет на энергопотребление. Чем короче интервал, тем больше энергии будет потреблять ваше устройство из-за увеличения времени включения радио. Вы также должны убедиться, что вы не выбрали слишком большой интервал, в противном случае это поставит под угрозу взаимодействие с пользователем (более высокий интервал подключения приводит к более высокой задержке). И последнее, что необходимо учитывать, - это любые ограничения устройств в вашей системе с точки зрения максимального количества пакетов на поддерживаемый интервал подключения.

-------

Случай 6 (PHY: 2 Мбит / с, ATT MTU = 247 байт, DLE: включен, интервал соединения: 400 миллисекунд)
Пропускная способность данных, сообщаемая прошивкой:
Время: прошло 6,11 секунды.
Пропускная способность: 1371,82 Кбит / с.
Отправлено 1048712 байт полезной нагрузки ATT.
Расчетная пропускная способность данных:
Время передачи пакета данных = размер пакета данных / скорость необработанных данных = 2 + 4 + 2 + 4 + 247 + 3 байта / 2 Мбит / с = 262 * 8 бит / 2 Мбит / с = 1048 микросекунд
Data_Packet_Time = время передачи пустого пакета + IFS + время передачи фактического пакета данных + IFS = 44 + 150 + 1048 + 150 микросекунд = 1392 микросекунды
Максимальное количество пакетов данных на интервал подключения = [интервал подключения / Data_Packet_Time] = [400 миллисекунд / 1392 микросекунды] = [287,36] = 287 пакетов
Общее количество данных, переданных за интервал подключения = 287 * 244 байта = 287 * 244 * 8 бит = 560224 бит
Пропускная способность = Общее количество данных, переданных за интервал подключения / интервал подключения = 560224 бит / 400 миллисекунд = 1400,56 Кбит / с

 

[pvvx]

CH582/592 в большинстве случаев (и зависит от приемного адаптера) переходит на работу в формате BT4.2 c размером пакета в 27/20 пользовательских байт. В файле конфигурации есть возможность задать количество пакетов передаваемых за раз (между интервалом соединения), и общий объем в кол-ве пакетов для разметки памяти.

Но в итого выходит, что передача между интервалами ограничена этими мелкими нарезками по 27/20 байт, а не нормальным пакетом BT5.0 в размер MTU (к примеру в 251 байт).

В итоге приходится ставить минимально возможный интервал – 7.5 ms и CH582 передает MTU этими мелкими блоками – 27+20+20+20+20… байт и ограниченным числом. Для совместимости с разными адаптерами желательно ограничивать кол-во таких пакетов до 5. В итоге выходит, что за интервал соединения передается только 27+20+20+20+20=107 байт полезной информации.

В большинстве вариантов внешних адаптеров, отработает и большее кол-во этих мелких пакетиков за интервал (в установленный объем MTU) до полного заполнения “интервала соединения” (аналогично ситуации с USB2.0FS).
В сообщении выше и дана картинка RF передачи с ограничением в 5 пакетиков...
Если подвинуть антенну приемного адаптера, то перед каждым пакетиком будет короткий импульс подтверждения от приемного адаптера...

 

[pvvx]

Но в RF сети существуют помехи и коллизии с другими устройствами 2.4ГГц. В итоге, не получив подтверждения передающий дублирует пакет. И где-то в этой ситуации у CH5xx и возникает лажа…

 

[pvvx]

В примерах от WCH перед вызовом Notify() производится закидывание блока в диспетчер памяти TMOS. После отработки функции – освобождение этого куска памяти, в независимости от ошибки Notify(). При запросе памяти задаются всякие дескрипторы, и с ними вызывается и освобождение памяти. Не копано только то, что функция Notify() урезана или с лажей – при неуспешном подтверждении приема не выдает ошибки, а память освобождается и занимается новым пакетом, пока идет дублирование передачи неподтвержденного пакета. Это предположение, но уже лень ковырять это…

 

[DiFroll]

Всем доброго времени суток. Люди, хочется услышать ваше мнение. Выпустят они регистра беспроводного интерфейса или нет?

 

[pvvx]

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

 

[pvvx]

Всем доброго времени суток. Люди, хочется услышать ваше мнение. Выпустят они регистра беспроводного интерфейса или нет?

Хто такой "регистра беспроводного интерфейса"?

 

[pvvx]

Всем доброго времени суток. Люди, хочется услышать ваше мнение. Выпустят они регистра беспроводного интерфейса или нет?

"регистра" - это регистратор? BLE cниффер?

Для Windows на любом BT адаптере:
Bluetooth Virtual Sniffer btvs.exe
https://learn.microsoft.com/en-us/windows-hardware/drivers/bluetooth/testing-btp-tools-btvs

 

[dzanis]

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

Спасибо за столь интересное описание. Но это надо не сюда плакать, каким-то редким прохожим, а идти прямо к начальству. Накатать им в issue на git про эту проблему. А то они думают раз все молчат то и проблем с их кодом не существует. Один только pvvx эту проблему нашёл на весь китай. Это не удивительно, чипом мало кто интересуется, хоть и CH5xx несколько лет в релизе, и али им завален за копейки. А 582F так вообще меньше доллара за дев боард. Но очень скудно про эти бле статей и видео в интернете. Ну заказал уже,что делать.Как прочитал на хаюре , что CH592 настолько мало жрёт от 1.7v ,что его можно сделать "дожирателем батареек AA "