اختيار شريحة بوابة Bluetooth Mesh: Telink أم Silicon Labs أم Nordic؟
مقارنة بين Telink mesh_gw وNordic Zephyr وSilicon Labs NCP/BGAPI لبوابة Bluetooth Mesh: البرنامج الثابت والبروتوكول التسلسلي وسعة العقد والتكلفة، ولماذا اخترنا Silicon Labs.
حسمنا في المقال السابق أمرين: الأجهزة والبوابة تتخاطبان عبر SIG Mesh، وفي البوابة تقيم حزمة Mesh على وحدة بلوتوث مستقلة يقودها برنامج Linux عبر المنفذ التسلسلي.
يبقى سؤال عملي جدًا: أي شريحة بلوتوث نختار؟
قارنّا بين ثلاثة مصنّعين: Telink وSilicon Labs وNordic. غيّرنا رأينا مرة في منتصف الطريق، وانتهينا إلى Silicon Labs في البوابة وTelink في الأجهزة. يعرض هذا المقال المقارنة والمنطق وراء القرار.
أولًا، ما الذي تفعله هذه الشريحة داخل البوابة؟
وحدة البلوتوث في البوابة ليست عقدة Mesh عادية، بل تؤدي عدة أدوار:
- Provisioner (مُجهِّز): يُجهّز الأجهزة الجديدة، ويوزّع العناوين، ويوزّع المفاتيح ويربطها.
- Controller (متحكّم): يرسل أوامر التشغيل والإطفاء وتعتيم الإضاءة وتغيير اللون، ويستقبل تقارير الحالة.
- عقدة دائمة العمل: تعيد بثّ الرسائل للأجهزة الأبعد.
- معالج مساعد: يتلقى الأوامر من مضيف Linux عبر UART ويُعيد إليه الرسائل الواردة.
لذلك فالمقارنة ليست في السيليكون نفسه. الأهم هو هل يوفّر المصنّع برنامجًا ثابتًا (firmware) جاهزًا للبوابة، ومدى قابلية البروتوكول التسلسلي بين المضيف والوحدة للاستخدام. هذه الطبقة هي التي تحدد حجم الشيفرة التي يحتاجها برنامج البوابة، وهل يستطيع أحد تصحيح أخطائه لاحقًا.
Telink: الأرخص، وبرنامجها الثابت جاهز، لكن بروتوكولها مغلق
تهيمن Telink على سوق الإضاءة والمفاتيح في الصين، وأجهزتنا كانت تستخدم شرائحها أصلًا. حزمة SIG Mesh SDK الخاصة بها مفتوحة على GitHub وتتضمن برنامجًا ثابتًا جاهزًا للبوابة هو mesh_gw.
يبدو mesh_gw تقريبًا على هذا النحو:
| الطبقة | المحتوى | قابل للتعديل؟ |
|---|---|---|
| حزمة البلوتوث وحزمة Mesh | التشفير وطبقتا الشبكة والنقل | مغلق المصدر، مكتبات فقط |
| طبقة تطبيق البوابة | معالجة الأوامر التسلسلية، مسار التجهيز، تقارير الحالة | مفتوح المصدر |
| واجهة المضيف | UART (الشريحة الأحدث TL321X تدعم UART فقط) | بروتوكول Telink الخاص |
نقاط القوة واضحة:
- شرائح رخيصة، بضعة يوانات للقطعة عند الكميات الكبيرة.
- برنامج ثابت للبوابة جاهز للاستخدام، مع أداة تصحيح على Windows.
- المصنّع نفسه الذي في الأجهزة، فأي نماذج خاصة بـ Telink على الأجهزة تُفهم مباشرة.
المشكلة في البروتوكول التسلسلي. فقد صمّمته Telink بنفسها، والتوثيق شحيح، وكثير من التفاصيل لا يتضح إلا بقراءة شيفرة SDK. أسماء الأوامر على نمط HCI_CMD_GATEWAY_... توحي بأنها HCI البلوتوث القياسي، لكنها ليست كذلك، وحتى تأطير الإطارات مختلف: الإطارات من المضيف إلى الوحدة بلا ترويسة طول وتُفصل بزمن خمول UART، أما الإطارات العائدة من الوحدة فتحمل ترويسة طول.
وهناك أيضًا حد للسعة: يخزّن mesh_gw افتراضيًا 200 عقدة كحد أقصى، أو 110 مع التجهيز عن بُعد، لأن بيانات العقد تعيش في قطاع فلاش واحد. هذا كافٍ للمنزل، أما الاستخدام التجاري فيعني تعديل تخطيط التخزين في SDK.
كُتب نموذجنا الأول على هذا البروتوكول، مع وحدة محاكاة للاختبار. اشتغل النموذج، لكن كل ميزة جديدة كانت تعني الغوص في الشيفرة المصدرية من جديد، ولم نشعر معه بالثبات يومًا.
Nordic: أفضل الأدوات والتوثيق، لكن عليك كتابة البرنامج الثابت للبوابة
يحظى nRF52840 وnRF5340 من Nordic بسمعة طيبة بين مطوّري البلوتوث. فالتوثيق وأدوات التنصت وتطبيقات الهاتف من الأفضل في القطاع، ويكلّف nRF52840 Dongle نحو عشرة دولارات ويُركَّب مباشرة في منفذ USB.
لكن لدى Nordic فجوة جوهرية: حزمة nRF Connect SDK الحالية لا تتضمن برنامجًا ثابتًا رسميًا لبوابة تسلسلية. كانت حزمة nRF5 SDK for Mesh القديمة تتضمن واحدًا، لكنها لم تعد مدعومة. يترك هذا ثلاثة خيارات في جانب البوابة:
| الأسلوب | على الوحدة | على المضيف | التقييم |
|---|---|---|---|
| كتابة برنامج ثابت خاص للبوابة | Provisioner وعملاء النماذج في Zephyr Mesh مع بروتوكول تسلسلي مخصص | ترجمة فقط | أنظف معمارية، لكنها تتطلب كتابة ألف إلى ألفي سطر بلغة C |
| الوحدة كمتحكّم بلوتوث عادي | برنامج HCI القياسي من Zephyr | خدمة Mesh من BlueZ على Linux، أو حزمة خاصة بك | البرنامج الثابت جاهز، لكن لا تطوير على Windows |
| Zephyr Mesh Shell | سطر أوامر مدمج | أوامر نصية | للتصحيح فقط |
من ناحية السعة، يمكن ضبط حزمة Zephyr حتى 4096 عقدة، والواقعي بين ألف وألفين بحسب الذاكرة. لكن الافتراضي 8 عقد فقط، مع قائمة حماية من إعادة الإرسال بـ 10 مدخلات. وإن تركته كما هو بدأت رسائل الجهاز الحادي عشر بالفشل، وهذا فخ كلاسيكي عند بناء بوابة على Zephyr.
تناسب Nordic حالتين: أن تريد تحكمًا كاملًا في طبقة Mesh داخل البوابة، أو أن تدير بوابة واحدة عدة مئات من الأجهزة أو أكثر. لم تنطبق علينا أي منهما، والوحدات أغلى بوضوح، فاستبعدناها.
Silicon Labs: بروتوكول تسلسلي موثّق، وهذا حسم الأمر
تتبع Silicon Labs النهج نفسه الذي تتبعه Telink: «الوحدة تشغّل الحزمة والمضيف يرسل الأوامر»، ويسمى رسميًا وضع NCP (المعالج المساعد للشبكة). الفرق أن بروتوكولها التسلسلي BGAPI موثّق توثيقًا جيدًا:
- كل أمر واستجابة وحدث موثّق، مع مكتبات مضيف رسمية بلغتي C وPython.
- يغطي تقريبًا كامل واجهة Mesh البرمجية: التجهيز، والإعداد، والنماذج القياسية، وتحديث المفاتيح، وتحديث البرنامج الثابت.
- تتضمن SDK مثالًا لـ Provisioner على جانب المضيف (ملاحظة التطبيق AN1371)، فيمكن لتنفيذنا بلغة Rust أن يتبع مساره.
- أداة NCP Commander الرسومية تتيح تجهيز الأجهزة وتبديل الإضاءة دون كتابة أي شيفرة.
تأطير BGAPI بسيط: ترويسة من 4 بايتات مع حمولة حتى 255 بايتًا.
[hdr0][len_lo][class][cmd][payload 0–255 bytes]
hdr0: bit7 command/event, bits 6–3 device type, bits 2–0 length high bitsتنبيه واحد: لا يوجد فحص تحقق (checksum) في BGAPI على الوصلة التسلسلية. تُفصل الإطارات بالطول وحده، لذا يجب تفعيل التحكم بالتدفق العتادي RTS/CTS لتجنب فقدان البايتات. عند اختيار المعالج الرئيسي، تأكد أن UART فيه يدعم التحكم بالتدفق.
أما السعر، فتُدرج Silicon Labs على موقعها شريحة EFR32BG24 المستخدمة في البوابات بنحو 2.70 إلى 3.70 دولار للقطعة عند 1000 قطعة، أي أكثر من Telink. وبالنسبة لكل بوابة، يعني هذا زيادة قدرها دولاران تقريبًا.
الثلاثة جنبًا إلى جنب
| Telink | Nordic | Silicon Labs | |
|---|---|---|---|
| البرنامج الثابت للبوابة | جاهز (mesh_gw) |
اكتبه بنفسك، أو HCI قياسي | جاهز (أمثلة NCP) |
| البروتوكول التسلسلي | خاص، توثيق شحيح | بروتوكولك الخاص، أو HCI قياسي | BGAPI، موثّق، مع مكتبات مضيف |
| أدوات التصحيح | متوفرة | الأفضل | جيدة |
| السعة الافتراضية للعقد | 200 (110 مع التجهيز عن بُعد) | 8، يجب رفعها حتى 4096 | تُحدد بإعدادات برنامج NCP الثابت |
| تكلفة الشريحة | الأدنى | أعلى | متوسطة |
| سلسلة التوريد الصينية | الأنضج | مقبولة | جيدة |
اختيارنا: Silicon Labs في البوابة وTelink في الأجهزة
التركيبة النهائية:
- البوابة: وحدة من سلسلة BG24 من Silicon Labs تشغّل برنامج NCP الثابت.
- الأجهزة: ما زالت Telink، تشغّل SIG Mesh SDK الخاصة بها.
تستخدم البوابة وحدة واحدة، فدفع دولارين أو ثلاثة زيادة يشتري بروتوكولًا تسلسليًا موثّقًا وواجهة Mesh كاملة وأمثلة رسمية، ويجعل الصيانة أسهل بكثير. أما الأجهزة فالأمر مختلف: المفاتيح والمصابيح تُشحن بكميات كبيرة، فيتضخم الفرق الصغير في سعر الشريحة، وتكلفة Telink وبيئتها المحلية أنسب.
ويتعايش المصنّعان في شبكة واحدة بفضل النماذج القياسية من SIG التي تناولها المقال السابق. ما دامت الأجهزة تلتزم بنماذج قياسية مثل Generic OnOff وLight Lightness وCTL، فلا يهم مصنّع البوابة. وإن استخدم جهاز نماذج خاصة بـ Telink، فإما أن ننتقل إلى القياسية، أو ننفّذ النموذج الخاص المقابل في البوابة.
بعد التخلي عن بروتوكول Telink، لا نحتاج إلا إلى إعادة كتابة طبقة البروتوكول التسلسلي في برنامج البوابة؛ أما Matter وجدول الأجهزة وطبقة الربط فتبقى دون مساس. وهذا ثمرة التصميم الطبقي الذي عرضناه في المقال الأول.
ما يزال بحاجة إلى تحقق
هذه الاستنتاجات ما زالت على الورق. وحين تصل اللوحات، هناك ثلاثة أمور تأتي أولًا:
- هل تعمل بوابة Silicon Labs مع أجهزة Telink فعلًا؟ قبل كتابة أي شيفرة، استخدم NCP Commander لتجهيز لوحة محمّلة ببرنامج الإضاءة من Telink وتشغيلها.
- هل يستطيع UART في المعالج الرئيسي تشغيل التحكم بالتدفق العتادي؟ نجري اختبارات إجهاد طويلة ونراقب الإطارات المفقودة.
- كم جهازًا تتحمله بوابة واحدة بموثوقية؟ نضبط عدد العقد وقائمة الحماية من إعادة الإرسال في برنامج NCP الثابت وفق الحاجة الفعلية.
وستحظى النتائج بمقال خاص بها.
كلمة أخيرة
عند اختيار شريحة بلوتوث لبوابة، يغري التركيز على السعر والمواصفات. لكن ما يشكّل التطوير والصيانة فعلًا هو في الغالب البروتوكول التسلسلي الخفي: هل هو موثّق، وهل يمكن تصحيح أخطائه، وهل تستطيع معرفة سبب العطل حين يقع؟
إن كنت تختار شريحة لبوابة Bluetooth Mesh، أو تعمل مع BGAPI من Silicon Labs أو mesh_gw من Telink، يسعدني الحديث معك: linktr.ee/weiyii