Forfatter: TorchIoTBootCamp
Link: https://zhuanlan.zhihu.com/p/339700391
Fra: Quora
1. Introduksjon
Silicon Labs har tilbudt en vert+NCP-løsning for Zigbee-gatewaydesign. I denne arkitekturen kan verten kommunisere med NCP via UART- eller SPI-grensesnitt. Oftest brukes UART da det er mye enklere enn SPI.
Silicon Labs har også levert et eksempelprosjekt for vertsprogrammet, som er prøvenZ3GatewayHost. Prøven kjører på et Unix-lignende system. Noen kunder vil kanskje ha en vertsprøve som kan kjøres på en RTOS, men dessverre er det ingen RTOS-basert vertsprøve foreløpig. Brukere må utvikle sitt eget vertsprogram basert på RTOS.
Det er viktig å forstå UART-gatewayprotokollen før du utvikler et tilpasset vertsprogram. For både UART-basert NCP og SPI-basert NCP, bruker verten EZSP-protokollen for å kommunisere med NCP.EZSPer forkortelse forEmberZnet Serial Protocol, og det er definert iUG100. For UART-basert NCP implementeres en lavere lagprotokoll for å overføre EZSP-data pålitelig over UART, det erASKEprotokoll, forkortelse forAsynkron seriell vert. For mer informasjon om ASH, seUG101ogUG115.
Forholdet mellom EZSP og ASH kan illustreres med følgende diagram:
Dataformatet til EZSP og ASH-protokollen kan illustreres med følgende diagram:
På denne siden vil vi introdusere prosessen med å ramme UART-dataene og noen nøkkelrammer som ofte brukes i Zigbee-gatewayen.
2. Innramming
Den generelle innrammingsprosessen kan illustreres med følgende diagram:
I dette diagrammet betyr dataene EZSP-rammen. Generelt er innrammingsprosessene: |Nei|Trinn|Referanse|
|:-|:-|:-|
|1|Fyll EZSP-rammen|UG100|
|2|Data randomisering|Seksjon 4.3 av UG101|
|3|Legg til kontrollbyte|kap2 og kap3 av UG101|
|4|Beregn CRC|Seksjon 2.3 av UG101|
|5|Byte Stuffing|Seksjon 4.2 av UG101|
|6|Legg til sluttflagget|Seksjon 2.4 av UG101|
2.1. Fyll EZSP-rammen
EZSP-rammeformatet er illustrert i kapittel 3 i UG100.
Vær oppmerksom på at dette formatet kan endres når SDK-en oppgraderes. Når formatet endres, vil vi gi det et nytt versjonsnummer. Det siste EZSP-versjonsnummeret er 8 når denne artikkelen er skrevet (EmberZnet 6.8).
Siden EZSP-rammeformatet kan være forskjellig mellom ulike versjoner, er det et obligatorisk krav at verten og NCPMÅarbeid med samme EZSP-versjon. Ellers kan de ikke kommunisere som forventet.
For å oppnå det, må den første kommandoen mellom verten og NCP være versjonskommandoen. Med andre ord må verten hente EZSP-versjonen av NCP før annen kommunikasjon. Hvis EZSP-versjonen er forskjellig fra EZSP-versjonen av vertssiden, må kommunikasjonen avbrytes.
Det implisitte kravet bak dette er at formatet til versjonskommandoen kanALDRI ENDRE. EZSP-versjonskommandoformatet er som nedenfor:
链接：https://zhuanlan.zhihu.com/p/339700391
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请泤儎凂
2.2. Datarandomisering
Den detaljerte randomiseringsprosessen er beskrevet i avsnitt 4.3 i UG101. Hele EZSP-rammen vil bli randomisert. Randomiseringen er til eksklusiv-ELLER EZSP-rammen og en pseudo-tilfeldig sekvens.
Nedenfor er algoritmen for å generere den pseudo-tilfeldige sekvensen.
- rand0 = 0×42
- hvis bit 0 av randi er 0, randi+1 = randi >> 1
- hvis bit 0 av randi er 1, randi+1 = (randi >> 1) ^ 0xB8
2.3. Legg til kontrollbyte
Kontrollbyten er én byte-data, og bør legges til toppen av rammen. Formatet er illustrert med tabellen nedenfor:
Totalt er det 6 typer kontrollbyte. De tre første brukes for vanlige rammer med EZSP-data, inkludert DATA, ACK og NAK. De tre siste brukes uten vanlige EZSP-data, inkludert RST, RSTACK og ERROR.
Formatet til RST, RSTACK og ERROR er beskrevet i avsnitt 3.1 til 3.3.
2.4. Beregn CRC
En 16-bits CRC beregnes på byte fra kontrollbyten til slutten av dataene. Standard CRCCCITT (g(x) = x16 + x12 + x5 + 1) initialiseres til 0xFFFF. Den mest signifikante byten går foran den minst signifikante byten (big-endian-modus).
2.5. Byte Stuffing
Som beskrevet i avsnitt 4.2 i UG101, er det noen reserverte byteverdier som brukes til spesielle formål. Disse verdiene finner du i følgende tabell:
Når disse verdiene vises i rammen, vil det bli gjort en spesiell behandling av dataene. – Sett inn escape-byten 0x7D foran den reserverte byten – Reverser bit5-en til den reserverte byten
Nedenfor er noen eksempler på denne algoritmen:
2.6. Legg til sluttflagget
Det siste trinnet er å legge til sluttflagget 0x7E på slutten av rammen. Etter det kan dataene sendes til UART-porten.
3. De-framing prosess
Når data mottas fra UART, trenger vi bare å gjøre de omvendte trinnene for å dekode dem.
4. Referanser
Innleggstid: 08-02-2022