• Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram

CH582M (СH581, CH582, СH583)

pvvx

Активный участник сообщества
@pecherskih - Наиболее востребованная функциональность в ближайшее время (PAwR) описана в "Periodic Advertising with Responses (PAwR)", "Encrypted Advertising Data".
Как это реализовать на WCH? Есть какие подсказки (?), а то копал и ничего, не нашел даже релиза функций уровня nRF ESB :cry: (Для Telink и прочих есть. Т.к. любой SDK базируется на функциях типа rf_start_rx2tx()/rf_start_tx2rx() c указанием временной диаграммы передачи, паузы и окна приема. Частоты, модуляция и кол-во повторов обычно задается предварительно другими функциями)

PAwR - это закат Zigbee и Mesh, конец использования их в бытовухе...
 

pecherskih

Member
Немного об ошибках в документации :) В описании CH583DS1 на кристаллы WCH в разных версиях документа есть существенные отличия :)
Вот что написано на первой странице даташита перед таблицей в разных версиях:

v1.3
Compared with CH582, CH583 contains SPI1 master and 512KB Flash for data storage and code backup. CH583 supports minimum 1.7V power supply.
v1.7
Compared with CH582, CH583 adds SPI1 master and supports power supply down to 1.7V.

Т.е в версии 1.3 указывалось, что СН583 содержит 512KB Flash, а в таблице ниже указывается размер 544КВ. Я так понял что это дополнительные 512KB Flash, т.к. 544к = 512к(дополнит.) + 32к(основная). В версии 1.7 этой строчки уже нет. Наверное всё таки в ранней версии была опечатка. Вставлять огромную EEPROM я просто не вижу смысла.
13.png17.png
 

cryptozoy

Member
Wireless mode requires 2 WCH-LinkW, divided into WCH-LinkW master (connected to computer) and WCH-
LinkW slave (connected to MCU.) After WCH-LinkW is successfully enumerated to computer, it will detect
whether there is a slave match within 2 seconds to switch mode, if there is a slave match, it will switch to
wireless mode, and the green light will be on; otherwise, it will switch to wired mode, and the green light goes
off.

Беспроводной режим требует два WCH-LinkW: ведущий (master), подключённый к компьютеру; ведомый (slave), подключённый к отлаживаемому микроконтроллеру. После успешного подключения к компьютеру ведущий WCH-LinkW в течение двух секунд определит, есть ли сопряжение с ведомым WCH-LinkW, и если есть, то переключится в беспроводной режим и загорится зелёный индикатор; в противном случае он переключится в проводной режим и зелёный индикатор погаснет.
 

pvvx

Активный участник сообщества
Что-то нигде не найти SDK или ещё чего для CH32V208 с Zigbee. Аппаратных ограничений у чипа для реализации Zigbee 3.0 нет, т.к. писано что он BT5.3. Flash маловат, но уместить типичное End-Device достаточно.

Кто видел оф. описание характеристик уровней приема чипов WCH в разных PHY?
 

pvvx

Активный участник сообщества
В "SDK" есть PAwR_ADV и PAwR_RSP.
Это реализация BT5.4 ? Если да, то Zigbee более не нужен.
PAwR превращает периодическую рекламу в режим двунаправленной связи.
 

cryptozoy

Member
В "SDK" есть PAwR_ADV и PAwR_RSP.
Это реализация BT5.4 ? Если да, то Zigbee более не нужен.
PAwR превращает периодическую рекламу в режим двунаправленной связи.
В спецификации 5.3 нет такого функционала. Появился впервые для LE в 5.4.

Описание применения PAwR от Nordic Semiconductor: https://devzone.nordicsemi.com/guid...rtising-with-responses-pawr-a-practical-guide
 

pvvx

Активный участник сообщества
Это чисто программное дополнение и может быть реализовано на чипе соответствующем Bluetoth 5.0 или "необязательным" дополнениям ещё в стандарте версии 4.2 (2014 год).
 

pvvx

Активный участник сообщества
При трансляции PAwR в Coded PHY S8, разрешенному ещё в стандарте BT5.0 для передачи рекламы, дальность связи увеличивается в 2 раза по сравнению с Zigbee, если использовать одинаковый уровень RF TX в дБм.
PAwR - это просто аналог BLE-MESH, с немного другой реализацией кодирования RF фреймов.
И включая введение стандарта шифрования рекламы в BT5.4, Zigbee выходит полностью в пролете.
Заголовок BLE рекламы передается по 3-м каналам, а Zigbee использует один канал. Это ещё дополнительное преимущество в помехозащищённости.
А прыжки при связи по каналам в BLE дают ещё дополнительные преимущества...
 

