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 la puerta de enlace Zigbee. En esta arquitectura, el host puede comunicarse con la interfaz NCP a través de UART o SPI. Más comúnmente, UART se usa ya que es mucho más simple que SPI.
Silicon Labs también ha proporcionado un proyecto de muestra para el programa host, que es la muestraZ3gatewayhost. La muestra se ejecuta en un sistema similar a UNIX. Algunos clientes pueden querer una muestra de host que pueda ejecutarse en un RTOS, pero desafortunadamente, no hay una muestra de host basada en RTOS por el momento. Los usuarios deben desarrollar su propio programa de host basado en RTO.
Es importante comprender el protocolo UART Gateway antes de desarrollar un programa de host personalizado. Tanto para NCP basado en UART como NCP basado en SPI, el host usa el protocolo EZSP para comunicarse con el NCP.EZSPes corto paraProtocolo de serie de Emberznet, y se define enUG100. Para NCP basado en UART, se implementa un protocolo de capa inferior para llevar datos EZSP de manera confiable a través de UART, ese es elCENIZAprotocolo, corto paraAnfitrión asíncrono. Para obtener más detalles sobre Ash, consulteUG101yUG115.
La relación entre EZSP y Ash puede ilustrarse mediante el siguiente diagrama:
El formato de datos del protocolo EZSP y Ash puede ilustrarse mediante el siguiente diagrama:
En esta página, introduciremos el proceso de enmarcar los datos de UART y algunos marcos clave que se usan con frecuencia en Zigbee Gateway.
2. Marco
El proceso de marco general puede ilustrarse mediante el siguiente cuadro:
En este gráfico, los datos significan el marco EZSP. En general, los procesos de encuadre son: | no | paso | referencia |
|:-|:-|:-|
| 1 | Llena 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 | Calcule el CRC | Sección 2.3 de UG101 |
| 5 | Relleno de bytes | Sección 4.2 de UG101 |
| 6 | Agregue la bandera final | Sección 2.4 de UG101 |
2.1. Llena el marco EZSP
El formato de marco EZSP se ilustra en el Capítulo 3 de UG100.
Preste atención que este formato puede cambiar cuando el SDK se actualiza. Cuando cambia el formato, le daremos un nuevo número de versión. El último número de versión EZSP es 8 cuando se escribe este artículo (Emberznet 6.8).
Como el formato de marco EZSP puede ser diferente entre las diferentes versiones, existe un requisito obligatorio de que el host y el NCPDEBETrabaja con la misma versión EZSP. De lo contrario, no pueden comunicarse como se esperaba.
Para lograr eso, 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 EZSP es diferente con la versión EZSP del lado del host, la comunicación debe ser abortada.
El requisito implícito detrás de esto es que el formato del comando de la versión puedeNunca cambie. El formato de comando de la versión EZSP es como a continuación:
链接 ： 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 marco EZSP será aleatorizado. La aleatorización es exclusiva, o el marco EZSP y una secuencia pseudo-aleatorio.
A continuación se muestra el algoritmo de generar la secuencia pseudo-aleatorio.
- 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 datos de un byte, y debe agregarse a la cabeza del marco. El formato se ilustra con la tabla a continuación:
Totalmente, hay 6 tipos de bytes de control. Los primeros tres se utilizan para marcos comunes con datos EZSP, incluidos datos, ACK y NAK. Los últimos tres se usan sin datos EZSP comunes, incluidos RST, RSTACK y ERROR.
El formato de RST, RSTACK y ERROR se describen en la Sección 3.1 a 3.3.
2.4. Calcule el CRC
Se calcula un CCR 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 byte menos significativo (modo endiano grande).
2.5. Relleno de byte
Como se describe en la Sección 4.2 de UG101, hay algunos valores de byte reservados utilizados para fines especiales. Estos valores se pueden encontrar en la siguiente tabla:
Cuando estos valores aparecen en el marco, se realizará un tratamiento especial a los datos. - Inserte el byte de escape 0x7d frente al byte reservado - invierta el bit5 de ese byte reservado
A continuación se presentan algunos ejemplos de este algoritmo:
2.6. Agregar la bandera final
El paso final es agregar la bandera final 0x7E al final del marco. Después de eso, los datos se pueden enviar al puerto UART.
3. Proceso de desecho
Cuando se reciben datos del UART, solo necesitamos hacer los pasos inversos para decodificarlos.
4. Referencias
Tiempo de publicación: febrero-08-2022