व्यक्तिगत रूप से, मैं एक "टैग की गई तालिका" प्रारूप पसंद करता हूं।
इस प्रारूप में, आपका डेटा "टेबल" की एक श्रृंखला में विभाजित है। प्रत्येक तालिका में एक शीर्षलेख होता है जो एक अनुमानित प्रारूप और एक शरीर का पालन करता है जो आपको इसकी आवश्यकता के अनुसार बदल सकता है।
यहाँ तालिकाओं में से एक की तरह लग रहे हैं का एक उदाहरण है:
Byte 0: Table Length (in 16-bit words)
Byte 1: Table ID (used by firmware to determine what this data is)
Byte 2: Format Version (incremented every time the format of this table changes)
Byte 3: Checksum (simple sum-to-zero checksum)
Byte 4: Start of body
...
Byte N: End of body
मैं बहुत अधिक डेटा का भंडारण नहीं कर रहा था, इसलिए मैं शीर्षक में प्रत्येक क्षेत्र के लिए एक एकल बाइट का इस्तेमाल किया। आप जो भी आकार चाहते हैं उसका उपयोग कर सकते हैं, जब तक आप इसे कभी नहीं बदलते। डेटा टेबल ईईपीरोम में एक के बाद एक लिखा जाता है।
जब आपके फर्मवेयर को ईईपीरोम से डेटा को पढ़ने की आवश्यकता होती है, तो यह पहली तालिका में पढ़ना शुरू कर देता है। यदि फर्मवेयर तालिका आईडी को पहचानता है और सूचीबद्ध तालिका संस्करण का समर्थन करता है, तो यह तालिका के शरीर के बाहर डेटा को लोड करता है (निश्चित रूप से चेकसम को सत्यापित करने के बाद)। यदि आईडी, संस्करण, या चेकसम चेक आउट नहीं करते हैं, तो तालिका बस छोड़ दी जाती है। श्रृंखला में अगली तालिका का पता लगाने के लिए लंबाई क्षेत्र का उपयोग किया जाता है। जब फर्मवेयर शून्य की लंबाई वाली तालिका देखता है, तो यह जानता है कि यह डेटा के अंत तक पहुंच गया है और प्रक्रिया के लिए कोई और टेबल नहीं है।
मुझे यह प्रारूप लचीला लगता है (मैं किसी भी प्रकार के डेटा को किसी तालिका के शरीर में जोड़ सकता हूं) और मजबूत (हेडर प्रारूप निरंतर रखें और डेटा टेबल दोनों आगे और पीछे की ओर संगत होंगे)।
कुछ चेतावनी हैं, हालांकि वे बहुत बोझिल नहीं हैं। सबसे पहले, आपको यह सुनिश्चित करने की ज़रूरत है कि आपका फर्मवेयर उस मामले को संभाल सकता है जहां महत्वपूर्ण डेटा या तो तालिका में नहीं है या असमर्थित प्रारूप संस्करण का उपयोग कर रहा है। आपको ईईपीरोम स्टोरेज एरिया के पहले बाइट को शून्य पर भी आरंभ करने की आवश्यकता होगी (ताकि पहले बूट पर, आप कचरे में लोड करना शुरू नहीं कर रहे हैं कि यह डेटा है)। चूंकि प्रत्येक तालिका इसकी लंबाई जानता है, इसलिए तालिका को विस्तार या संक्षिप्त करना संभव है; हालांकि, आपको यह सुनिश्चित करने के लिए शेष तालिका भंडारण क्षेत्र को चारों ओर स्थानांतरित करना होगा ताकि कोई "छेद" न हो (यदि टेबल की पूरी श्रृंखला आपके डिवाइस की स्मृति में फिट नहीं हो सकती है, तो यह प्रक्रिया परेशान हो सकती है)। व्यक्तिगत रूप से, मुझे इनमें से कोई भी समस्या का बड़ा होने के लिए नहीं मिला है, और यह डेटा संग्रहण के कुछ अन्य तरीकों का उपयोग करके सहेजने वाली परेशानी के लायक है।
यह फ़र्मवेयर संस्करणों के बीच तालिका आकार में परिवर्तनों से निपटने के लिए एक महान समाधान की तरह लगता है। क्या आपके पास डेटा को डुप्लिकेट करने के अलावा बिजली-हानि मध्य-लेखन के प्रति सहिष्णु बनाने के लिए कोई सलाह है? –
संपूर्ण तालिका को अमान्य चेकसम के साथ लिखें, फिर (एक अलग लेनदेन में) वापस जाएं और सही चेकसम लिखें। यदि मध्य-लेखन में कोई समस्या है, तो डेटा में पढ़ने पर आपका चेकसम गलत होगा। – bta
यह एक सुरुचिपूर्ण समाधान है जो कार्यान्वित करने के लिए तुच्छ है: निम्नलिखित के लिए धन्यवाद। –