pvvx

Активный участник сообщества
Для полной поддержки новых стандартов BLE сам чип должен уметь или иметь:
1. выводы для переключения антенн
2. более точный анализ RSSI
Это нужно исключительно для ненужной функции AoA/AoD :)
Всё остальное = программная реализация.

При переходе от BT4 к BT5:
1. Размер буфера RF
2. Разные PHY
3. Уровни приема и передачи.
 

il-2

New member
У меня в ходе вгрызания в стандарт BLE и работы с CH58x возник вопрос - по Notification (и Indication)
В стандарте написано, что для поддержки Notification надо выставить соответствующий бит в Characteristic Properties.
Однако в описании процедуры Notification GATT-профиля упоминается еще Client Characteristic Configuration descriptor - это необязательный дескриптор характеристики, который клиент может писать и читать, чтобы управлять Notification и Indication. В библиотечных примерах у китайцев он реализован. У меня собственно вопрос - этот дескриптор необходим? Если я его не реализую, то не имею право высылать Notification и Indication?
 

pvvx

Активный участник сообщества
Если я его не реализую, то не имею право высылать Notification и Indication?
Это зависит от SDK. Он может посылать или нет Notification и Indication в зависимости от своих китайских предпочтений.
Ещё разница бывает в флагах GATT_PROP_READ | GATT_PROP_WRITE_NO_RSP | GATT_PROP_NOTIFY. Если добавить GATT_PROP_WRITE, то будет отрабатывать response по усмотрению адаптера :)
И тоже зависит от реализации в конкретном SDK.
Что-то реализация в WCH SDK очень похожа на PHY SDK. Но PHY мы тут уже раскрутили на исходники болобов и теперь можно всё менять...
 

il-2

New member
Это зависит от SDK. Он может посылать или нет Notification и Indication в зависимости от своих китайских предпочтений.
Ещё разница бывает в флагах GATT_PROP_READ | GATT_PROP_WRITE_NO_RSP | GATT_PROP_NOTIFY. Если добавить GATT_PROP_WRITE, то будет отрабатывать response по усмотрению адаптера :)
И тоже зависит от реализации в конкретном SDK.
Что-то реализация в WCH SDK очень похожа на PHY SDK. Но PHY мы тут уже раскрутили на исходники болобов и теперь можно всё менять...
Спасибо. У китайцев в примерах реализован Client Characteristic Configuration descriptor. Так-же в своих примерах они используют 2 функции - GATTServApp_InitCharCfg и GATTServApp_ReadCharCfg для инициализации и чтения значений этого дескриптора. Функция записи GATTServApp_WriteCharCfg в примерах не используется. Либо китайцы чего-то не доделали в своих примерах, либо библиотека это делает сама.

Но фиг с ними - и с китайцами, и с их библиотеками. Вопрос у меня все-таки остался - что говорит стандарт о необходимости иметь Client Characteristic Configuration descriptor для выдачи нотификаций и индикаций??? Там как-то непонятно написано. Вроде бы он нужен, чтобы клиент мог управлять нотификациями и индикациями, и в то-же время сказано - что он необязателен.
 

pecherskih

Member
Спасибо. У китайцев в примерах реализован Client Characteristic Configuration descriptor. Так-же в своих примерах они используют 2 функции - GATTServApp_InitCharCfg и GATTServApp_ReadCharCfg для инициализации и чтения значений этого дескриптора. Функция записи GATTServApp_WriteCharCfg в примерах не используется. Либо китайцы чего-то не доделали в своих примерах, либо библиотека это делает сама.

