كيفية منع تلف البيانات "الكتابة الجزئية" أثناء فقدان الطاقة?

Question

في بيئة مضمنة (باستخدام مسب 430) ، لقد رأيت بعض تلف البيانات الناجمة عن الكتابة الجزئية إلى الذاكرة غير المتطايرة.يبدو أن هذا ناتج عن فقدان الطاقة أثناء الكتابة (إما لفرام أو شرائح المعلومات).

أنا التحقق من صحة البيانات المخزنة في هذه المواقع مع اتفاقية حقوق الطفل.

سؤالي هو, ما هي الطريقة الصحيحة لمنع هذا" الكتابة الجزئية " الفساد?حاليا ، لقد عدلت رمز بلدي للكتابة إلى موقعين فرام منفصلة.لذلك ، إذا تمت مقاطعة كتابة واحدة مما تسبب في اتفاقية حقوق الطفل غير صالحة ، يجب أن يظل الموقع الآخر صالحا.هل هذه ممارسة شائعة?هل أحتاج إلى تنفيذ سلوك الكتابة المزدوج هذا لأي ذاكرة غير متطايرة?

Answer 1

الحل البسيط هو الحفاظ على اثنين إصدارات البيانات (في صفحات منفصلة لذاكرة فلاش) ، الإصدار الحالي والإصدار السابق.يحتوي كل إصدار على رأس يتكون من رقم تسلسلي وكلمة تتحقق من صحة رقم التسلسل-ببساطة مكمل 1 لرقم التسلسل على سبيل المثال:

---------
|  seq  |
---------
| ~seq  |
---------
|       |
| data  |
|       |
---------

الشيء الحاسم هو أنه عندما يتم كتابة البيانات seq و ~seq الكلمات مكتوبة الاخير.

على بدء لك قراءة البيانات التي تحتوي على أعلى تسلسل صالح عدد (المحاسبة للالتفاف حول ربما-وخاصة بالنسبة للكلمات تسلسل قصيرة).عند كتابة البيانات ، يمكنك الكتابة والتحقق من صحة الأقدم منع.

الحل الذي تستخدمه بالفعل صالح طالما أن اتفاقية حقوق الطفل مكتوبة أخيرا ، ولكنها تفتقر إلى البساطة وتفرض نفقات حساب اتفاقية حقوق الطفل التي قد لا تكون ضرورية أو مرغوبة.

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

Answer 2

يأخذ فريقنا الهندسي نهجا بين هذه المشكلة: حلها في الأجهزة والبرامج!

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

ثانيا، تكون بياناتنا أمرا بالغ الأهمية بشكل خاص للتشغيل، وتحديثها في كثير من الأحيان ولا نريد أن نرتدي تخزين الفلاش غير المخطط الخاص بنا (فهي تدعم الكثير من الكتابات.) لذلك نحن في الواقع تخزين البيانات 16 مرة في فلاش وحماية كل سجل مع رمز CRC. على التمهيد، نجد أحدث الكتابة الصالحة ثم ابدأ دورات المسح / الكتابة لدينا.

لم نر مطلقا فساد بيانات منذ تنفيذ نظامنا الباراني بصراحة.

تحديث:

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

Answer 3

لقد استخدمنا شيء مشابه إجابة Clifford ولكنك مكتوب في عملية كتابة واحدة.تحتاج نسختين من البيانات والبديل بينهما.استخدم رقم تسلسل زيادة بحيث يحتوي موقع واحد بفعالية على أرقام تسلسل وواحد من الغريب.

اكتب البيانات مثل هذا (في أمر كتابة واحد إذا كنت تستطيع):

giveacodicetagpre.

عندما تقرأ ذلك، تأكد من أن كل من أرقام التسلسل هي نفسها - إذا لم تكن البيانات غير صالحة.عند بدء التشغيل، اقرأ كلتا المواقع والعمل الذي حدث أكثر حداثة (مع مراعاة رقم التسلسل المتداول).

Answer 4

دائما تخزين البيانات في نوع من البروتوكول، مثل start_byte، إجمالي البايتات للكتابة والبيانات وإنهاء البايت. قبل أن يصرخ إلى الذاكرة الخارجية / الداخلية دائما تحقق من سجلات Moniter Power Moniters / ADC. إذا كنت على أي حال تفسد البيانات، فسوف ينتهي البايت أيضا.بحيث لا يتمكن هذا الدخول بعد التحقق من صحة البروتوكول بأكمله. المجموع الاختباري ليست فكرة جيدة، يمكنك اختيار CRC16 بدلا من ذلك إذا كنت ترغب في تضمين CRC في بروتوكولك.