هل يعود سجل SD سليماً بعد انقطاع الطاقة؟ مشاريع تخرج ESP32

قد ينجح المسجل في كتابة آلاف الصفوف ثم يتوقف عن قراءة الملف كله بعد فصل مفاجئ. السبب ليس دائماً تلف بطاقة الذاكرة: قد يكون آخر قطاع أو تحديث جدول الملفات وقع في لحظة القطع. لهذا لا يكفي أن ينفذ البرنامج flush ثم يفترض أن كل شيء أصبح آمناً. تحذر وثائق ESP-IDF من أن FAT لا يضمن معاملات الكتابة عند الانقطاع، بينما صُمم littlefs مع التعافي من فقد الطاقة ضمن أهدافه؛ لكن تبديل نظام الملفات ليس حلاً سحرياً إذا كان الهدف استخدام بطاقة SD عادية يقرأها الحاسوب.

ما السؤال الذي يختبره المشروع؟

المشروع لا يعلن أن بطاقة SD «مضمونة ضد التلف». يقارن طريقتين للتسجيل: ملف CSV يحدّثه التطبيق مباشرة، وسجل سجلات مستقل append-only يتضمن رقم تسلسلياً ووقتاً وقيمة وCRC. تُحفظ في FRAM الصغيرة أحدث قيمة رقمية تم إقرارها، لا نسخة كاملة من ملف الذاكرة. عند الإقلاع يقرأ البرنامج السجل من آخر موضع معروف، ويفحص الأرقام وCRC حتى آخر سجل مكتمل. إذا لم تتطابق البطاقة وFRAM، يعلن التعارض ويعرض السجلات الصالحة بدلاً من إخفاء الفقد.

المكونات ومسار البيانات

يكفي ESP32، بطاقة SD على ناقل SPI أو SDMMC مناسب للوحة، ذاكرة I²C FRAM، حساس رقمي بسيط أو مولد قيم اختبار، ومفتاح يقطع تغذية اللوحة من مصدر محدود الجهد. لكل سجل شكل ثابت: magic، نسخة التنسيق، sequence، timestamp، payload، ثم CRC. تُكتب البايتات إلى ملف مفتوح على دفعات مع فواصل تحقق، وبعد نجاح العملية يُحدّث مؤشر FRAM في خانة متناوبة تحمل sequence وCRC. وجود خانتين يجعل اختيار آخر مؤشر صالح ممكناً إذا انقطع التيار أثناء تحديث المؤشر نفسه. وحتى نجاح دالة الكتابة أو flush في نظام التشغيل لا يثبت دائماً أن متحكم البطاقة أنهى تثبيت كل البيانات في وسيطها الداخلي؛ لذلك لا يصف الاختبار أي نقطة إقرار على أنها ضمان دائم قبل اختبارها على البطاقة الفعلية.

تذكر ورقة Infineon أن عائلة FRAM المذكورة تتحمل دورات كتابة كثيرة مقارنة بذاكرات EEPROM التقليدية، لكن قيمة التحمل تخص القطعة وشروط بياناتها ولا تعني أن تخزين مؤشر واحد يمنح بطاقة SD حماية مطلقة. يظل ترتيب الإقرار مهماً: لا تقدّم واجهة المستخدم رقماً كأنه محفوظ قبل تحقق التطبيق من الكتابة، ولا تعدّل سجل FRAM قبل أن يعرف التطبيق أي مجموعة بايتات قبلتها المكتبة فعلياً.

نقاط قطع الطاقة

أنشئ جدولاً من نقاط يمكن تكرارها: قبل فتح الملف، بعد إضافة header، في منتصف payload، بعد كتابة CRC، وبعد تحديث FRAM. استخدم مولد سجلات مرقمة بفاصل ثابت، ثم اقطع طاقة ESP32 عبر مفتاح خارجي بينما يكتب حمل الاختبار. كرر كل نقطة عشرات المرات وسجل رقم السجل المطلوب، وآخر رقم يعاد بناؤه، وهل أمكن تركيب البطاقة على حاسوب للقراءة فقط. لا تستخدم فصل كابل الحاسوب عن المنفذ كاختبار مضبوط إذا كان زمن استجابة التغذية يتغير بين مرة وأخرى.

خوارزمية الاستعادة

بعد الإقلاع، اقرأ نسختي المؤشر في FRAM واختر النسخة ذات CRC الصحيح ورقم التسلسل الأحدث وفق قاعدة التفاف موثقة. افحص السجل على البطاقة من نقطة البداية أو من آخر checkpoint معروف، وتوقف عند سجل ناقص أو CRC غير مطابق. السجل السابق يبقى صالحاً، أما الجزء الأخير فيصنف incomplete. إذا كانت المكتبة تعيد خطأ mount، لا تهيئ البطاقة تلقائياً؛ التهيئة تمحو الدليل الذي يحتاجه الطالب لتشخيص الفشل. احفظ رسالة الخطأ واسم البطاقة وعداد الإقلاع في مساحة أخرى ثم أوقف الكتابة.

