Tentang Zigbee Ezsp Uart

Penulis ： Torchiotbootcamp
Tautan ： https: //zhuanlan.zhihu.com/p/339700391
Dari ： Quora

1. Pendahuluan

Silicon Labs telah menawarkan solusi host+NCP untuk desain gateway ZigBee. Dalam arsitektur ini, tuan rumah dapat berkomunikasi dengan NCP melalui antarmuka UART atau SPI. Paling umum, UART digunakan karena jauh lebih sederhana daripada SPI.

Silicon Labs juga telah menyediakan proyek sampel untuk program host, yang merupakan sampelZ3GatewayHost. Sampel berjalan pada sistem seperti Unix. Beberapa pelanggan mungkin menginginkan sampel host yang dapat berjalan pada RTOS, tetapi sayangnya, tidak ada sampel host berbasis RTOS untuk saat ini. Pengguna perlu mengembangkan program host mereka sendiri berdasarkan RTO.

Penting untuk memahami protokol gateway UART sebelum mengembangkan program host yang disesuaikan. Untuk NCP NCP dan SPI berbasis UART, host menggunakan protokol EZSP untuk berkomunikasi dengan NCP.EZSPkependekan dariProtokol Serial Emberznet, dan didefinisikanUG100. Untuk NCP berbasis UART, protokol lapisan bawah diimplementasikan untuk membawa data EZSP secara andal di atas UART, itu adalahABUprotokol, kependekan dariHost serial asinkron. Untuk detail lebih lanjut tentang Ash, silakan merujuk keUG101DanUG115.

Hubungan antara EZSP dan Ash dapat diilustrasikan dengan diagram berikut:

Format data EZSP dan protokol abu dapat diilustrasikan dengan diagram berikut:

Di halaman ini, kami akan memperkenalkan proses membingkai data UART dan beberapa bingkai kunci yang sering digunakan di zigbee gateway.

2. Bingkai

Proses pembingkaian umum dapat diilustrasikan oleh bagan berikut:

Dalam bagan ini, data berarti bingkai EZSP. Secara umum, proses pembingkaian adalah: | Tidak | Langkah | Referensi |

|:-|:-|:-|

| 1 | Isi bingkai EZSP | UG100 |

| 2 | Pengacakan Data | Bagian 4.3 dari UG101 |

| 3 | Tambahkan Byte Kontrol | Chap2 dan Chap3 dari UG101 |

| 4 | Hitung CRC | Bagian 2.3 dari UG101 |

| 5 | Byte isian | Bagian 4.2 dari UG101 |

| 6 | Tambahkan Bendera Akhir | Bagian 2.4 dari UG101 |

2.1. Isi bingkai EZSP

Format bingkai EZSP diilustrasikan dalam Bab 3 dari UG100.

Perhatikan bahwa format ini dapat berubah ketika SDK meningkatkan. Ketika format berubah, kami akan memberikan nomor versi baru. Nomor versi EZSP terbaru adalah 8 ketika artikel ini ditulis (Emberznet 6.8).

Karena format bingkai EZSP mungkin berbeda antara versi yang berbeda, ada persyaratan wajib bahwa host dan NCPHARUSBekerja dengan versi EZSP yang sama. Kalau tidak, mereka tidak dapat berkomunikasi seperti yang diharapkan.

Untuk mencapai itu, perintah pertama antara host dan NCP harus menjadi perintah versi. Dengan kata lain, host harus memadamkan versi EZSP dari NCP sebelum komunikasi lainnya. Jika versi EZSP berbeda dengan versi EZSP dari sisi host, komunikasi harus dibatalkan.

Persyaratan implisit di balik ini adalah bahwa format perintah versi dapatTidak pernah berubah. Format perintah versi EZSP seperti di bawah ini:

Penjelasan bidang parameter dan format respons versi dapat ditemukan di Bab 4 dari UG100. Bidang parameter adalah versi EZSP dari program host. Ketika artikel ini ditulis, ini 8.

作者： Torchiotbootcamp
链接： https: //zhuanlan.zhihu.com/p/339700391
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

2.2. Pengacakan data

Proses pengacakan terperinci dijelaskan dalam Bagian 4.3 dari UG101. Seluruh bingkai EZSP akan diacak. Pengacakan adalah untuk eksklusif-atau bingkai EZSP dan urutan pseudo-acak.

Di bawah ini adalah algoritma menghasilkan urutan pseudo-acak.

Rand0 = 0 × 42
Jika bit 0 dari Randi adalah 0, randi+1 = randi >> 1
Jika bit 0 dari Randi adalah 1, randi+1 = (randi >> 1) ^ 0xb8

2.3. Tambahkan byte kontrol

Byte kontrol adalah data satu byte, dan harus ditambahkan ke kepala bingkai. Format diilustrasikan dengan tabel di bawah ini:

Benar -benar, ada 6 jenis byte kontrol. Tiga yang pertama digunakan untuk bingkai umum dengan data EZSP, termasuk data, ACK dan NAK. Tiga terakhir digunakan tanpa data EZSP umum, termasuk RST, RSTACK dan kesalahan.

Format RST, RSTACK dan kesalahan dijelaskan dalam Bagian 3.1 hingga 3.3.

2.4. Hitung CRC

CRC 16-bit dihitung pada byte dari byte kontrol hingga akhir data. CRCCCITT standar (g (x) = x16 + x12 + x5 + 1) diinisialisasi ke 0xFFFF. Byte yang paling signifikan mendahului byte yang paling tidak signifikan (mode besar-endian).

2.5. Byte isian

Seperti yang dijelaskan dalam Bagian 4.2 dari UG101, ada beberapa nilai byte yang dipesan yang digunakan untuk tujuan khusus. Nilai -nilai ini dapat ditemukan di tabel berikut:

Ketika nilai -nilai ini muncul dalam bingkai, perawatan khusus akan dilakukan pada data. - Masukkan Byte Escape 0x7d di depan byte yang dipesan - membalikkan bit5 dari byte yang dipesan

Di bawah ini adalah beberapa contoh algoritma ini: