Autor ： Torchiotbootcamp
Ligazón ： https: //zhuanlan.zhihu.com/p/339700391
De ： Quora
1. Introdución
Silicon Labs ofreceu unha solución host+NCP para o deseño de Gateway Zigbee. Nesta arquitectura, o host pode comunicarse co NCP a través da interface UART ou SPI. Máis comúnmente, UART úsase xa que é moito máis sinxelo que o SPI.
Silicon Labs tamén proporcionou un proxecto de mostra para o programa de host, que é a mostraZ3GATEWAYHOST. A mostra funciona nun sistema similar a UNIX. Algúns clientes poden querer unha mostra de host que poida executar nun RTO, pero por desgraza, polo momento non hai unha mostra de host baseada en RTOS. Os usuarios necesitan desenvolver o seu propio programa de host baseado en RTOS.
É importante comprender o protocolo de pasarela UART antes de desenvolver un programa de host personalizado. Tanto para NCP baseado en UART como para NCP baseado en SPI, o host usa o protocolo EZSP para comunicarse co NCP.EZSPé curto paraProtocolo en serie EmberzNet, e defínese enUG100. Para NCP baseado en UART, implementase un protocolo de capa inferior para transportar datos de EZSP de forma fiable sobre UART, ese é oCinzaProtocolo, curto paraAsíncrono anfitrión en serie. Para máis detalles sobre a cinza, consulteUG101eUG115.
A relación entre EZSP e Ash pódese ilustrar co seguinte diagrama:
O formato de datos do EZSP e o protocolo de cinza pódese ilustrar co seguinte diagrama:
Nesta páxina, introduciremos o proceso de enmarcar os datos UART e algúns cadros clave que se usan frecuentemente en Zigbee Gateway.
2. Marco
O proceso xeral de marco pódese ilustrar co seguinte gráfico:
Neste gráfico, os datos significan o marco EZSP. En xeral, os procesos de enmarcado son: | Non | Paso | Referencia |
|:-|:-|:-|
| 1 | Enche o cadro EZSP | UG100 |
| 2 | Randomización de datos | Sección 4.3 de UG101 |
| 3 | Engadir o byte de control | Chap2 e Chap3 de UG101 |
| 4 | Calcula o CRC | Sección 2.3 de UG101 |
| 5 | recheo byte | Sección 4.2 de UG101 |
| 6 | Engadir a bandeira final | Sección 2.4 de UG101 |
2.1. Encha o marco EZSP
O formato de fotograma EZSP está ilustrado no capítulo 3 de UG100.
Preste atención a que este formato poida cambiar cando o SDK actualice. Cando o formato cambie, daremos un número de versión nova. O último número de versión EZSP é 8 cando se escribe este artigo (EmberzNet 6.8).
Como o formato de fotograma EZSP pode ser diferente entre diferentes versións, hai un requisito obrigatorio que o host e o NCPDEBETraballa coa mesma versión EZSP. Se non, non poden comunicarse como se espera.
Para conseguilo, o primeiro comando entre o host e o NCP debe ser o comando de versión. Noutras palabras, o host debe retroceder a versión EZSP do NCP antes de calquera outra comunicación. Se a versión EZSP é diferente coa versión EZSP do lado do host, a comunicación debe abortarse.
O requisito implícito detrás disto é que o formato do comando da versión podeNunca cambie. O formato de comando de versión EZSP é como a continuación:
链接 ： https: //zhuanlan.zhihu.com/p/339700391
来源 ： 知乎
著作权归作者所有。商业转载请联系作者获得授权 ， 非商业转载请注明出处。
2.2. Randomización de datos
O proceso de aleatorización detallado descríbese na sección 4.3 de UG101. O cadro EZSP completo será aleatorizado. A aleatorización é a exclusiva ou o marco EZSP e unha secuencia pseudo-aleatoria.
A continuación móstrase o algoritmo de xerar a secuencia pseudo-aleatoria.
- Rand0 = 0 × 42
- Se o bit 0 de Randi é 0, Randi+1 = Randi >> 1
- Se o bit 0 de Randi é 1, Randi+1 = (Randi >> 1) ^ 0xb8
2.3. Engade o byte de control
O byte de control é un datos dun byte e debe engadirse á cabeza do cadro. O formato móstrase coa táboa seguinte:
Totalmente, hai 6 tipos de bytes de control. Os tres primeiros úsanse para cadros comúns con datos EZSP, incluíndo datos, ACK e NAK. Os tres últimos úsanse sen datos comúns de EZSP, incluíndo RST, RSTack e Error.
O formato do primeiro, RSTack e o erro descríbense na sección 3.1 a 3.3.
2.4. Calcula o CRC
Un CRC de 16 bits calcúlase en bytes desde o byte de control ata o final dos datos. O estándar CRCCCITT (g (x) = x16 + x12 + x5 + 1) inicialízase a 0xffff. O byte máis significativo precede ao byte menos significativo (modo de gran endiano).
2.5. Recheo de bytes
Como se describe na sección 4.2 de UG101, hai algúns valores de bytes reservados empregados para fins especiais. Estes valores pódense atopar na seguinte táboa:
Cando estes valores aparezan no cadro, farase un tratamento especial aos datos. - Inserir o byte de escape 0x7d diante do byte reservado - reverter o bit5 dese byte reservado
A continuación móstranse algúns exemplos deste algoritmo:
2.6. Engade a bandeira final
O último paso é engadir a bandeira final 0x7E ao final do cadro. Despois diso, os datos pódense enviar ao porto UART.
3. Proceso de marco
Cando os datos se reciben do UART, só necesitamos facer os pasos inversos para decodificalo.
4. Referencias
Tempo de publicación: FEB-08-2022