CH582M (СH581, CH582, СH583)

[pvvx]

Если для примера взять INA228 (2.94-MHz high-speed I2C interface), то минимальный шаг оцифровки и опроса у INA228 равен 50 мкс. Т.е. за 50 мкс по минимуму необходимо по I2C два раза выставить номер адреса, номер регистра и прочитать 3 байта данных. На это требуется около 60 тактов CLK I2C (менее 830 нс на один такт CLK) и не менее 20 записей и опросов регистров типа while(бит-регистра = ok) контроллера I2С.
Т.е. CPU будет занят только этой задачей и ничем более (если ещё сможет выставить частоту шины I2C менее 820 нс).
В итоге большинство любимых в народе MCU/SoC в пролете…

Такие вот дела с I2C и SMBus…
По этому ещё в начале этого века были проектированы стандартные ip модели контроллеров I2C... Но всякие STM и т.д. жадятся за каждый транзистор в чипе...

 

[dzanis]

Куда девать входящий поток в CH582/592 ?

Проверить что последние байты идентичны тем , что были отправлены? Я думал просто тест скорости провести. Можно отправлять один и тот-же пакет,с итерацией последних байт для того чтоб понимать номер пакета.
Но тут у меня другая проблема. Настроил и собрал iSLER.c на MRS2 , залил в CH592 и чип постоянно в ребуте. Этот ch32fun настолько оброс дефайнами,что там чёрт ногу сломит. Я понимаю их , что они хотят чтобы их код работал на любом устройстве от wch.Но даже оракул счёл что проще сделать виртуальную машину с которой байт код будет работать на любом устройстве, это проще чем пихать миллион дефайноф в одном файле.
Я к отладке не подключал CH592,пока не знаю где копать. Заливал через usb программой WCHISPTool_CH57x-59x.exe .Отладка просто printf через uart1. В общем летит мусор в uart и всё.

 

[dzanis]

Такие вот дела с I2C и SMBus…

Понятно. А по SPI к INA не подключится?

 

[pvvx]

Понятно. А по SPI к INA не подключится?

INA229 - это SPI. Но имеем почти те-же проблемы.
И INAxxx тут не при чем. Давно есть куча датчиков температуры и влажности с CLK I2С более 1 МГц. А для BLE важно время активности SoC, т.к. это рано потреблению.

 

[pvvx]

Проверить что последние байты идентичны тем , что были отправлены? Я думал просто тест скорости провести. Можно отправлять один и тот-же пакет,с итерацией последних байт для того чтоб понимать номер пакета.

Это не будет тестом для реальных приложений.
Поток данных нужно форматировать и буферизировать. Это работа CPU с неким шагом, который можно вызывать через событие в TMOS.
Но данные нужно отправлять в какой-то интерфейс - типично это делается по прерываниям.
И тут сразу неизвестность в приоритетах прерываний и вообще схеме прерываний используемых в TMOS.
Т.е. для теста нужно отнимать время работы у CPU, к примеру через прерывание таймера, и смотреть что на это скажет TMOS и стек BLE.

Но тут у меня другая проблема. Настроил и собрал iSLER.c на MRS2 , залил в CH592 и чип постоянно в ребуте. Этот ch32fun настолько оброс дефайнами,что там чёрт ногу сломит. Я понимаю их , что они хотят чтобы их код работал на любом устройстве от wch.Но даже оракул счёл что проще сделать виртуальную машину с которой байт код будет работать на любом устройстве, это проще чем пихать миллион дефайноф в одном файле.

Я и не лезу в это скопление. Так как для каждой задачи требуется своя оптимизация и алгоритмы. Универсального решения для таких тупых чипов не бывает. А там хотят сделать очередное Arduino... и послал разбираться с этой кашей https://github.com/biemster в одиночку
И у них задача простая - сделать урезанный Apple FindMy - это передача маяков раз несколько секунд.

 

[pvvx]

Add ch582 firmware · Issue #28 · pvvx/ADV_BLE2UART

