Autore ： TorchiotBootCamp
Link ： https: //zhuanlan.zhihu.com/p/339700391
Da ： Quora
1. Introduzione
Silicon Labs ha offerto una soluzione host+NCP per Zigbee Gateway Design. In questa architettura, l'host può comunicare con il PCN tramite interfaccia UART o SPI. Più comunemente, l'UART viene utilizzato in quanto è molto più semplice di SPI.
Silicon Labs ha anche fornito un progetto di esempio per il programma host, che è il campioneZ3gatewayhost. Il campione funziona su un sistema simile a Unix. Alcuni clienti potrebbero desiderare un campione host che può essere eseguito su un RTOS, ma sfortunatamente non esiste un campione host basato su RTO per il momento. Gli utenti devono sviluppare il proprio programma host basato su RTOS.
È importante comprendere il protocollo UART Gateway prima di sviluppare un programma host personalizzato. Sia NCP basato su NCP e SPI, l'host utilizza il protocollo EZSP per comunicare con l'NCP.EZSPè breve perProtocollo 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, breve perOspite seriale asincrono. Per maggiori dettagli su Ash, fare riferimento aUG101EUg115.
La relazione tra EZSP e cenere può essere illustrata dal seguente diagramma:
Il formato dei dati dell'EZSP e del protocollo di cenere può essere illustrato dal seguente diagramma:
In questa pagina, introdurremo il processo di inquadratura dei dati UART e alcuni fotogrammi chiave che sono spesso utilizzati in Zigbee Gateway.
2. Inquadratura
Il processo di inquadratura generale può essere illustrato dal seguente grafico:
In questo grafico, i dati indicano il frame EZSP. In generale, i processi di inquadratura sono: | No | Step | Riferimento |
|:-|:-|:-|
| 1 | Riempi il telaio EZSP | UG100 |
| 2 | Randomizzazione dei dati | Sezione 4.3 di UG101 |
| 3 | Aggiungi il byte di controllo | Chap2 e Chap3 di Ug101 |
| 4 | Calcola il CRC | Sezione 2.3 di UG101 |
| 5 | Pieno byte | Sezione 4.2 di UG101 |
| 6 | Aggiungi la bandiera finale | Sezione 2.4 di UG101 |
2.1. Riempi il telaio EZSP
Il formato del frame EZSP è illustrato nel Cap 3 di UG100.
Presta attenzione che questo formato può cambiare quando l'SDK si aggiorna. Quando il formato cambia, gli daremo un nuovo numero di versione. L'ultimo numero di versione EZSP è 8 quando questo articolo è scritto (Emberznet 6.8).
Poiché il formato del frame EZSP può essere diverso tra le diverse versioni, esiste un requisito obbligatorio che l'host e il PCNDOVERElavorare 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 reggere la versione EZSP dell'NCP prima di qualsiasi altra comunicazione. Se la versione EZSP è diversa con la versione EZSP del lato host, la comunicazione deve essere abortita.
Il requisito implicito alla base di ciò è che il formato del comando della versione puòNon cambiare mai. Il formato del comando della versione EZSP è come sotto:
链接 ： 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 è quella di esclusiva o la cornice EZSP e una sequenza pseudo-casuale.
Di seguito è riportato l'algoritmo di 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. Aggiungi il byte di controllo
Il byte di controllo è un dati di un byte e dovrebbe essere aggiunto alla testa del frame. Il formato è illustrato con la tabella seguente:
Totalmente, ci sono 6 tipi di byte di controllo. I primi tre vengono utilizzati per frame comuni con dati EZSP, inclusi dati, ACK e NAK. Gli ultimi tre vengono utilizzati senza dati EZSP comuni, inclusi RST, RSTACK ed ERROR.
Il formato di RST, RSTACK e ERROR sono descritti nella Sezione 3.1 a 3.3.
2.4. Calcola il CRC
Un CRC a 16 bit viene calcolato su 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 a scopo speciale. Questi valori possono essere trovati nella tabella seguente:
Quando questi valori compaiono nel frame, ai dati verrà eseguito un trattamento speciale. - Inserire il byte di fuga 0x7d di fronte al byte riservato - Invertire il bit5 di quel byte riservato
Di seguito sono riportati alcuni esempi di questo algoritmo:
2.6. Aggiungi la bandiera finale
Il passaggio finale è quello di aggiungere il flag end 0x7e alla fine del frame. Successivamente, i dati possono essere inviati alla porta UART.
3. Processo di deraming
Quando i dati vengono ricevuti dall'UART, dobbiamo solo eseguire i passaggi inversi per decodificarli.
4. Riferimenti
Tempo post: feb-08-2022