Auteur：TorchIoTBootCamp
Lien：https://zhuanlan.zhihu.com/p/339700391
De：Quora
1. Présentation
Silicon Labs a proposé une solution hôte + NCP pour la conception de passerelle Zigbee. Dans cette architecture, l'hôte peut communiquer avec le NCP via l'interface UART ou SPI. Le plus souvent, UART est utilisé car il est beaucoup plus simple que SPI.
Silicon Labs a également fourni un exemple de projet pour le programme hôte, qui est l'exempleZ3GatewayHôte. L'exemple s'exécute sur un système de type Unix. Certains clients voudront peut-être un exemple d'hôte pouvant s'exécuter sur un RTOS, mais malheureusement, il n'existe pas d'exemple d'hôte basé sur RTOS pour le moment. Les utilisateurs doivent développer leur propre programme hôte basé sur RTOS.
Il est important de comprendre le protocole de passerelle UART avant de développer un programme hôte personnalisé. Pour les NCP basés sur UART et SPI, l'hôte utilise le protocole EZSP pour communiquer avec le NCP.EZSPest l'abréviation deProtocole série EmberZnet, et il est défini dansUG100. Pour le NCP basé sur UART, un protocole de couche inférieure est implémenté pour transporter les données EZSP de manière fiable via UART.CENDREprotocole, abréviation deHôte série asynchrone. Pour plus de détails sur ASH, veuillez vous référer àUG101etUG115.
La relation entre EZSP et ASH peut être illustrée par le schéma suivant :
Le format des données de l'EZSP et du protocole ASH peut être illustré par le schéma suivant :
Dans cette page, nous présenterons le processus de cadrage des données UART et certaines images clés fréquemment utilisées dans la passerelle Zigbee.
2. Cadrage
Le processus général de cadrage peut être illustré par le graphique suivant :
Dans ce graphique, les données désignent le cadre EZSP. En général, les processus de cadrage sont : |Non|Étape|Référence|
|:-|:-|:-|
|1|Remplissez le cadre EZSP|UG100|
|2|Randomisation des données|Section 4.3 de UG101|
|3|Ajoutez l'octet de contrôle|Chap2 et Chap3 de UG101|
|4|Calculer le CRC|Section 2.3 de l'UG101|
|5|Byte Stuffing|Section 4.2 de UG101|
|6|Ajouter l'indicateur de fin|Section 2.4 de UG101|
2.1. Remplissez le cadre EZSP
Le format de trame EZSP est illustré au chapitre 3 de l'UG100.
Attention, ce format peut changer lors de la mise à niveau du SDK. Lorsque le format change, nous lui attribuerons un nouveau numéro de version. Le dernier numéro de version d'EZSP est 8 au moment de la rédaction de cet article (EmberZnet 6.8).
Comme le format de trame EZSP peut être différent entre les différentes versions, il existe une exigence obligatoire que l'hôte et le NCPDOITtravailler avec la même version EZSP. Sinon, ils ne peuvent pas communiquer comme prévu.
Pour y parvenir, la première commande entre l'hôte et le NCP doit être la commande de version. En d'autres termes, l'hôte doit récupérer la version EZSP du NCP avant toute autre communication. Si la version EZSP est différente de la version EZSP du côté hôte, la communication doit être interrompue.
L'exigence implicite derrière cela est que le format de la commande version puisseNE JAMAIS CHANGER. Le format de commande de la version EZSP est le suivant :
Description : https://zhuanlan.zhihu.com/p/339700391
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
2.2. Randomisation des données
Le processus de randomisation détaillé est décrit dans la section 4.3 de l'UG101. L'ensemble du cadre EZSP sera randomisé. La randomisation consiste à effectuer un OU exclusif sur la trame EZSP et une séquence pseudo-aléatoire.
Vous trouverez ci-dessous l'algorithme de génération de la séquence pseudo-aléatoire.
- rand0 = 0×42
- si le bit 0 de randi est 0, randi+1 = randi >> 1
- si le bit 0 de randi est 1, randi+1 = (randi >> 1) ^ 0xB8
2.3. Ajouter l'octet de contrôle
L'octet de contrôle est une donnée d'un octet et doit être ajouté en tête de la trame. Le format est illustré par le tableau ci-dessous :
Au total, il existe 6 types d’octets de contrôle. Les trois premiers sont utilisés pour les trames courantes contenant des données EZSP, notamment DATA, ACK et NAK. Les trois derniers sont utilisés sans données EZSP communes, notamment RST, RSTACK et ERROR.
Les formats de RST, RSTACK et ERROR sont décrits aux sections 3.1 à 3.3.
2.4. Calculer le CRC
Un CRC de 16 bits est calculé sur les octets depuis l'octet de contrôle jusqu'à la fin des données. Le standard CRCCCITT (g(x) = x16 + x12 + x5 + 1) est initialisé à 0xFFFF. L'octet de poids fort précède l'octet de poids faible (mode big-endian).
2.5. Bourrage d'octets
Comme décrit dans la section 4.2 de l'UG101, certaines valeurs d'octets réservées sont utilisées à des fins spéciales. Ces valeurs se retrouvent dans le tableau suivant :
Lorsque ces valeurs apparaîtront dans le cadre, un traitement spécial sera apporté aux données. – Insérez l'octet d'échappement 0x7D devant l'octet réservé – Inversez le bit5 de cet octet réservé
Voici quelques exemples de cet algorithme :
2.6. Ajouter le drapeau de fin
La dernière étape consiste à ajouter l'indicateur de fin 0x7E à la fin de la trame. Après cela, les données peuvent être envoyées au port UART.
3. Processus de décadrage
Lorsque les données sont reçues de l’UART, il suffit d’effectuer les étapes inverses pour les décoder.
4. Références
Heure de publication : 08 février 2022