Forfatter: TorchIoTBootCamp
Link: https://zhuanlan.zhihu.com/p/339700391
Fra: Quora
1. Innledning
Silicon Labs har tilbudt en host+NCP-løsning for Zigbee-gatewaydesign. I denne arkitekturen kan verten kommunisere med NCP-en via UART- eller SPI-grensesnitt. Vanligvis brukes UART, da det er mye enklere enn SPI.
Silicon Labs har også levert et eksempelprosjekt for vertsprogrammet, som er eksempeletZ3GatewayHostEksemplet kjører på et Unix-lignende system. Noen kunder ønsker kanskje et vertseksempel som kan kjøre på et RTOS, men dessverre finnes det ikke noe RTOS-basert vertseksempel for øyeblikket. Brukere må utvikle sitt eget vertsprogram basert på RTOS.
Det er viktig å forstå UART-gatewayprotokollen før man utvikler et tilpasset vertsprogram. For både UART-baserte NCP-er og SPI-baserte NCP-er bruker verten EZSP-protokollen for å kommunisere med NCP-en.EZSPer en forkortelse forEmberZnet seriell protokoll, og det er definert iUG100For UART-basert NCP implementeres en lavere lagsprotokoll for å overføre EZSP-data pålitelig over UART, det erASKEprotokoll, forkortelse forAsynkron seriell vertFor 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 å lage UART-data 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 rammeprosessene: |Ingen|Trinn|Referanse|
|:-|:-|:-|
|1|Fyll EZSP-rammen|UG100|
|2|Datarandomisering|Avsnitt 4.3 av UG101|
|3|Legg til kontrollbyten|Kap. 2 og kap. 3 av UG101|
|4|Beregn CRC|Del 2.3 av UG101|
|5|Bytefylling|Avsnitt 4.2 av UG101|
|6|Legg til sluttflagget|Del 2.4 av UG101|
2.1. Fyll EZSP-rammen
EZSP-rammeformatet er illustrert i kapittel 3 av 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 nyeste EZSP-versjonsnummeret er 8 når denne artikkelen er skrevet (EmberZnet 6.8).
Ettersom EZSP-rammeformatet kan variere mellom ulike versjoner, er det et obligatorisk krav at verten og NCP-enMÅfungere med samme EZSP-versjon. Ellers kan de ikke kommunisere som forventet.
For å oppnå dette, må den første kommandoen mellom verten og NCP-en være version-kommandoen. Med andre ord, verten må hente EZSP-versjonen av NCP-en før noen annen kommunikasjon. Hvis EZSP-versjonen er forskjellig fra EZSP-versjonen på vertssiden, må kommunikasjonen avbrytes.
Det implisitte kravet bak dette er at formatet til versjonskommandoen kanALDRI ENDREEZSP-versjonskommandoformatet er som følger:
链接：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 skjer til å ekskludere 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, er randi+1 = randi >> 1
- Hvis bit 0 av randi er 1, er randi+1 = (randi >> 1) ^ 0xB8
2.3. Legg til kontrollbyten
Kontrollbyten er én byte data, og bør legges til rammehodet. Formatet er illustrert med tabellen nedenfor:
Det finnes totalt 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.
Formatene til RST, RSTACK og ERROR er beskrevet i avsnitt 3.1 til 3.3.
2.4. Beregn CRC
En 16-bit 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. Bytefylling
Som beskrevet i avsnitt 4.2 i UG101, finnes det noen reserverte byteverdier som brukes til spesielle formål. Disse verdiene finnes i følgende tabell:
Når disse verdiene vises i rammen, vil dataene bli behandlet spesielt. – Sett inn escape-byten 0x7D foran den reserverte byten – Reverser bit5 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. Deframing-prosess
Når data mottas fra UART-en, trenger vi bare å gjøre de omvendte trinnene for å dekode dem.
4. Referanser
Publisert: 08.02.2022