Autor : Torchiotbootcamp
Enllaç : https: //zhuanlan.zhihu.com/p/339700391
De : Quora
1. Introducció
Silicon Labs ha ofert una solució Host+NCP per al disseny de Gateway Zigbee. En aquesta arquitectura, l'amfitrió es pot comunicar amb el NCP mitjançant la interfície UART o SPI. El més comunament, UART s’utilitza, ja que és molt més senzill que SPI.
Silicon Labs també ha proporcionat un projecte de mostra per al programa amfitrió, que és la mostraZ3Gatewayhost
. La mostra funciona amb un sistema similar a Unix. Alguns clients poden voler una mostra d’amfitrió que pugui funcionar en un RTOS, però, per desgràcia, no hi ha cap mostra d’amfitrió basada en RTOS de moment. Els usuaris han de desenvolupar el seu propi programa d’amfitrió basat en RTOS.
És important comprendre el protocol UART Gateway abans de desenvolupar un programa d’amfitrió personalitzat. Tant per a NCP basat en UART com per a NCP basat en SPI, l'amfitrió utilitza el protocol EZSP per comunicar -se amb el NCP.Ezspés curt perProtocol en sèrie Emberznet, i es defineix a100 UG. Per a NCP basat en UART, s'implementa un protocol de capa inferior per transportar dades EZSP de manera fiable sobre UART, això és elCendraprotocol, curt perAmfitrió de sèrie asíncron. Per obtenir més detalls sobre Ash, consulteuUG101iUG115.
La relació entre EZSP i ASH es pot il·lustrar amb el diagrama següent:
El format de dades de l'EZSP i el protocol ASH es pot il·lustrar mitjançant el diagrama següent:
En aquesta pàgina, introduirem el procés d’enquadrament de les dades UART i alguns marcs de claus que s’utilitzen freqüentment a Zigbee Gateway.
2. Froming
El procés general de frenada es pot il·lustrar amb el gràfic següent:
En aquest gràfic, les dades significa el marc EZSP. En general, els processos d’enquadrament són: | no | pas | referència |
|:-|:-|:-|
| 1 | Ompliu el marc EZSP | UG100 |
| 2 | Dades aleatoritzades | Secció 4.3 de UG101 |
| 3 | Afegiu el byte de control | Chap2 i Chap3 de UG101 |
| 4 | Calculeu la secció CRC | 2.3 de UG101 |
| 5 | Filtre de bytes | Secció 4.2 de UG101 |
| 6 | Afegiu la bandera final | Secció 2.4 de UG101 |
2.1. Ompliu el marc EZSP
El format de fotograma EZSP s'il·lustra al Cap 3 de UG100.
Fixeu -vos que aquest format pot canviar quan actualitzi el SDK. Quan el format canvia, li donarem un nou número de versió. L’últim número de versió EZSP és 8 quan s’escriu aquest article (Emberznet 6.8).
Com que el format de fotograma EZSP pot ser diferent entre diferents versions, hi ha un requisit obligatori que l'amfitrió i el NCPHaver deTreballar amb la mateixa versió EZSP. En cas contrari, no es poden comunicar com s’esperava.
Per aconseguir -ho, la primera ordre entre l'amfitrió i el NCP ha de ser l'ordre de versió. Dit d'una altra manera, l'amfitrió ha de recuperar la versió EZSP del NCP abans de qualsevol altra comunicació. Si la versió EZSP és diferent amb la versió EZSP del costat de l'amfitrió, s'ha de avortar la comunicació.
El requisit implícit que hi ha al darrere és que el format de l'ordre de versió potMai canvieu. El format d'ordres de la versió EZSP és com a continuació:
链接 : https: //zhuanlan.zhihu.com/p/339700391
来源 : 知乎
著作权归作者所有。商业转载请联系作者获得授权 , 非商业转载请注明出处。
2.2. Dades aleatoritzades
El procés detallat aleatoritzat es descriu a la secció 4.3 de UG101. Tot el marc EZSP serà aleatori. L’aleatorització és exclusiva o el marc EZSP i una seqüència de pseudo-aleatori.
A continuació, es mostra l'algorisme de generar la seqüència pseudo-aleatòria.
- rand0 = 0 × 42
- Si el bit 0 de Randi és 0, Randi+1 = Randi >> 1
- Si el bit 0 de Randi és 1, Randi+1 = (Randi >> 1) ^ 0xb8
2.3. Afegiu el byte de control
El byte de control és una dada d’un byte i s’ha d’afegir al cap del marc. El format s’il·lustra amb la taula següent:
Totalment, hi ha 6 tipus de bytes de control. Els tres primers s'utilitzen per a fotogrames comuns amb dades EZSP, incloses dades, ACK i Nak. Els tres últims s’utilitzen sense dades comunes d’EZSP, incloses RST, RSTACK i ERROR.
El format de RST, RSTACK i ERROR es descriu a la secció 3.1 a 3.3.
2.4. Calculeu el CRC
Un CRC de 16 bits es calcula en bytes des del byte de control fins al final de les dades. El CRCCCITT estàndard (g (x) = x16 + x12 + x5 + 1) s’inicialitza a 0xffff. El byte més significatiu precedeix el byte menys significatiu (mode gran-endian).
2.5. Farciment de bytes
Tal com es descriu a la secció 4.2 de UG101, hi ha alguns valors de bytes reservats utilitzats per a propòsits especials. Aquests valors es poden trobar a la taula següent:
Quan aquests valors apareixen al marc, es farà un tractament especial a les dades. - Inseriu el byte d’escapament 0x7d davant del byte reservat: reverteix el bit5 d’aquest byte reservat
A continuació es mostren alguns exemples d’aquest algorisme:
2.6. Afegiu la bandera final
L’últim pas és afegir la bandera final 0x7e al final del marc. Després d'això, les dades es poden enviar al port UART.
3. Procés de desemmotllament
Quan les dades es reben de la UART, només hem de fer els passos inversos per descodificar -les.
4. Referències
Posada Posada: 08 de febrer de 2012