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. UART viene utilizzata più comunemente perché è molto più semplice di SPI.
Silicon Labs ha anche fornito un progetto campione per il programma host, che è il campioneZ3GatewayHostL'esempio funziona su un sistema simile a Unix. Alcuni clienti potrebbero desiderare un esempio di host eseguibile su un sistema operativo in tempo reale (RTOS), ma sfortunatamente al momento non è disponibile alcun esempio di host basato su RTOS. Gli utenti devono sviluppare il proprio programma host basato su RTOS.
È importante comprendere il protocollo gateway UART prima di sviluppare un programma host personalizzato. Sia per NCP basati su UART che per NCP basati su SPI, l'host utilizza il protocollo EZSP per comunicare con l'NCP.EZSPè l'abbreviazione diProtocollo seriale EmberZnet, ed è definito inUG100Per NCP basato su UART, viene implementato un protocollo di livello inferiore per trasportare i dati EZSP in modo affidabile su UART, ovveroCENEREprotocollo, abbreviazione diHost seriale asincronoPer maggiori dettagli su ASH, fare riferimento aUG101EUG115.
La relazione tra EZSP e ASH può essere illustrata dal seguente diagramma:
Il formato dei dati del protocollo EZSP e ASH può essere illustrato dal seguente diagramma:
In questa pagina introdurremo il processo di framing dei dati UART e alcuni frame chiave frequentemente utilizzati nel gateway Zigbee.
2. Inquadratura
Il processo generale di inquadratura può essere illustrato dal seguente grafico:
In questo grafico, i dati si riferiscono al frame EZSP. In generale, i processi di framing sono: |No|Step|Reference|
|:-|:-|:-|
|1|Riempi il frame EZSP|UG100|
|2|Randomizzazione dei dati|Sezione 4.3 di UG101|
|3|Aggiungi il byte di controllo|Cap.2 e Cap.3 di UG101|
|4|Calcola il CRC|Sezione 2.3 di UG101|
|5|Byte Stuffing|Sezione 4.2 di UG101|
|6|Aggiungi il flag di fine|Sezione 2.4 di UG101|
2.1. Riempire il frame EZSP
Il formato del frame EZSP è illustrato nel capitolo 3 di UG100.
Si prega di notare che questo formato potrebbe cambiare con l'aggiornamento dell'SDK. Quando il formato verrà modificato, gli verrà assegnato un nuovo numero di versione. L'ultima versione di EZSP disponibile 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, è obbligatorio che l'host e l'NCPDOVEREfunzionano con la stessa versione di EZSP. Altrimenti, non possono comunicare come previsto.
Per raggiungere questo obiettivo, il primo comando tra l'host e l'NCP deve essere il comando "version". 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 lato host, la comunicazione deve essere interrotta.
Il requisito implicito dietro questo è che il formato del comando di versione possaNON 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 sarà randomizzato. La randomizzazione consiste nell'operazione di OR esclusivo tra il frame EZSP e una sequenza pseudo-casuale.
Di seguito è riportato l'algoritmo per generare la 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'intestazione del frame. Il formato è illustrato nella tabella seguente:
In totale, ci sono 6 tipi di byte di controllo. I primi tre vengono utilizzati per frame comuni con dati EZSP, inclusi DATA, ACK e NAK. Gli ultimi tre vengono utilizzati senza dati EZSP comuni, inclusi RST, RSTACK ed ERROR.
Il formato di RST, RSTACK ed ERROR è descritto nelle sezioni da 3.1 a 3.3.
2.4. Calcola il CRC
Un 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) è inizializzato a 0xFFFF. Il byte più significativo precede il byte meno significativo (modalità big-endian).
2.5. Riempimento di byte
Come descritto nella sezione 4.2 di UG101, alcuni valori di byte riservati vengono utilizzati per scopi specifici. Questi valori sono riportati nella seguente tabella:
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 bit5 di quel byte riservato
Di seguito alcuni esempi di questo algoritmo:
2.6. Aggiungere il flag di fine
Il passaggio finale 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 dall'UART, dobbiamo semplicemente eseguire i passaggi inversi per decodificarli.
4. Riferimenti
Data di pubblicazione: 08-02-2022