ما الذي تقيسه؟

لكل تجربة احسب نسبة السجلات المستعادة إلى السجلات التي أبلغ التطبيق بأنه كتبها، وعدد السجلات غير المكتملة، ومدة فحص البطاقة، ومقدار ما ضاع منذ آخر checkpoint. اعرض النتائج منفصلة حسب نقطة القطع ونظام الملفات وحجم الدفعة. قارن الكتابة كل سجل بالكتابة على دفعات، لأن الكتابة الصغيرة المتكررة تغيّر الأداء ومعدل التعامل مع القطاعات. تقرير مشروع التخرج يصبح مفيداً حين يحتوي على سجل الخام ونسخة من برنامج إعادة الفحص، لا مخططاً واحداً لزمن الكتابة.

يمكن أن يضيف الفريق سجل أحداث على الواجهة، لكن لا ينبغي أن يحول التجربة إلى اختبار أمان للبطاقة أو إلى ادعاء أن كل سجلات المختبرات ستبقى. تختلف متحكمات بطاقات SD، وسياسات caching، والمكتبات، والجهد المتبقي في المكثفات. كما أن littlefs يعمل عادةً على block device يعرفه المنفذ؛ لا يمكن اختيار اسمه في الإعداد ثم افتراض أن كل بطاقة SD أصبحت تستخدمه من دون طبقة تكامل متوافقة.

اختبارات قبول واضحة

اختبر إقلاعاً سليماً بعد إيقاف منظم، وقطعاً متكرراً أثناء كل مرحلة، وبطاقة ممتلئة، وCRC خاطئاً عمداً، ومؤشري FRAM غير صالحين. معيار القبول المقترح: لا يعرض البرنامج سجلاً بCRC خاطئ على أنه صحيح، ولا يهيئ البطاقة تلقائياً، ويشرح عدد السجلات التي أمكن استعادتها. أضف اختباراً لطول الملف وقيم sequence عند التفاف العداد، واختبر إعادة تشغيل قارئ السجلات على الحاسوب بلا اللوحة. هذه اختبارات مشروع وليست شهادة امتثال أو اختبار عمر للذاكرة.

حدود النتيجة وتسليم الفريق

وثائق ESP-IDF تشرح سلوك أنظمة الملفات المتاحة ومخاطرها، كما يعرض تصميم littlefs اعتبارات النسخ عند الكتابة ومقاومة انقطاع الطاقة؛ كلاهما يساعد على صياغة الفرضية لكنه لا يصف أداء بطاقة الطالب. يجب كتابة موديل البطاقة، نوع الناقل، حجم دفعة الكتابة، وإصدار المكتبة. الاستنتاج المقبول هو «في إعداد الاختبار استعاد القارئ كذا من السجلات»، لا «FRAM تمنع تلف SD». ومن مهام مشاريع التخرج أن يسلّم الفريق ملفات التجربة والكود والقرارات والقيود، ويمكن مراجعة نطاق التنفيذ ضمن خدمة مشاريع التخرج ومشاريع Arduino والأجهزة المتصلة.

يتصل المشروع بأفكار مراقبة الباب التي تحتاج تسجيلاً قابلاً للمراجعة، لكنه يركز على سلامة كتابة السجل لا على قياس فتح الباب. كما يمكن أن يستفيد من فكرة إيصال البناء في توثيق نسخة firmware المستخدمة لكل تجربة. هذا الفصل بين ما يقيسه النظام وما يقوله عن نفسه يجعل النتيجة أكثر قابلية للتكرار.

يمكن مراجعة الفروق التي يعلنها الإطار عن أنظمة الملفات في ESP-IDF، ثم مقارنة مبدأ النسخ عند الكتابة في وثيقة تصميم littlefs. وتوضح نشرة FM24V02A أن الشريحة ذاكرة F-RAM غير متطايرة بسعة 256 كيلوبت، وتنفذ الكتابة عند نقل البايت على ناقل I²C من دون مهلة كتابة داخلية؛ هذه خاصية للشريحة نفسها ولا تضمن حفظ بيانات بطاقة SD بعد انقطاع الطاقة.

وهذا مناسب لمشاريع تخرج في الأنظمة المضمنة حين يكون المطلوب توثيق ما بقي بعد انقطاع مضبوط، لا الادعاء بأن السجل محصّن من كل عطل.