Autor: TorchIoTBootCamp
Enlace: https://zhuanlan.zhihu.com/p/339700391
De: Quora
1. Introducción
Silicon Labs ha ofrecido una solución host+NCP para el diseño de puertas de enlace Zigbee. En esta arquitectura, el host puede comunicarse con el NCP mediante una interfaz UART o SPI. El uso más común es UART, ya que es mucho más sencillo que SPI.
Silicon Labs también ha proporcionado un proyecto de muestra para el programa anfitrión, que es el proyecto de muestra.Host de puerta de enlace Z3La muestra se ejecuta en un sistema tipo Unix. Algunos clientes podrían querer una muestra de host compatible con un RTOS, pero lamentablemente, por el momento no existe una muestra de host basada en RTOS. Los usuarios deben desarrollar su propio programa de host basado en RTOS.
Es importante comprender el protocolo de puerta de enlace UART antes de desarrollar un programa host personalizado. Tanto para los NCP basados en UART como en SPI, el host utiliza el protocolo EZSP para comunicarse con el NCP.EZSPes la abreviatura deProtocolo serial EmberZnet, y se define enUG100Para el NCP basado en UART, se implementa un protocolo de capa inferior para transportar datos EZSP de manera confiable a través de UART, que es elCENIZAprotocolo, abreviatura deHost serie asíncronoPara obtener más detalles sobre ASH, consulteUG101yUG115.
La relación entre EZSP y ASH se puede ilustrar mediante el siguiente diagrama:
El formato de datos del protocolo EZSP y ASH se puede ilustrar mediante el siguiente diagrama:
En esta página, presentaremos el proceso de encuadre de los datos UART y algunos fotogramas clave que se utilizan con frecuencia en la puerta de enlace Zigbee.
2. Enmarcado
El proceso general de encuadre se puede ilustrar mediante el siguiente gráfico:
En este gráfico, los datos corresponden al marco EZSP. En general, los procesos de encuadre son: |No|Paso|Referencia|
|:-|:-|:-|
|1|Llene el marco EZSP|UG100|
|2|Aleatorización de datos|Sección 4.3 de UG101|
|3|Agregar el byte de control|Capítulo 2 y Capítulo 3 de UG101|
|4|Calcular el CRC|Sección 2.3 de UG101|
|5|Relleno de bytes|Sección 4.2 de UG101|
|6|Agregar la bandera final|Sección 2.4 de UG101|
2.1. Rellenar el marco EZSP
El formato de marco EZSP se ilustra en el capítulo 3 de UG100.
Tenga en cuenta que este formato puede cambiar al actualizar el SDK. Cuando el formato cambie, le asignaremos un nuevo número de versión. La versión más reciente de EZSP es la 8 al momento de escribir este artículo (EmberZnet 6.8).
Como el formato del marco EZSP puede ser diferente entre distintas versiones, existe un requisito obligatorio de que el host y el NCPDEBETrabajan con la misma versión de EZSP. De lo contrario, no podrán comunicarse como se espera.
Para lograrlo, el primer comando entre el host y el NCP debe ser el comando de versión. En otras palabras, el host debe obtener la versión EZSP del NCP antes de cualquier otra comunicación. Si la versión EZSP difiere de la versión EZSP del host, la comunicación debe interrumpirse.
El requisito implícito detrás de esto es que el formato del comando de versión puedaNUNCA CAMBIESEl formato del comando de la versión EZSP es el siguiente:
链接: https://zhuanlan.zhihu.com/p/339700391
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处.
2.2. Aleatorización de datos
El proceso detallado de aleatorización se describe en la sección 4.3 de UG101. Se aleatorizará todo el marco EZSP. La aleatorización consiste en aplicar OR exclusivo al marco EZSP y una secuencia pseudoaleatoria.
A continuación se muestra el algoritmo para generar la secuencia pseudoaleatoria.
- rand0 = 0×42
- si el bit 0 de randi es 0, randi+1 = randi >> 1
- si el bit 0 de randi es 1, randi+1 = (randi >> 1) ^ 0xB8
2.3. Agregar el byte de control
El byte de control es un dato de un byte y debe añadirse al encabezado de la trama. El formato se ilustra en la tabla a continuación:
En total, hay 6 tipos de bytes de control. Los tres primeros se utilizan para tramas comunes con datos EZSP, como DATA, ACK y NAK. Los tres últimos se utilizan sin datos EZSP comunes, como RST, RSTACK y ERROR.
El formato de RST, RSTACK y ERROR se describen en las secciones 3.1 a 3.3.
2.4. Calcular el CRC
Se calcula un CRC de 16 bits en bytes desde el byte de control hasta el final de los datos. El CRCCCITT estándar (g(x) = x16 + x12 + x5 + 1) se inicializa a 0xFFFF. El byte más significativo precede al menos significativo (modo big-endian).
2.5. Relleno de bytes
Como se describe en la sección 4.2 de UG101, existen algunos valores de byte reservados para fines específicos. Estos valores se pueden encontrar en la siguiente tabla:
Cuando estos valores aparecen en el marco, se realizará un tratamiento especial a los datos. – Insertar el byte de escape 0x7D delante del byte reservado – Invertir el bit 5 de ese byte reservado
A continuación se muestran algunos ejemplos de este algoritmo:
2.6. Agregar la bandera de fin
El último paso es agregar el indicador de fin 0x7E al final de la trama. Después, los datos pueden enviarse al puerto UART.
3. Proceso de desenmarcado
Cuando recibimos datos del UART, solo tenemos que realizar los pasos inversos para decodificarlos.
4. Referencias
Hora de publicación: 08-feb-2022