Auteur: TorchIoTBootCamp
Link: https://zhuanlan.zhihu.com/p/339700391
Van: Quora
1. Inleiding
Silicon Labs biedt een host+NCP-oplossing voor Zigbee-gatewayontwerp. In deze architectuur kan de host met de NCP communiceren via een UART- of SPI-interface. UART wordt meestal gebruikt omdat het veel eenvoudiger is dan SPI.
Silicon Labs heeft ook een voorbeeldproject voor het hostprogramma geleverd, namelijk het voorbeeldZ3GatewayHostHet voorbeeld draait op een Unix-achtig systeem. Sommige klanten willen mogelijk een hostvoorbeeld dat op een RTOS kan draaien, maar helaas is er momenteel geen hostvoorbeeld op basis van RTOS. Gebruikers moeten hun eigen hostprogramma op basis van RTOS ontwikkelen.
Het is belangrijk om het UART-gatewayprotocol te begrijpen voordat u een aangepast hostprogramma ontwikkelt. Voor zowel UART-gebaseerde NCP's als SPI-gebaseerde NCP's gebruikt de host het EZSP-protocol om met de NCP te communiceren.EZSPis een afkorting voorEmberZnet serieel protocol, en het is gedefinieerd inUG100Voor op UART gebaseerde NCP wordt een protocol op een lagere laag geïmplementeerd om EZSP-gegevens betrouwbaar over UART te transporteren, dat is deASprotocol, kort voorAsynchrone seriële hostVoor meer informatie over ASH kunt u terecht opUG101EnUG115.
De relatie tussen EZSP en ASH kan worden geïllustreerd aan de hand van het volgende diagram:
Het gegevensformaat van het EZSP- en ASH-protocol kan worden geïllustreerd aan de hand van het volgende diagram:
Op deze pagina introduceren we het proces van het framing van UART-gegevens en enkele sleutelframes die vaak worden gebruikt in de Zigbee-gateway.
2. Kadering
Het algemene kaderproces kan worden geïllustreerd aan de hand van het volgende diagram:
In deze grafiek hebben de gegevens betrekking op het EZSP-frame. Over het algemeen zijn de framingprocessen: |Geen|Stap|Referentie|
|:-|:-|:-|
|1|Vul het EZSP-frame|UG100|
|2|Gegevensrandomisatie|Sectie 4.3 van UG101|
|3|Voeg de controlebyte toe|Chap2 en Chap3 van UG101|
|4|Bereken de CRC|Paragraaf 2.3 van UG101|
|5|Byte Stuffing|Sectie 4.2 van UG101|
|6|Voeg de eindvlag toe|Sectie 2.4 van UG101|
2.1. Vul het EZSP-frame in
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 we het een nieuw versienummer. Het nieuwste EZSP-versienummer was 8 toen dit artikel werd geschreven (EmberZnet 6.8).
Omdat het EZSP-frameformaat per versie kan verschillen, is er een verplichte vereiste dat de host en NCPMOETENwerken met dezelfde EZSP-versie. Anders kunnen ze niet zoals verwacht communiceren.
Om dit te bereiken, moet het eerste commando tussen de host en de NCP het versiecommando zijn. Met andere woorden, de host moet de EZSP-versie van de NCP ophalen vóór elke andere communicatie. Als de EZSP-versie verschilt van de EZSP-versie van de host, moet de communicatie worden afgebroken.
De impliciete vereiste hierachter is dat de opmaak van het versiecommando kanNOOIT VERANDERENHet commando-formaat 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 gehele EZSP-frame wordt gerandomiseerd. De randomisatie bestaat uit het gebruik van exclusieve OR voor het EZSP-frame en een pseudo-willekeurige volgorde.
Hieronder ziet u het algoritme voor het genereren van de pseudo-willekeurige reeks.
- rand0 = 0×42
- als bit 0 van randi 0 is, randi+1 = randi >> 1
- als bit 0 van randi 1 is, randi+1 = (randi >> 1) ^ 0xB8
2.3. Voeg de controlebyte toe
De controlebyte bestaat uit één byte data en moet aan de kop van het frame worden toegevoegd. De indeling wordt geïllustreerd in de onderstaande tabel:
Er zijn in totaal zes soorten controlebytes. De eerste drie worden gebruikt voor gemeenschappelijke frames met EZSP-gegevens, waaronder DATA, ACK en NAK. De laatste drie worden gebruikt zonder gemeenschappelijke EZSP-gegevens, waaronder RST, RSTACK en ERROR.
De opmaak van RST, RSTACK en ERROR wordt beschreven in paragraaf 3.1 tot en met 3.3.
2.4. Bereken de CRC
Een 16-bits CRC wordt berekend over bytes vanaf de controlebyte tot het einde van de data. 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 paragraaf 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 aan de data gegeven. – Voeg de escape byte 0x7D in voor de gereserveerde byte – Keer de 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. De-framing-proces
Wanneer er gegevens van de UART worden ontvangen, hoeven we alleen maar de omgekeerde stappen uit te voeren om de gegevens te decoderen.
4. Referenties
Plaatsingstijd: 08-02-2022