CH582 is possibly the cheapest solution here, with complete modules well below 80RUB or 1EUR/USD (https://vi.aliexpress.com/item/1005008586545355.html for example). Are you interested in expanding ...

github.com

 

[pvvx]

На сегодня итог с CH582F такой:
Не тянет опрос I2C и передачу более 9 килобайт, а менее – запросто и благополучно.

Для теста был изменен вызов GATT_Notification() на GATT_Indication().
Разница в том, что GATT_Indication() требует обязательного подтверждения передачи приемником.
И при превышении 9 килобайт сообщает об ошибке передачи...
Какую из функций использовать – без разницы – итог одинаков.

Тестовая прога с INA226 на 8000 байт в секунду (опрос INA226 в 250 мкс):

Всё без проблем на таком трафике.

Спойлер: Лог с CH582F

CH58x_BLE_LIB_V2.13
I2C: Set default CFG
Initialized..
Advertising..
Scan req from f4 4e fc bf aa 91 (запрос активного сканирования внешним адаптером - запрашивает имя устрйоства)
Scan req from f4 4e fc bf aa 91 (дубль запроса)
Conn1: 48, 0, 960  (запрос соединение с адаптера, с его хотелками интервалов)
Connected.. (соединение)
MTU exchange: 507 (изменяем размер MTU)
CurMTU = 507:507 (проверка что говорит стек WCH о своем MTU и MTU адаптера)
ExchangeMTU(494): 2 (затесавшийся тест: команда изменения MTU возвращает ошибку  номер 2, т.к. она только для мастера)
PHY Update 0… (посылка запроса изменения PHY для соединения номер 0)
Update conn1 : 7, 0, 50 (переназначение интервалов соединения)
PHY update Rx:2 Tx:2 ..  (согласовал PHY 2MHz на TX и RX)
(далее команды идентификации устройства и конфигурации I2C и INA226)
cmd[2]: 00,00  
cmd[40]: 26,01,00,00,50,c3,e8,03,80,00,ff,07,00,00,00,00,00,00,00,00,00,00,00,00,80,01,80,02,80,01,80,02,80,00,00,00,00,00,00,00
cmd[3]: 01,40,01
cmd[4]: 02,10,80,fe
cmd[13]: 0b,01,74,00,fa,00,dc,05,80,00,4f,00,00 (старт потока с заданными параметрами)
(далее молча гонит поток, т.к. производительности и так не хватает)

Диаграммы приема на СВЧ диод рядом с модулем для контроля кто и когда передает (клетка 5 мс):

Если внешний адаптер умеет играть в BT5.0+:


Если внешний адаптер прикидывается в поддержку BT5.0+ (передача идет мелкими блочками по 9 шт, стеку указано до 12):


Импульсы малой амплитуды - передачи внешнего адаптера, большой амплитуды - это CH582F.

Аналогичное поведение наблюдается на 7 проверенных USB-BT и PCI-BT адаптерах. Кто кусками, кто целыми блоками по MTU…

По всевозможным issue в Windows Web Bluetooth API нет команды запроса установки MTU. Отнекиваются тем, что якобы windows при соединении сама устанавливает максимальный MTU. Но по реальному поведению видно, что это не совсем так - гарантированно имеющий размер внутреннего буфера приемника-передатчика адаптер с BT5.0+ вдруг начинает работать с блоками 2x байта...

 

[pvvx]

В этой-же прошивке работает и USB и там всё нормально до пределов INA226 (опрос в 140 мкс):

На вход дана пила с генератора...
То есть получить гальваническую развязку PowerProfiler-у через BLE с CH582 не выйдет...

 

[pvvx]

При работе стека у USB не хватает производительности для обслуживания потока с I2С более 20 килобайт в секунду.
При увеличении частоты CPU с 60 на 80 МГц, получаем пропорциональную прибавку ограничения в USB и BLE.

Т.е. тормоз создает сам стек – ему не хватает времени, остающегося от работы прерывания обслуживающего I2C. При этом USB без запущенного стека запросто перелопачивает к сотне килобайт в секунду от I2C или за 600 килобайт в секунду при тусовке через двойные буфера, с формированием заголовков блоков передачи от встроенного ADC...

На этом можно заканчивать с CH58x/592. Будет второй тормозной чип – первый с совершенно идентичным BLE стеком = РНY62xx/ST17H6x. На нем аналогично не удалось обрабатывать прием OTA данных на полную скорость, хотя-бы в половину от TLSR825x…

 

[pvvx]

Если обратиться к документации:

6.6 Ограничение обработки приложения во время работы Bluetooth Low Energy

Из-за временной зависимости протокола Bluetooth Low Energy контроллер должен обрабатывать каждое событие соединения или событие трансляции до его поступления. Несвоевременная обработка приведет к повторной передаче или отключению.

TOMS не является многопоточным, поэтому при наличии транзакций Bluetooth Low Energy другие задачи должны быть остановлены для обработки контроллером. Поэтому следите за тем, чтобы не занимать слишком много событий в приложении. Если требуется сложная обработка, обратитесь к разделу 3.3, чтобы разбить её на части.

3.3 События задач и их выполнение

Планирование TMOS осуществляется посредством опроса. Системные часы обычно берутся из RTC, а единица измерения — 625 мкс. Пользователи добавляют настраиваемые события в список задач TMOS, регистрируя задачи, а затем TMOS планирует и запускает их…..

Всё это соблюдено. Кроме прерывания, которое должно отрабатывать постоянно для чтения шины по I2C с мелким интервалом.
Т.е. данное описание работы стека в CH58x/59x гласит, что стек у WCH, скопированный из какой-то общей кормушки (наверно древний nRF) вышел сверх тормознутым и занимать время CPU во время его работы незя.

Для этого WCH прилагает вариант примеров 8K_PollingRateWirelessMouse с libCH59xRF_FAST.a и другими библиотеками стека… Это те примеры с исходниками, которые ищет @selevo:

 

[dzanis]

На этом можно заканчивать с CH58x/592.

pvvx, спасибо за труды и эксперименты! Пока WCH гордо пишет в даташите про 2 Мбит/с, мы имеем честные 9 КБ/с. В мегабитах это выглядит ещё печальнее, стыдно перед dial-up из 90-х . Но благодаря тебе хотя бы знаем реальность, а не маркетинг.
Правда, остаётся вопрос: куда вообще пристроить столь тормознутый BLE? Музыку не послушаешь, самый пережатый кодек не потянет, разве что midi. Файлы логов, максимум передавать сохранения небольшие, на большее терпения не хватит. В общем, ble на ch5xx явно не для скорости, а для медитативного общения байтов в стиле дзен.