تصحيح أخطاء USB CDC ACM التسلسلي: ترميز الخط وحالة خط التحكم والبيانات المفقودة

كيفية تصحيح أخطاء أجهزة المنفذ التسلسلي الافتراضي USB CDC ACM من خلال فحص SET_LINE_CODING وSET_CONTROL_LINE_STATE ونقاط نهاية bulk وسلوك البرامج الثابتة.

USB, CDC ACM, تسلسلي, ترميز الخط, البرامج الثابتة

تُستخدم أجهزة USB CDC ACM للمنافذ التسلسلية الافتراضية ووحدات تحكم الأجهزة وأدوات البرامج الثابتة والقياس عن بُعد والتركيبات الاختبارية والتشخيصات المدمجة. تبدو بسيطة من جانب التطبيق: "افتح منفذ COM أو /dev/ttyACM*، وعيّن معدل البود، واقرأ واكتب البايتات. تحتها، لا يزال المضيف والجهاز يتبادلان طلبات USB خاصة بالفئة وعمليات نقل bulk." عندما يعد جهاز CDC لكن لا تتحرك البيانات، يمكن أن يُظهر الالتقاط ما إذا كانت المشكلة في تخطيط الواصفات، أو ترميز الخط، أو حالة خط التحكم، أو حركة نقطة النهاية، أو تخزين البرامج الثابتة المؤقت.

CDC ACM لديه واجهات تحكم وبيانات

يكشف جهاز CDC ACM النموذجي عن واجهة اتصال وواجهة بيانات. قد يرسل المضيف طلبات خاصة بالفئة قبل بدء نقل البيانات.

أدلة مهمة:

  • واصف واجهة الاتصال
  • واصف واجهة البيانات
  • واصفات CDC الوظيفية
  • نقطة نهاية الإشعار
  • نقطة نهاية bulk IN
  • نقطة نهاية bulk OUT
  • SET_LINE_CODING
  • GET_LINE_CODING
  • SET_CONTROL_LINE_STATE

إذا لم تصل هذه الطلبات أبدًا، فقد لا يربط المضيف برنامج تشغيل CDC المتوقع.

معدل البود غالبًا إشارة وليس UART فعليًا

بالنسبة للعديد من أجهزة USB CDC، لا يكون معدل البود ذا معنى فعلي بنفس الطريقة التي يكون بها لـ UART. لكن المضيف لا يزال يرسل ترميز الخط. قد تستخدمه البرامج الثابتة لتكوين جسر، أو تتجاهله، أو تتحقق منه.

أسئلة الالتقاط:

  • هل أرسل المضيف SET_LINE_CODING؟
  • ما معدل البود والتكافؤ وبتات التوقف وبتات البيانات المطلوبة؟
  • هل قبلت البرامج الثابتة الطلب؟
  • هل عين المضيف DTR أو RTS مع SET_CONTROL_LINE_STATE؟
  • هل تنتظر البرامج الثابتة DTR قبل الإرسال؟

العديد من مشكلات "لا يوجد خرج تسلسلي" هي في الواقع "البرامج الثابتة تنتظر DTR ولم يؤكده المضيف أبدًا" أو "التطبيق فتح المنفذ لكنه لم يهيئه كما هو متوقع".

نقاط نهاية Bulk تثبت حركة البيانات

بعد الإعداد، تنتقل بيانات CDC عادةً عبر نقاط نهاية bulk. إذا ظهرت الكتابات من المضيف على bulk OUT لكن لم يتبعها استجابة bulk IN، فقد لا ترسل البرامج الثابتة. إذا ظهرت بيانات bulk IN لكن التطبيق لا يعرضها، فقد يكون المشكلة في سلوك التطبيق المضيف.

افحص:

  • اتجاه نقطة النهاية
  • أطوال النقل
  • سلوك NAK/المهلة المتكرر
  • بايتات الحمولة الفعلية
  • حالة عمليات النقل
  • الترتيب بالنسبة لطلبات حالة الخط

هكذا يصبح التقاط USB أكثر فائدة من لقطة شاشة طرفية.

أين يتناسب Bus Scope

يجب أن يساعد Bus Scope فرق البرامج الثابتة في الاحتفاظ بالواصفات وطلبات الفئة وبيانات نقطة النهاية الأولية في جلسة واحدة. لتصحيح أخطاء CDC ACM، يجب أن يجيب:

  • هل ربط المضيف CDC؟
  • ما ترميز الخط الذي أرسله؟
  • هل تغير DTR/RTS؟
  • هل حمل bulk OUT الأوامر؟
  • هل حمل bulk IN الاستجابات؟
  • هل حدثت المشكلة قبل أو بعد بدء الحركة بأسلوب تسلسلي؟

بالنسبة لعمليات البحث مثل "USB CDC ACM no data"، أو "virtual COM port no output"، أو "SET_CONTROL_LINE_STATE DTR"، الدليل ليس في الطرفية وحدها. إنه في طلبات فئة USB وعمليات نقل نقطة النهاية.