Autore:TorchIoTBootCamp
Collegamento: https://zhuanlan.zhihu.com/p/339700391
Da: Quora
1. Introduzione
Silicon Labs ha offerto una soluzione host+NCP per la progettazione del gateway Zigbee. In questa architettura, l'host può comunicare con l'NCP tramite l'interfaccia UART o SPI. Più comunemente, viene utilizzato UART poiché è molto più semplice di SPI.
Silicon Labs ha fornito anche un progetto di esempio per il programma host, ovvero l'esempioZ3GatewayHost. L'esempio viene eseguito su un sistema simile a Unix. Alcuni clienti potrebbero desiderare un campione di host che possa essere eseguito su un RTOS, ma sfortunatamente per il momento non esiste un campione 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 l'NCP basato su UART che per l'NCP basato su SPI, l'host utilizza il protocollo EZSP per comunicare con l'NCP.EZSPè l'abbreviazione diProtocollo seriale EmberZnet, ed è definito inUG100. Per NCP basato su UART, viene implementato un protocollo di livello inferiore per trasportare i dati EZSP in modo affidabile su UART, questo è ilCENEREprotocollo, abbreviazione diHost seriale asincrono. Per ulteriori dettagli su ASH, fare riferimento aUG101EUG115.
La relazione tra EZSP e ASH può essere illustrata dal seguente diagramma:
Il formato dei dati dell'EZSP e del protocollo ASH può essere illustrato dal seguente diagramma:
In questa pagina introdurremo il processo di framing dei dati UART e alcuni fotogrammi chiave che vengono frequentemente utilizzati nel gateway Zigbee.
2. Inquadratura
Il processo generale di inquadramento può essere illustrato dal seguente grafico:
In questo grafico, i dati indicano il frame EZSP. In generale, i processi di framing sono: |No|Passo|Riferimento|
|:-|:-|:-|
|1|Riempi il telaio EZSP|UG100|
|2|Randomizzazione dei dati|Sezione 4.3 di UG101|
|3|Aggiungi il byte di controllo|Cap2 e Chap3 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. Riempi il riquadro EZSP
Il formato del frame EZSP è illustrato nel capitolo 3 di UG100.
Tieni presente che questo formato potrebbe cambiare durante l'aggiornamento dell'SDK. Quando il formato cambia, gli assegneremo un nuovo numero di versione. L'ultimo numero di versione EZSP è 8 al momento della stesura di questo articolo (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'NCPDOVEREfunzionare con la stessa versione EZSP. Altrimenti, non possono comunicare come previsto.
Per raggiungere questo obiettivo, il primo comando tra l'host e l'NCP deve essere il comando della 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 del lato host, la comunicazione deve essere interrotta.
Il requisito implicito dietro questo è che il formato del comando versione possaNON CAMBIARE MAI. Il 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 prevede l'OR esclusivo del frame EZSP e di 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. Aggiungi il byte di controllo
Il byte di controllo è un byte di dati e deve essere aggiunto all'inizio del frame. Il formato è illustrato con la 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. Calcolare 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 su 0xFFFF. Il byte più significativo precede il byte meno significativo (modalità big-endian).
2.5. Ripieno di byte
Come descritto nella sezione 4.2 di UG101, ci sono alcuni valori di byte riservati utilizzati per scopi speciali. Questi valori possono essere trovati nella seguente tabella:
Quando questi valori compaiono nel riquadro, verrà fatto un trattamento speciale ai dati. – Inserisci il byte di escape 0x7D davanti al byte riservato – Inverti il bit5 di quel byte riservato
Di seguito sono riportati alcuni esempi di questo algoritmo:
2.6. Aggiungi il flag di fine
Il passaggio finale consiste nell'aggiungere il flag di fine 0x7E alla fine del frame. Successivamente, i dati possono essere inviati alla porta UART.
3. Processo di de-inquadramento
Quando i dati vengono ricevuti dall'UART, dobbiamo solo eseguire i passaggi inversi per decodificarli.
4. Riferimenti
Orario di pubblicazione: 08-febbraio-2022