Autore: TorchIoTBootCamp
Collegamento: https://zhuanlan.zhihu.com/p/339700391
Da: Quora
1. Introduzione
Silicon Labs ha offerto una soluzione host+NCP per la progettazione di gateway Zigbee. In questa architettura, l'host può comunicare con l'NCP tramite interfaccia UART o SPI. Più comunemente si utilizza l'UART perché è molto più semplice dell'SPI.
Silicon Labs ha inoltre fornito un progetto di esempio per il programma host, che è il campioneZ3GatewayHostL'esempio viene eseguito su un sistema di tipo Unix. Alcuni clienti potrebbero desiderare un esempio host compatibile con un RTOS, ma purtroppo al momento non esiste un esempio host basato su RTOS. Gli utenti devono sviluppare il proprio programma host basato su RTOS.
È importante comprendere il protocollo del gateway UART prima di sviluppare un programma host personalizzato. Sia per i moduli NCP basati su UART che per quelli basati su SPI, l'host utilizza il protocollo EZSP per comunicare con il modulo NCP.EZSPè l'abbreviazione diProtocollo seriale EmberZnete viene definito inUG100. Per NCP basato su UART, viene implementato un protocollo di livello inferiore per trasportare i dati EZSP in modo affidabile su UART, cioè ilCENEREprotocollo, abbreviazione diHost seriale asincronoPer maggiori dettagli su ASH, si prega di fare riferimento aUG101EUG115.
La relazione tra EZSP e ASH può essere illustrata dal seguente diagramma:
Il formato dei dati dei protocolli EZSP e ASH può essere illustrato dal seguente diagramma:
In questa pagina, illustreremo il processo di incapsulamento dei dati UART e alcuni frame chiave frequentemente utilizzati nei gateway Zigbee.
2. Inquadratura
Il processo generale di incorniciatura può essere illustrato dal seguente schema:
In questo grafico, i dati si riferiscono al frame EZSP. In generale, i processi di inquadramento sono: |No|Passaggio|Riferimento|
|:-|:-|:-|
|1|Compilare il modulo EZSP|UG100|
|2|Randomizzazione dei dati|Sezione 4.3 di UG101|
|3|Aggiungere il byte di controllo|Capitolo 2 e Capitolo 3 di UG101|
|4|Calcolare il CRC|Sezione 2.3 di UG101|
|5|Byte Stuffing|Sezione 4.2 di UG101|
|6|Aggiungere il flag di fine|Sezione 2.4 di UG101|
2.1. Compilare il modulo EZSP
Il formato del frame EZSP è illustrato nel capitolo 3 di UG100.
Tieni presente che questo formato potrebbe cambiare con gli aggiornamenti dell'SDK. Quando il formato cambia, gli assegneremo un nuovo numero di versione. L'ultima versione di EZSP al momento della stesura di questo articolo è la 8 (EmberZnet 6.8).
Poiché il formato del frame EZSP può essere diverso tra le diverse versioni, esiste un requisito obbligatorio che l'host e l'NCPDOVEREDevono utilizzare la stessa versione di EZSP. In caso contrario, la comunicazione non avverrà come previsto.
Per raggiungere questo obiettivo, il primo comando tra l'host e l'NCP deve essere il comando di versione. In altre parole, l'host deve recuperare la versione EZSP dell'NCP prima di qualsiasi altra comunicazione. Se la versione EZSP è diversa dalla versione EZSP dell'host, la comunicazione deve essere interrotta.
Il requisito implicito alla base di ciò è che il formato del comando di versione puòNON CAMBIARE MAIIl formato del comando della versione EZSP è il seguente:
链接：https://zhuanlan.zhihu.com/p/339700391
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
2.2. Randomizzazione dei dati
Il processo di randomizzazione dettagliato è descritto nella sezione 4.3 di UG101. L'intero frame EZSP verrà randomizzato. La randomizzazione consiste nell'eseguire un'operazione OR esclusivo tra il frame EZSP e una sequenza pseudo-casuale.
Di seguito è riportato l'algoritmo per la generazione della sequenza pseudo-casuale.
- rand0 = 0×42
- se il bit 0 di randi è 0, randi+1 = randi >> 1
- se il bit 0 di randi è 1, randi+1 = (randi >> 1) ^ 0xB8
2.3. Aggiungere il byte di controllo
Il byte di controllo è un dato di un byte e deve essere aggiunto all'inizio del frame. Il formato è illustrato nella tabella seguente:
In totale, ci sono 6 tipi di byte di controllo. I primi tre vengono utilizzati per i frame comuni con dati EZSP, ovvero DATA, ACK e NAK. Gli ultimi tre vengono utilizzati senza dati EZSP comuni, ovvero RST, RSTACK e ERROR.
Il formato di RST, RSTACK ed ERROR è descritto nelle sezioni da 3.1 a 3.3.
2.4. Calcolare il CRC
Il CRC a 16 bit viene calcolato sui byte dal byte di controllo fino alla fine dei dati. Il CRCCCITT standard (g(x) = x16 + x12 + x5 + 1) viene inizializzato a 0xFFFF. Il byte più significativo precede il byte meno significativo (modalità big-endian).
2.5. Byte Stuffing
Come descritto nella sezione 4.2 di UG101, esistono alcuni valori di byte riservati utilizzati per scopi specifici. Questi valori sono riportati nella tabella seguente:
Quando questi valori appaiono nel frame, verrà eseguito un trattamento speciale sui dati. – Inserire il byte di escape 0x7D davanti al byte riservato – Invertire il bit 5 di quel byte riservato
Di seguito sono riportati alcuni esempi di questo algoritmo:
2.6. Aggiungere il flag di fine
L'ultimo passaggio consiste nell'aggiungere il flag di fine 0x7E alla fine del frame. Dopodiché, i dati possono essere inviati alla porta UART.
3. Processo di de-framing
Quando i dati vengono ricevuti dalla UART, dobbiamo semplicemente eseguire i passaggi inversi per decodificarli.
4. Riferimenti
Data di pubblicazione: 8 febbraio 2022