Auteur : TorchIoTBootCamp
Lien：https://zhuanlan.zhihu.com/p/339700391
De : Quora
1. Introduction
Silicon Labs propose une solution hôte+NCP pour la conception de passerelles Zigbee. Dans cette architecture, l'hôte peut communiquer avec le NCP via une interface UART ou SPI. L'UART est le plus souvent utilisé, car il est beaucoup plus simple que le SPI.
Silicon Labs a également fourni un exemple de projet pour le programme hôte, qui est l'exempleZ3GatewayHostL'exemple fonctionne sur un système de type Unix. Certains clients pourraient souhaiter un exemple hôte compatible avec un RTOS, mais malheureusement, il n'existe pas encore d'exemple hôte basé sur un RTOS. Les utilisateurs doivent développer leur propre programme hôte basé sur un 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 dansUG100Pour le NCP basé sur UART, un protocole de couche inférieure est implémenté pour transporter les données EZSP de manière fiable sur UART, c'est leCENDREprotocole, abréviation deHôte série asynchronePour plus de détails sur ASH, veuillez vous référer àUG101etUG115.
La relation entre EZSP et ASH peut être illustrée par le diagramme suivant :
Le format des données de l'EZSP et du protocole ASH peut être illustré par le diagramme suivant :
Dans cette page, nous présenterons le processus de cadrage des données UART et certaines trames clés fréquemment utilisées dans la passerelle Zigbee.
2. Encadrement
Le processus général de cadrage peut être illustré par le tableau suivant :
Dans ce graphique, les données correspondent au cadre EZSP. En général, les processus de cadrage sont : |Aucune|Étape|Référence|
|:-|:-|:-|
|1|Remplir le cadre EZSP|UG100|
|2|Randomisation des données|Section 4.3 de UG101|
|3|Ajouter l'octet de contrôle|Chap2 et Chap3 de UG101|
|4|Calculer le CRC|Section 2.3 de UG101|
|5|Remplissage d'octets|Section 4.2 de UG101|
|6|Ajouter l'indicateur de fin|Section 2.4 de UG101|
2.1. Remplir le cadre EZSP
Le format de trame EZSP est illustré au chapitre 3 de l'UG100.
Veuillez noter que ce format peut changer lors des mises à jour du SDK. À chaque modification, nous lui attribuerons un nouveau numéro de version. La dernière version d'EZSP est la 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 est obligatoire que l'hôte et le NCPDOITfonctionnent avec la même version d'EZSP. Sinon, ils ne peuvent pas communiquer comme prévu.
Pour ce faire, la première commande entre l'hôte et le NCP doit être la commande de version. Autrement dit, l'hôte doit récupérer la version EZSP du NCP avant toute autre communication. Si la version EZSP diffère de celle de l'hôte, la communication doit être interrompue.
L'exigence implicite derrière cela est que le format de la commande de version puisseNE CHANGEZ JAMAISLe 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 du cours UG101. L'ensemble de la séquence EZSP sera randomisé. La randomisation consiste à effectuer une opération OU exclusive entre la séquence 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 trame. Son format est illustré dans le tableau ci-dessous :
Il existe au total six types d'octets de contrôle. Les trois premiers sont utilisés pour les trames communes avec données EZSP, notamment DATA, ACK et NAK. Les trois derniers sont utilisés sans données EZSP communes, notamment RST, RSTACK et ERROR.
Le format de RST, RSTACK et ERROR est décrit dans les sections 3.1 à 3.3.
2.4. Calculer le CRC
Un CRC 16 bits est calculé sur les octets depuis l'octet de contrôle jusqu'à la fin des données. Le CRC standard (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 sont réservées à des fins spécifiques. Ces valeurs sont présentées dans le tableau suivant :
Lorsque ces valeurs apparaissent dans le cadre, un traitement spécial sera appliqué aux données. – Insérer l'octet d'échappement 0x7D devant l'octet réservé – Inverser le bit5 de cet octet réservé
Vous trouverez ci-dessous quelques exemples de cet algorithme :
2.6. Ajouter l'indicateur de fin
L'étape finale consiste à ajouter l'indicateur de fin 0x7E à la fin de la trame. Les données peuvent ensuite être envoyées au port UART.
3. Processus de décadrage
Lorsque les données sont reçues de l'UART, il suffit de suivre les étapes inverses pour les décoder.
4. Références
Date de publication : 08/02/2022