Auteur: TorchIoTBootCamp
Link: https://zhuanlan.zhihu.com/p/339700391
Van: Quora
1. Inleiding
Silicon Labs heeft een host+NCP-oplossing aangeboden voor het ontwerp van de Zigbee-gateway. In deze architectuur kan de host communiceren met de NCP via de UART- of SPI-interface. Meestal wordt UART gebruikt omdat het veel eenvoudiger is dan SPI.
Silicon Labs heeft ook een voorbeeldproject voor het hostprogramma geleverd, namelijk het voorbeeldZ3GatewayHost. Het voorbeeld draait op een Unix-achtig systeem. Sommige klanten willen misschien een host-sample die op een RTOS kan draaien, maar helaas is er voorlopig geen op RTOS gebaseerd host-sample. Gebruikers moeten hun eigen hostprogramma ontwikkelen op basis van RTOS.
Het is belangrijk om het UART-gatewayprotocol te begrijpen voordat u een aangepast hostprogramma ontwikkelt. Voor zowel op UART gebaseerde NCP als op SPI gebaseerde NCP gebruikt de host het EZSP-protocol om met de NCP te communiceren.EZSPis een afkorting voorEmberZnet serieel protocol, en het is gedefinieerd inUG100. Voor op UART gebaseerde NCP wordt een lager protocol geïmplementeerd om EZSP-gegevens betrouwbaar over UART te transporteren, dat is deASprotocol, afkorting vanAsynchrone seriële host. Voor meer informatie over ASH verwijzen wij u naarUG101EnUG115.
De relatie tussen EZSP en ASH kan worden geïllustreerd aan de hand van het volgende diagram:
Het gegevensformaat van het EZSP- en het ASH-protocol kan worden geïllustreerd aan de hand van het volgende diagram:
Op deze pagina introduceren we het proces van het inlijsten van de UART-gegevens en enkele sleutelframes die vaak worden gebruikt in de Zigbee-gateway.
2. Inlijsten
Het algemene frameringsproces kan worden geïllustreerd aan de hand van het volgende diagram:
In dit diagram betekenen de gegevens het EZSP-frame. Over het algemeen zijn de frameprocessen: |No|Step|Reference|
|:-|:-|:-|
|1|Vul het EZSP-frame|UG100|
|2|Gegevensrandomisatie|Paragraaf 4.3 van UG101|
|3|Voeg de besturingsbyte|Chap2 en Chap3 van UG101| toe
|4|Bereken de CRC|Paragraaf 2.3 van UG101|
|5|Byte-opvulling|Sectie 4.2 van UG101|
|6|Voeg de eindvlag toe|Paragraaf 2.4 van UG101|
2.1. Vul het EZSP-frame
Het EZSP-frameformaat wordt geïllustreerd in hoofdstuk 3 van UG100.
Houd er rekening mee dat dit formaat kan veranderen wanneer de SDK wordt geüpgraded. Wanneer het formaat verandert, geven wij het een nieuw versienummer. Het nieuwste EZSP-versienummer is 8 op het moment dat dit artikel wordt geschreven (EmberZnet 6.8).
Omdat het EZSP-frameformaat tussen verschillende versies kan verschillen, is er een verplichte vereiste dat de host en NCPMOETENwerken met dezelfde EZSP-versie. Anders kunnen ze niet communiceren zoals verwacht.
Om dat te bereiken moet het eerste commando tussen de host en het NCP het versiecommando zijn. Met andere woorden: de host moet de EZSP-versie van het NCP ophalen voordat enige andere communicatie plaatsvindt. Als de EZSP-versie verschilt van de EZSP-versie van de hostzijde, moet de communicatie worden afgebroken.
De impliciete vereiste hierachter is dat het formaat van de versieopdracht dat wel kanVERANDER NOOIT. Het opdrachtformaat van de EZSP-versie ziet er als volgt uit:
链接:https://zhuanlan.zhihu.com/p/339700391
Ik bedoel: 知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
2.2. Randomisatie van gegevens
Het gedetailleerde randomisatieproces wordt beschreven in paragraaf 4.3 van UG101. Het hele EZSP-frame wordt gerandomiseerd. De randomisatie vindt plaats door exclusieve OF het EZSP-frame en een pseudo-willekeurige reeks.
Hieronder ziet u het algoritme voor het genereren van de pseudo-willekeurige reeks.
- rand0 = 0×42
- als bit 0 van randi 0 is, dan is randi+1 = randi >> 1
- als bit 0 van randi 1 is, randi+1 = (randi >> 1) ^ 0xB8
2.3. Voeg de controlebyte toe
De besturingsbyte bestaat uit gegevens van één byte en moet aan de kop van het frame worden toegevoegd. Het formaat wordt geïllustreerd met de onderstaande tabel:
In totaal zijn er 6 soorten besturingsbytes. De eerste drie worden gebruikt voor algemene frames met EZSP-gegevens, waaronder DATA, ACK en NAK. De laatste drie worden gebruikt zonder gemeenschappelijke EZSP-gegevens, waaronder RST, RSTACK en ERROR.
Het formaat van RST, RSTACK en ERROR wordt beschreven in paragraaf 3.1 tot 3.3.
2.4. Bereken de CRC
Een 16-bits CRC wordt berekend op basis van bytes vanaf de besturingsbyte tot het einde van de gegevens. De standaard CRCCCITT (g(x) = x16 + x12 + x5 + 1) wordt geïnitialiseerd op 0xFFFF. De meest significante byte gaat vooraf aan de minst significante byte (big-endian-modus).
2.5. Byte-vulling
Zoals beschreven in sectie 4.2 van UG101, zijn er enkele gereserveerde bytewaarden die voor speciale doeleinden worden gebruikt. Deze waarden zijn te vinden in de volgende tabel:
Wanneer deze waarden in het frame verschijnen, wordt er een speciale behandeling op de gegevens uitgevoerd. – Plaats de escape-byte 0x7D vóór de gereserveerde byte – Keer bit5 van die gereserveerde byte om
Hieronder staan enkele voorbeelden van dit algoritme:
2.6. Voeg de eindvlag toe
De laatste stap is het toevoegen van de eindvlag 0x7E aan het einde van het frame. Daarna kunnen de gegevens naar de UART-poort worden verzonden.
3. Deframingproces
Wanneer gegevens van de UART worden ontvangen, hoeven we alleen maar de omgekeerde stappen uit te voeren om deze te decoderen.
4. Referenties
Posttijd: 08-02-2022