Autor：TorchIoTBotCamp
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 pasarelas Zigbee. Nesta arquitectura, o host pode comunicarse co NCP a través dunha interface UART ou SPI. O máis habitual é usar UART porque é moito máis sinxelo que SPI.
Silicon Labs tamén proporcionou un proxecto de exemplo para o programa anfitrión, que é o exemploHost de pasarela Z3O exemplo execútase nun sistema tipo Unix. Algúns clientes poden querer un exemplo de host que poida executarse nun RTOS, pero por desgraza, non hai ningún exemplo de host baseado en RTOS polo de agora. Os usuarios deben desenvolver o seu propio programa de host baseado en RTOS.
É importante comprender o protocolo de pasarela UART antes de desenvolver un programa host personalizado. Tanto para o NCP baseado en UART como para o NCP baseado en SPI, o host usa o protocolo EZSP para comunicarse co NCP.EZSPé abreviatura deProtocolo serie EmberZnet, e está definido enUG100Para NCP baseado en UART, impleméntase un protocolo de capa inferior para transportar datos EZSP de forma fiable sobre UART, que é oCINZOprotocolo, abreviatura deHost serie asíncronoPara obter máis detalles sobre ASH, consulteUG101eUG115.
A relación entre EZSP e ASH pódese ilustrar co seguinte diagrama:
O formato de datos do EZSP e do protocolo ASH pódese ilustrar co seguinte diagrama:
Nesta páxina, presentaremos o proceso de enmarcar os datos UART e algúns fotogramas clave que se usan con frecuencia na pasarela Zigbee.
2. Enmarcado
O proceso xeral de enmarcación pódese ilustrar co seguinte gráfico:
Neste gráfico, os datos refírense ao marco EZSP. En xeral, os procesos de enmarcamento son: |Sen|Paso|Referencia|
|:-|:-|:-|
|1|Encher o marco EZSP|UG100|
|2|Aleatoriación de datos|Sección 4.3 de UG101|
|3|Engadir o byte de control|Capítulo 2 e Capítulo 3 de UG101|
|4|Calcula o CRC|Sección 2.3 de UG101|
|5|Recheo de bytes|Sección 4.2 de UG101|
|6|Engadir o indicador de fin|Sección 2.4 de UG101|
2.1. Encher o marco EZSP
O formato da trama EZSP ilústrase no capítulo 3 da UG100.
Ten en conta que este formato pode cambiar cando se actualice o SDK. Cando o formato cambie, asignarémoslle un novo número de versión. O número de versión máis recente de EZSP é o 8 no momento en que se escribe este artigo (EmberZnet 6.8).
Dado que o formato da trama EZSP pode ser diferente entre as diferentes versións, existe un requisito obrigatorio que o servidor e o NCPDEBEtraballar coa mesma versión de EZSP. Se non, non se poden comunicar 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 recuperar a versión EZSP do NCP antes de calquera outra comunicación. Se a versión EZSP é diferente da versión EZSP do lado do host, a comunicación debe ser abortada.
O requisito implícito disto é que o formato do comando de versión poidaNUNCA CAMBIESO formato do comando da versión EZSP é o seguinte:
链接: https://zhuanlan.zhihu.com/p/339700391
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注椎出出
2.2. Aleatorización de datos
O proceso detallado de aleatorización descríbese na sección 4.3 da UG101. Todo o marco EZSP será aleatorizado. A aleatorización faise mediante unha operación OR exclusiva entre o marco EZSP e unha secuencia pseudoaleatoria.
A continuación móstrase o algoritmo para xerar unha secuencia pseudoaleatoria.
- 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. Engadir o byte de control
O byte de control é un dato dun byte e debe engadirse á cabeceira da trama. O formato ilústrase na táboa seguinte:
En total, hai 6 tipos de bytes de control. Os tres primeiros úsanse para tramas comúns con datos EZSP, incluíndo DATA, ACK e NAK. Os tres últimos úsanse sen datos EZSP comúns, incluíndo RST, RSTACK e ERROR.
O formato de RST, RSTACK e ERROR descríbese nas seccións 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 CRCCCITT estándar (g(x) = x16 + x12 + x5 + 1) inicialízase a 0xFFFF. O byte máis significativo precede ao byte menos significativo (modo big-endian).
2.5. Recheo de bytes
Como se describe na sección 4.2 da UG101, hai algúns valores de bytes reservados que se usan para fins especiais. Estes valores pódense atopar na seguinte táboa:
Cando estes valores aparezan na trama, aplicarase un tratamento especial aos datos. – Inserir o byte de escape 0x7D diante do byte reservado – Inverter o bit5 dese byte reservado
A continuación móstranse algúns exemplos deste algoritmo:
2.6. Engadir o indicador de fin
O paso final é engadir o indicador de fin 0x7E ao final da trama. Despois diso, os datos pódense enviar ao porto UART.
3. Proceso de desencadre
Cando se reciben datos do UART, só precisamos facer os pasos inversos para decodificalos.
4. Referencias
Data de publicación: 08-02-2022