Om ZigBee EZSP UART

Forfatter ： Torchiotbootcamp
Link ： https: //zhuanlan.zhihu.com/p/339700391
Fra ： Quora

1. Introduktion

Silicon Labs har tilbudt en vært+NCP -løsning til ZigBee Gateway Design. I denne arkitektur kan værten kommunikere med NCP gennem UART- eller SPI -interface. Oftest bruges UART, da det er meget enklere end SPI.

Silicon Labs har også leveret et eksempelprojekt til værtsprogrammet, som er prøvenZ3Gatewayhost. Prøven kører på et UNIX-lignende system. Nogle kunder ønsker muligvis en værtsprøve, der kan køre på en RTOS, men desværre er der ingen RTOS -baseret værtsprøve for tiden. Brugere er nødt til at udvikle deres eget værtsprogram baseret på RTO'er.

Det er vigtigt at forstå UART Gateway -protokollen, før du udvikler et tilpasset værtsprogram. For både UART -baserede NCP og SPI -baserede NCP bruger værten EZSP -protokollen til at kommunikere med NCP.EZSPer forkortet efterEmberznet seriel protokol, og det er defineret iUG100. For UART -baseret NCP implementeres en lavere lagprotokol til at bære EZSP -data pålideligt over UART, det erASKEProtokol, kort efterAsynkron seriel vært. For flere detaljer om aske, se venligstUG101ogUG115.

Forholdet mellem EZSP og Ash kan illustreres ved følgende diagram:

Dataformatet for EZSP og ASH -protokollen kan illustreres ved følgende diagram:

På denne side introducerer vi processen med at indramme UART -data og nogle nøglerammer, der ofte bruges i Zigbee Gateway.

2. ramme

Den generelle rammeproces kan illustreres af følgende diagram:

I dette diagram betyder dataene EZSP -rammen. Generelt er indramningsprocesserne: | nej | Trin | Reference |

|:-|:-|:-|

| 1 | Fyld EZSP -rammen | UG100 |

| 2 | Data randomisering | Afsnit 4.3 i UG101 |

| 3 | Tilføj kontrollen Byte | Chap2 og Chap3 i UG101 |

| 4 | Beregn CRC | Afsnit 2.3 i UG101 |

| 5 | Byte -fyldning | Afsnit 4.2 i UG101 |

| 6 | Tilføj slutflagget | Afsnit 2.4 i UG101 |

2.1. Fyld EZSP -rammen

EZSP -rammeformatet er illustreret i kap. 3 på UG100.

Vær opmærksom på, at dette format kan ændre sig, når SDK -opgraderingerne. Når formatet ændres, giver vi det et nyt versionnummer. Det seneste EZSP -versionnummer er 8, når denne artikel er skrevet (EmberzNet 6.8).

Da EZSP -rammeformatet kan være forskelligt mellem forskellige versioner, er der et obligatorisk krav om, at værten og NCPSKALArbejd med den samme EZSP -version. Ellers kan de ikke kommunikere som forventet.

For at opnå dette skal den første kommando mellem værten og NCP være versionskommandoen. Med andre ord, værten skal gentage EZSP -versionen af NCP før nogen anden kommunikation. Hvis EZSP -versionen er forskellig med EZSP -versionen af værtssiden, skal kommunikationen afbrydes.

Det implicitte krav bag dette er, at formatet af versionskommandoen kanSkift aldrig. EZSP -versionskommandoformatet er som nedenfor:

Forklaringer på parameterfeltet og formatet for versionens respons kan findes i kap. 4 på UG100. Parameterfeltet er EZSP -versionen af værtsprogrammet. Når denne artikel er skrevet, er den 8.

作者： Torchiotbootcamp
链接： https: //zhuanlan.zhihu.com/p/339700391
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

2.2. Data randomisering

Den detaljerede randomiseringsproces er beskrevet i afsnit 4.3 i UG101. Hele EZSP -rammen vil blive randomiseret. Randomiseringen er til eksklusiv-eller EZSP-rammen og en pseudo-tilfældig sekvens.

Nedenfor er algoritmen til at generere den pseudo-tilfældige sekvens.

Rand0 = 0 × 42
Hvis bit 0 af randi er 0, randi+1 = randi >> 1
Hvis bit 0 af randi er 1, randi+1 = (randi >> 1) ^ 0xb8

2.3. Tilføj kontrolbyte

Kontrolbyte er en byte -data og bør føjes til hovedet på rammen. Formatet er illustreret med nedenstående tabel:

Der er helt 6 slags kontrolbyte. De første tre bruges til almindelige rammer med EZSP -data, herunder data, ACK og NAK. De sidste tre bruges uden almindelige EZSP -data, herunder RST, RSTACK og fejl.

Formatet for RST, RSTACK og fejl er beskrevet i afsnit 3.1 til 3.3.

2.4. Beregn CRC

En 16-bit CRC beregnes på bytes fra kontrolbyte indtil slutningen af dataene. Standard CRCCCITT (G (x) = x16 + x12 + x5 + 1) initialiseres til 0xffff. Den mest markante byte går foran den mindst betydningsfulde byte (big-endian-tilstand).

2.5. Byte -fyldning

Som beskrevet i afsnit 4.2 i UG101 er der nogle reserverede byteværdier, der bruges til specielt formål. Disse værdier findes i følgende tabel:

Når disse værdier vises i rammen, udføres en særlig behandling af dataene. - Indsæt flugtbyte 0x7d foran den reserverede byte - Vend bit5 af den reserverede byte

Nedenfor er nogle eksempler på denne algoritme: