О Zigbee EZSP UART

Автор:TorchIoTBootCamp
Ссылка: https://zhuanlan.zhihu.com/p/339700391
От: Куора

1. Введение

Silicon Labs предложила решение хост+NCP для проектирования шлюза Zigbee. В этой архитектуре хост может связываться с NCP через интерфейс UART или SPI. Чаще всего используется UART, поскольку он намного проще, чем SPI.

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

Прежде чем разрабатывать индивидуальную хост-программу, важно понять протокол шлюза UART. Как для NCP на базе UART, так и для NCP на основе SPI хост использует протокол EZSP для связи с NCP.ЭЗСПэто сокращение отПоследовательный протокол EmberZnet, и он определен вУГ100. Для NCP на базе UART реализован протокол нижнего уровня для надежной передачи данных EZSP через UART.ПЕПЕЛпротокол, сокращение отАсинхронный последовательный хост. Более подробную информацию о ASH см.УГ101иУГ115.

Связь между 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 должна быть команда версии. Другими словами, хост должен получить версию NCP EZSP перед любым другим обменом данными. Если версия 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. Самый значимый байт предшествует наименее значимому байту (режим с обратным порядком байтов).

2.5. Байтовая вставка

Как описано в разделе 4.2 документа UG101, существуют некоторые зарезервированные значения байтов, используемые для специальных целей. Эти значения можно найти в следующей таблице:

7

Когда эти значения появляются в кадре, к данным будет применена специальная обработка. – Вставьте escape-байт 0x7D перед зарезервированным байтом. – Поменяйте местами бит 5 этого зарезервированного байта.

Ниже приведены некоторые примеры этого алгоритма:

8

2.6. Добавьте флаг завершения

Последний шаг — добавить флаг завершения 0x7E в конец кадра. После этого данные можно отправить в порт UART.

3. Процесс дефрейминга

Когда данные получены от UART, нам просто нужно выполнить обратные шаги для их декодирования.

4. Ссылки


Время публикации: 08 февраля 2022 г.
Онлайн-чат WhatsApp!