Автор：TorchIoTBootCamp
Връзка: https://zhuanlan.zhihu.com/p/339700391
От：Quora
1. Въведение
Silicon Labs предлага решение host+NCP за проектиране на Zigbee gateway. В тази архитектура хостът може да комуникира с NCP чрез UART или SPI интерфейс. Най-често се използва UART, тъй като е много по-лесен от SPI.
Silicon Labs също така предостави примерен проект за хост програмата, който е примерниятZ3GatewayHostПримерът работи на Unix-подобна система. Някои клиенти може да искат примерен хост, който може да работи на RTOS, но за съжаление засега няма примерен хост, базиран на RTOS. Потребителите трябва да разработят своя собствена хост програма, базирана на RTOS.
Важно е да разберете UART gateway протокола, преди да разработите персонализирана хост програма. Както за UART базиран NCP, така и за SPI базиран NCP, хостът използва EZSP протокола за комуникация с NCP.EZSPе съкратено отСериен протокол на EmberZnetи е дефинирано вUG100За NCP, базиран на UART, е реализиран протокол от по-нисък слой за надеждно пренасяне на EZSP данни през UART, това е...ПЕПЕЛпротокол, съкращение отАсинхронен сериен хостЗа повече подробности относно ASH, моля, вижтеUG101иUG115.
Връзката между EZSP и ASH може да бъде илюстрирана със следната диаграма:
Форматът на данните на EZSP и протокола ASH може да бъде илюстриран със следната диаграма:
На тази страница ще представим процеса на рамкиране на UART данните и някои ключови кадри, които често се използват в Zigbee шлюза.
2. Рамкиране
Общият процес на рамкиране може да бъде илюстриран със следната диаграма:
В тази диаграма данните означават EZSP кадъра. Като цяло, процесите на кадриране са: |Без|Стъпка|Референтен|
|:-|:-|:-|
|1|Запълнете рамката EZSP|UG100|
|2|Рандомизация на данни|Раздел 4.3 от UG101|
|3|Добавете контролния байт|Глава2 и Глава3 на UG101|
|4|Изчисляване на CRC|Раздел 2.3 от UG101|
|5|Запълване с байтове|Раздел 4.2 от UG101|
|6|Добавяне на крайния флаг|Раздел 2.4 от UG101|
2.1. Запълнете рамката на EZSP
Форматът на рамката EZSP е илюстриран в Глава 3 от UG100.
Обърнете внимание, че този формат може да се промени при надстройката на SDK. Когато форматът се промени, ще му дадем нов номер на версията. Последният номер на версията на EZSP е 8 към момента на писане на тази статия (EmberZnet 6.8).
Тъй като форматът на EZSP кадъра може да е различен между различните версии, има задължително изискване хостът и NCPЗАДЪЛЖИТЕЛНОработят със същата версия на EZSP. В противен случай те не могат да комуникират както се очаква.
За да се постигне това, първата команда между хоста и NCP трябва да бъде командата за версия. С други думи, хостът трябва да извлече EZSP версията на NCP преди каквато и да е друга комуникация. Ако EZSP версията е различна от EZSP версията на хоста, комуникацията трябва да бъде прекратена.
Имплицитното изискване зад това е, че форматът на командата version можеНИКОГА НЕ СЕ ПРОМЕНЯЙФорматът на командата за версия на EZSP е както следва:
链接: 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 вида контролни байтове. Първите три се използват за общи рамки с 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, има някои резервирани байтови стойности, използвани за специални цели. Тези стойности могат да бъдат намерени в следната таблица:
Когато тези стойности се появят в кадъра, данните ще бъдат обработени по специален начин. – Вмъкване на escape байт 0x7D пред резервирания байт – Обръщане на бит 5 на този резервиран байт
По-долу са дадени някои примери за този алгоритъм:
2.6. Добавете крайния флаг
Последната стъпка е да се добави крайният флаг 0x7E в края на кадъра. След това данните могат да бъдат изпратени към UART порта.
3. Процес на дефреймиране
Когато данните се получават от UART, просто трябва да извършим обратните стъпки, за да ги декодираме.
4. Референции
Време на публикуване: 08 февруари 2022 г.