Аб Zigbee EZSP UART

Аўтар:TorchIoTBootCamp
Спасылка: https://zhuanlan.zhihu.com/p/339700391
Ад: Quora

1. Уводзіны

Silicon Labs прапанавала рашэнне host+NCP для праектавання шлюза Zigbee. У гэтай архітэктуры хост можа ўзаемадзейнічаць з NCP праз інтэрфейс UART або SPI. Часцей за ўсё UART выкарыстоўваецца, бо ён значна прасцейшы за SPI.

Silicon Labs таксама прадаставіла ўзор праекта для асноўнай праграмы, які з'яўляецца ўзорамZ3GatewayHostПрыклад працуе на Unix-падобнай сістэме. Некаторым кліентам можа спатрэбіцца прыклад хоста, які можа працаваць на RTOS, але, на жаль, пакуль што няма прыкладу хоста на базе RTOS. Карыстальнікам трэба распрацаваць уласную праграму хоста на базе RTOS.

Перад распрацоўкай карыстальніцкай праграмы для хоста важна зразумець пратакол шлюза UART. Як для NCP на базе UART, так і для NCP на базе SPI хост выкарыстоўвае пратакол EZSP для сувязі з NCP.EZSPскарочана адПаслядоўны пратакол EmberZnet, і гэта вызначана ўUG100Для NCP на базе UART рэалізаваны пратакол ніжняга ўзроўню для надзейнай перадачы дадзеных EZSP праз UART, гэта значыцьПОПЕЛЬпратакол, скарочана адАсінхронны паслядоўны хостБольш падрабязную інфармацыю пра ASH глядзіце ўUG101іUG115.

Сувязь паміж EZSP і ASH можна праілюстраваць наступнай дыяграмай:

1

Фармат дадзеных пратаколаў EZSP і ASH можна праілюстраваць наступнай дыяграмай:

2

На гэтай старонцы мы прадставім працэс кадравання дадзеных UART і некаторыя ключавыя кадры, якія часта выкарыстоўваюцца ў шлюзе Zigbee.

2. Афармленне

Агульны працэс фарміравання кадра можна праілюстраваць наступнай дыяграмай:

3

У гэтай дыяграме дадзеныя азначаюць кадр EZSP. У цэлым, працэсы кадравання наступныя: |Няма|Крок|Спасылка|

|:-|:-|:-|

|1|Запоўніце рамку EZSP|UG100|

|2|Рандомізацыя дадзеных|Раздзел 4.3 UG101|

|3|Дадаць кіруючы байт|Chap2 і Chap3 з UG101|

|4|Разлічыць CRC|Раздзел 2.3 UG101|

|5|Запаўненне байтамі|Раздзел 4.2 UG101|

|6|Дадаць сцяжок канца|Раздзел 2.4 UG101|

2.1. Запоўніце рамку EZSP

Фармат кадра EZSP праілюстраваны ў главе 3 UG100.

4

Звярніце ўвагу, што гэты фармат можа змяніцца пры абнаўленні SDK. Пры змене фармату мы прысвоім яму новы нумар версіі. На момант напісання гэтага артыкула апошні нумар версіі EZSP — 8 (EmberZnet 6.8).

Паколькі фармат кадра EZSP можа адрознівацца ў розных версіях, існуе абавязковае патрабаванне, каб хост і NCPАБАВЯЗКОВАпрацаваць з адной і той жа версіяй EZSP. У адваротным выпадку яны не змогуць мець зносіны належным чынам.

Каб дасягнуць гэтага, першай камандай паміж хостам і NCP павінна быць каманда версіі. Іншымі словамі, хост павінен атрымаць версію EZSP NCP перад любой іншай сувяззю. Калі версія EZSP адрозніваецца ад версіі EZSP на баку хоста, сувязь павінна быць перапынена.

Імпліцытным патрабаваннем гэтага з'яўляецца тое, што фармат каманды версіі можаНІКОЛІ НЕ МЯНЯЙСЯФармат каманды версіі EZSP наступны:

5

Тлумачэнні поля параметра і фармату адказу аб версіі можна знайсці ў главе 4 дакумента UG100. Поле параметра — гэта версія EZSP хост-праграмы. На момант напісання гэтага артыкула гэта была версія 8.
7
作者: TorchIoTBootCamp
链接: https://zhuanlan.zhihu.com/p/339700391
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

2.2. Рандомізацыя дадзеных

Падрабязны працэс рандомізацыі апісаны ў раздзеле 4.3 UG101. Увесь кадр EZSP будзе рандомізаваны. Рандомізацыя праводзіцца шляхам аперацыі "выключальнае АБО" паміж кадрам EZSP і псеўдавыпадковай паслядоўнасцю.

Ніжэй прыведзены алгарытм генерацыі псеўдавыпадковай паслядоўнасці.

  • выпадковы0 = 0×42
  • калі біт 0 randi роўны 0, randi+1 = randi >> 1
  • калі біт 0 randi роўны 1, randi+1 = (randi >> 1) ^ 0xB8

2.3. Дадаць кіруючы байт

Кіруючы байт — гэта аднабайтавыя дадзеныя, якія трэба дадаць у загаловак кадра. Фармат паказаны ў табліцы ніжэй:

6

Усяго існуе 6 тыпаў кіруючых байтаў. Першыя тры выкарыстоўваюцца для агульных кадраў з дадзенымі EZSP, у тым ліку DATA, ACK і NAK. Апошнія тры выкарыстоўваюцца без агульных дадзеных EZSP, у тым ліку RST, RSTACK і ERROR.

Фармат RST, RSTACK і ERROR апісаны ў раздзелах 3.1–3.3.

2.4. Разлічыце CRC

16-бітны CRC вылічваецца для байтаў ад кантрольнага байта да канца дадзеных. Стандартны CRCCCITT (g(x) = x16 + x12 + x5 + 1) ініцыялізуецца як 0xFFFF. Найбольш значны байт папярэднічае найменш значнаму байту (рэжым big-endian).

2.5. Запаўненне байтамі

Як апісана ў раздзеле 4.2 UG101, існуюць некаторыя зарэзерваваныя значэнні байтаў, якія выкарыстоўваюцца для спецыяльных мэтаў. Гэтыя значэнні можна знайсці ў наступнай табліцы:

7

Калі гэтыя значэнні з'яўляюцца ў кадры, да дадзеных будзе прыменена спецыяльная апрацоўка. – Устаўка escape-байта 0x7D перад зарэзерваваны байтам – Інвертаванне біта 5 гэтага зарэзерваванага байта

Ніжэй прыведзены некаторыя прыклады гэтага алгарытму:

8

2.6. Дадаць сцяжок канца

Апошні крок — дадаць сцяжок канца 0x7E ў канец кадра. Пасля гэтага дадзеныя можна адпраўляць на порт UART.

3. Працэс дэфреймінгу

Калі дадзеныя атрымліваюцца ад UART, нам проста трэба выканаць зваротныя крокі для іх дэкадавання.

4. Спасылкі


Час публікацыі: 8 лютага 2022 г.
Інтэрнэт-чат у WhatsApp!