Forfatter ： Torchiotbootcamp
Link ： https: //zhuanlan.zhihu.com/p/339700391
Fra ： Quora
1. Innledning
Silicon Labs har tilbudt en vert+NCP -løsning for Zigbee Gateway Design. I denne arkitekturen kan verten kommunisere med NCP gjennom UART- eller SPI -grensesnittet. Oftest brukes UART som det er mye enklere enn SPI.
Silicon Labs har også gitt et eksempelprosjekt for vertsprogrammet, som er prøvenZ3GatewayHost. Prøven kjører på et UNIX-lignende system. Noen kunder vil kanskje ha en vertsutvalg som kan kjøre på RTOS, men dessverre er det ingen RTOS -basert vertsprøve for tiden. Brukere må utvikle sitt eget vertsprogram basert på RTO -er.
Det er viktig å forstå UART Gateway -protokollen 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 seriell protokoll, og det er definert iUG100. For UART -basert NCP implementeres en lavere lagsprotokoll for å bære EZSP -data pålitelig over UART, det erASKEProtokoll, forkortelse forAsynkron seriell vert. For mer informasjon om aske, seUG101ogUG115.
Forholdet mellom EZSP og Ash kan illustreres med følgende diagram:
Dataformatet til EZSP og askeprotokollen kan illustreres med følgende diagram:
På denne siden vil vi introdusere prosessen med å ramme ut UART -data og noen nøkkelrammer som ofte brukes i Zigbee Gateway.
2. Framing
Den generelle rammeprosessen 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 | Avsnitt 4.3 i UG101 |
| 3 | Legg til kontrollbyte | Chap2 og Chap3 of UG101 |
| 4 | Beregn CRC | Avsnitt 2.3 i UG101 |
| 5 | byte -fylling | Avsnitt 4.2 i UG101 |
| 6 | Legg til sluttflagget | Avsnitt 2.4 i UG101 |
2.1. Fyll EZSP -rammen
EZSP -rammeformatet er illustrert i kap 3 av UG100.
Vær oppmerksom på at dette formatet kan endre seg når SDK oppgraderer. 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 forskjellige versjoner, er det et obligatorisk krav om at verten og NCPMåArbeid med den samme EZSP -versjonen. Ellers kan de ikke kommunisere som forventet.
For å oppnå det, må den første kommandoen mellom verten og NCP være versjonskommandoen. Verten må med andre ord tilbaketrekke EZSP -versjonen av NCP før annen kommunikasjon. Hvis EZSP -versjonen er annerledes med EZSP -versjonen av vertssiden, må kommunikasjonen aborteres.
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. Data randomisering
Den detaljerte randomiseringsprosessen er beskrevet i avsnitt 4.3 i UG101. Hele EZSP -rammen vil bli randomisert. Randomiseringen er å eksklusiv eller EZSP-rammen og en pseudo-tilfeldig sekvens.
Nedenfor er algoritmen for å generere pseudo-tilfeldig-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 en byte -data, og bør legges til rammen. Formatet er illustrert med tabellen nedenfor:
Helt, det er 6 typer kontrollbyte. De tre første brukes til vanlige rammer med EZSP -data, inkludert data, ACK og NAK. De tre siste brukes uten vanlige EZSP -data, inkludert RST, RSTACK og feil.
Formatet til RST, RSTACK og FEIL 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 betydningsfulle byte går foran den minst betydningsfulle byte (Big-Endian-modus).
2.5. Byte -fylling
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 med dataene. - Sett inn fluktbyte 0x7d foran den reserverte byte - Omvend bit5 av den reserverte byte
Nedenfor er noen eksempler på denne algoritmen:
2.6. Legg til sluttflagget
Det siste trinnet er å legge sluttflagget 0x7E til enden av rammen. Etter det kan dataene sendes til UART -porten.
3. De-innrammingsprosess
Når data mottas fra UART, trenger vi bare å gjøre de motsatte trinnene for å avkode det.
4. Referanser
Post Time: Feb-08-2022