Но фиг с ними - и с китайцами, и с их библиотеками. Вопрос у меня все-таки остался - что говорит стандарт о необходимости иметь Client Characteristic Configuration descriptor для выдачи нотификаций и индикаций??? Там как-то непонятно написано. Вроде бы он нужен, чтобы клиент мог управлять нотификациями и индикациями, и в то-же время сказано - что он необязателен.
Добрый день. Напишу своё видение этого вопроса. Я согласен с pvvx в том, что многое зависит от конкретной реализации SDK. Давайте взглянем на этот вопрос с физической стороны. Что такое подпись на нотификацию? Это разрешение серверу ( чаще всего датчику ) отправлять клиенту ( чаще всего смартфон) сообщения об изменении параметра САМОСТОЯТЕЛЬНО. Т.е. без запроса со стороны самого клиента. Но что происходит на физическом уровне? После того как клиент увидел сервер в режиме advertising-а и присоединил его, у нас на рабочих каналах регулярно происходит запрос-ответ между клиентом (мастер) и сервером (slave). Т.е. что бы поддерживать связь, два устройства выходят в эфир и обмениваются друг с другом пакетами, чаще всего пустыми. Это физический уровень. Он нужен для поддержания связи. Если смартфону (мастер) надо передать запрос на датчик (slave) пакет от смартфона будет уже не пустым. Это запрос имеет свойства GATT_PROP_WRITE_NO_RSP или GATT_PROP_WRITE. В последнем случае датчик (slave) формирует ответ на запрос и через некоторое время передает его обратно. Но работать по запросу не всегда удобно, поэтому если подписаться на нотификацию, то датчик сам может посылать не пустой пакет смартфону (мастеру) на его пустой пакет. Вот здесь и кроются нюансы. Объясню. Что бы обратный пакет был принят, необходимо, что бы slave готов был его отправлять (был такой механизм у него, функции прописаны, выделены буферы и прочее), а master готов был его принимать (то же что бы был механизм). Поэтому когда делается подпись на нотификацию, master подготавливает механизм приема (если он ранее не был подготовлен), а затем отправляет команду на slave, что бы и он включил у себя механизм передачи без запроса. Так говорит теория. В жизни же всё может быть немного по другому. У slave как правило нет двух отдельных механизмов ответа - с запросом и самостоятельно (нотификация), как и у master нет двух разных механизмов приема. Различие только в заголовках пакетов. Через эти заголовки мы можем понять что это - ответ на запрос или нотификация. Что в большинстве случаев всё равно. Дальше обработка одинакова. Вам, к примеру, без разницы как градусник прислал температуру, по запросу или самостоятельно, обработка далее будет одинаковой. Поэтому эта игра в нотификацию часто условна., поэтому и пишут что Client Characteristic Configuration descriptor - это необязательный дескриптор . Я на одном из своих изделий WCH сделал отправку нотификации по нажатию кнопки, но при этом не делал никакой обработки подписи на нотификацию. Т.е. считаю что она сделана по-умолчанию. При открытии на телефоне программы nRF Connect и присоединении к телефону моего девайса, я могу отправлять на телефон уведомление о нажатии кнопки. И программа nRF Connect видит эти уведомления, хотя подпись на нотификацию не активна. Однако я встречал в своей практике случаи, когда без подписи на нотификацию, сама нотификация не работала. Так что повторюсь, как сказал pvvx это во многом зависит от конкретной реализаwии SDK. Посмотри мои 2 статьи на Хабре на тему GATT, там то же об этом я писал. https://habr.com/ru/articles/505078/ https://habr.com/ru/articles/735162/
 

pvvx

Активный участник сообщества
Со стороны клиента, чтобы отрабатывать прием конкретной характеристики, необходимо подписаться на неё. Это организует типа callback (Notify) в вашем приложении, куда будут приходить все данные от этой характеристики. Но можно принудительно запрашивать чтение характеристики, не подписываясь, т.е. не организуя специальный callback.

Но если уже произведена подпись на характеристику и организован callback (Notify), то и функция чтения выдаст данные в ответе её запроса и эти данные будут получены одновременно и в callback (Notify).

Т.е. это всё чисто программная реализация на верхнем уровне.
 

pvvx

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

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

pvvx

Активный участник сообщества
Т.е. включенный дескриптор Notify используется как уведомление мастеру, что клиент принимает данные этой характеристики. И есть возможность отключить поток этих данных, к примеру, чтобы не забивать общий трафик соединения… Но сообщения об ошибках мастер может и послать без включенного Notify и без гарантии приема клиентом (на верхнем уровне программ)…
Т.е. это всё верхний уровень реализации ПО. Уровень API.
А как известно, API в Linux для BT5.0 нет - не существует уже с 2014 года и не предвидится.
 

pvvx

Активный участник сообщества
В итоге есть Notification и Indication.
Indication не должен смотреть на включенный флаг Notify.
 
Сверху Снизу