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 a través de una interfaz UART o SPI. Lo más común es que se utilice UART, ya que es mucho más simple que SPI.
Silicon Labs también ha proporcionado un proyecto de muestra para el programa anfitrión, que es la muestraZ3GatewayHost. El ejemplo se ejecuta en un sistema tipo Unix. Es posible que algunos clientes quieran una muestra de host que pueda ejecutarse en un RTOS, pero desafortunadamente, por el momento no existe una muestra de host basada en RTOS. Los usuarios deben desarrollar su propio programa host basado en RTOS.
Es importante comprender el protocolo de puerta de enlace UART antes de desarrollar un programa de host personalizado. Tanto para el NCP basado en UART como para el NCP basado en SPI, el host utiliza el protocolo EZSP para comunicarse con el NCP.EZSPes corto paraProtocolo serie EmberZnet, y se define enUG100. Para NCP basado en UART, se implementa un protocolo de capa inferior para transportar datos EZSP de manera confiable a través de UART, ese es elCENIZAprotocolo, abreviatura deHost serie asíncrono. Para obtener más detalles sobre ASH, consulteUG101yUG115.
La relación entre EZSP y ASH se puede ilustrar con el siguiente diagrama:
El formato de datos del EZSP y el protocolo ASH se puede ilustrar con el siguiente diagrama:
En esta página, presentaremos el proceso de enmarcar los datos UART y algunos fotogramas clave que se utilizan con frecuencia en la puerta de enlace Zigbee.
2. Encuadre
El proceso de formulación general se puede ilustrar con el siguiente cuadro:
En este gráfico, los datos significan el marco EZSP. En general, los procesos de encuadre son: |No|Paso|Referencia|
|:-|:-|:-|
|1|Rellene el marco EZSP|UG100|
|2|Aleatorización de datos|Sección 4.3 de UG101|
|3|Agregue el byte de control|Chap2 y Chap3 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 de fin|Sección 2.4 de UG101|
2.1. Llene el marco EZSP
El formato de trama EZSP se ilustra en el Capítulo 3 de UG100.
Preste atención a que este formato puede cambiar cuando se actualiza el SDK. Cuando el formato cambie, le daremos un nuevo número de versión. El número de versión más reciente de EZSP es 8 cuando se escribe este artículo (EmberZnet 6.8).
Como el formato de trama EZSP puede ser diferente entre las distintas versiones, existe un requisito obligatorio de que el host y el NCPDEBETrabajar con la misma versión de EZSP. De lo contrario, no podrán comunicarse como se esperaba.
Para lograrlo, el primer comando entre el host y el NCP debe ser el comando de versión. En otras palabras, el anfitrión debe recuperar la versión EZSP del NCP antes de cualquier otra comunicación. Si la versión de EZSP es diferente a la versión de EZSP del lado del host, se debe cancelar la comunicación.
El requisito implícito detrás de esto es que el formato del comando de versión puedeNUNCA CAMBIE. El 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 de aleatorización detallado se describe en la sección 4.3 de UG101. Todo el cuadro EZSP será aleatorio. La aleatorización es exclusiva O el 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. Agregue el byte de control
El byte de control es un dato de un byte y debe agregarse al encabezado de la trama. El formato se ilustra con la siguiente tabla:
En total, existen 6 tipos de bytes de control. Los primeros tres se utilizan para tramas comunes con datos EZSP, incluidos DATA, ACK y NAK. Los últimos tres se utilizan sin datos EZSP comunes, incluidos RST, RSTACK y ERROR.
El formato de RST, RSTACK y ERROR se describe en las secciones 3.1 a 3.3.
2.4. Calcular el CRC
Un CRC de 16 bits se calcula 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 byte menos significativo (modo big-endian).
2.5. Relleno de bytes
Como se describe en la sección 4.2 de UG101, hay algunos valores de bytes reservados que se utilizan para fines especiales. Estos valores se pueden encontrar en la siguiente tabla:
Cuando estos valores aparezcan en el marco, se le hará un tratamiento especial a los datos. – Insertar el byte de escape 0x7D delante del byte reservado – Invertir el bit5 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 del marco. Después de eso, los datos se pueden enviar al puerto UART.
3. Proceso de desencuadre
Cuando se reciben datos del UART, solo necesitamos realizar los pasos inversos para decodificarlos.
4. Referencias
Hora de publicación: 08-feb-2022