حول تقنية Zigbee EZSP UART | شركة أوون للتكنولوجيا

المؤلف: TorchIoTBootCamp
الرابط: https://zhuanlan.zhihu.com/p/339700391
من: كورا

1. مقدمة

قدمت شركة Silicon Labs حلاً متكاملاً لبوابات Zigbee، يتألف من وحدة مضيفة ووحدة تحكم الشبكة (NCP). في هذا التصميم، تتواصل الوحدة المضيفة مع وحدة تحكم الشبكة عبر واجهة UART أو SPI. ويُستخدم UART عادةً لبساطته مقارنةً بـ SPI.

كما قدمت شركة Silicon Labs مشروعًا نموذجيًا للبرنامج المضيف، وهو النموذج.Z3GatewayHostيعمل هذا النموذج على نظام شبيه بنظام يونكس. قد يرغب بعض العملاء في نموذج مضيف يعمل على نظام تشغيل في الوقت الحقيقي (RTOS)، ولكن للأسف، لا يوجد حاليًا نموذج مضيف قائم على نظام RTOS. لذا، يتعين على المستخدمين تطوير برنامج مضيف خاص بهم قائم على نظام RTOS.

من المهم فهم بروتوكول بوابة UART قبل تطوير برنامج مضيف مخصص. بالنسبة لكل من وحدة التحكم في الشبكة (NCP) القائمة على UART ووحدة التحكم في الشبكة القائمة على SPI، يستخدم المضيف بروتوكول EZSP للتواصل مع وحدة التحكم في الشبكة.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 الخاص بالمضيف، فيجب إيقاف الاتصال.

الشرط الضمني وراء ذلك هو أن يكون تنسيق أمر الإصدار قابلاً للتغيير.لا تتغير أبداًصيغة أمر إصدار EZSP هي كما يلي:

تجدون شرحًا لحقل المعامل وتنسيق استجابة الإصدار في الفصل الرابع من دليل المستخدم UG100. حقل المعامل هو إصدار EZSP للبرنامج المضيف. عند كتابة هذه المقالة، كان الإصدار 8.

الموقع: TorchIoTBootCamp
الرابط:https://zhuanlan.zhihu.com/p/339700391
来源:知乎
لا داعي للقلق بشأن هذه المشكلة.

2.2. عشوائية البيانات

تُشرح عملية التوزيع العشوائي بالتفصيل في القسم 4.3 من دليل المستخدم UG101. سيتم توزيع إطار EZSP بالكامل عشوائيًا. وتتمثل عملية التوزيع العشوائي في دمج إطار EZSP مع تسلسل شبه عشوائي باستخدام عملية XOR.

فيما يلي خوارزمية توليد التسلسل شبه العشوائي.

rand0 = 0×42
إذا كانت البتة 0 من randi تساوي 0، فإن randi+1 = randi >> 1
إذا كانت البتة 0 من randi تساوي 1، فإن randi+1 = (randi >> 1) ^ 0xB8

2.3. أضف بايت التحكم

بايت التحكم عبارة عن بايت واحد من البيانات، ويجب إضافته إلى بداية الإطار. يوضح الجدول أدناه التنسيق:

يوجد إجمالاً ستة أنواع من بايتات التحكم. تُستخدم الأنواع الثلاثة الأولى للإطارات الشائعة التي تحتوي على بيانات EZSP، وهي: DATA وACK وNAK. أما الأنواع الثلاثة الأخيرة فتُستخدم بدون بيانات EZSP الشائعة، وهي: RST وRSTACK وERROR.

تم وصف تنسيق RST و RSTACK و ERROR في القسم 3.1 إلى 3.3.

2.4. حساب CRC

يتم حساب رمز التحقق الدوري (CRC) ذي 16 بت على البايتات بدءًا من بايت التحكم وحتى نهاية البيانات. يتم تهيئة رمز التحقق الدوري القياسي (CRCCCITT) (g(x) = x16 + x12 + x5 + 1) إلى 0xFFFF. يسبق البايت الأكثر أهمية البايت الأقل أهمية (نمط البايتات الكبيرة).