安全存储和访问EEPROM [英] Safely storing and accessing EEPROM

问题描述

我最近成立了需要存储在微控制器的EEPROM经常更新的配置变量。添加状态，本程序将立即迫使人们担心

I've recently established the need to store infrequently-updated configuration variables in the EEPROM of a microcontroller. Adding state to the program immediately forces one to worry about

• 检测EEPROM未初始化的数据（即第一次启动）的，


• 转换或无效旧的固件版本的数据，和


• 多个结构，其中每一个可在固件更新生长的寻址。

广泛的谷歌搜索只打开了一篇文章，解决<一个href=\"http://embeddedgurus.com/stack-overflow/2009/11/keeping-your-eeprom-data-valid-through-firmware-updates/\"相对=nofollow>让您的EEPROM数据通过固件更新有效。有没有人使用该文章中讨论的方法？有没有更好的替代办法？

Extensive Googling has only turned up one article that addresses keeping your EEPROM data valid through firmware updates. Has anyone used the approach discussed in that article? Is there a better alternative approach?

推荐答案

我个人preFER一个标记表的格式。

Personally, I prefer a "tagged table" format.

在此格式，您的数据分成了一系列的表的。每个表都有一个遵循predictable格式，并可以改变，你就需要一个机构的标头。

In this format, your data is split up into a series of "tables". Each table has a header that follows a predictable format and a body that can change as you need it to.

下面是一个什么样的表中的一个看起来像一个例子：

Here's an example of what one of the tables would look like:

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

我不存储大量的数据，所以我用一个字节在头部的每个字段。你可以使用任何你需要的大小，只要你永远不会改变它。该数据表被写入陆续进入EEPROM中。

I wasn't storing a lot of data, so I used a single byte for each field in the header. You can use whatever size you need, so long as you never change it. The data tables are written one after another into the EEPROM.

当您的固件需要读取数据出的EEPROM，它开始在第一个表中读取。如果固件识别该表ID和支持列出的表的版本，它加载（后验证校验和，当然）出表中的主体的数据。如果ID，版本或校验查不出来，表只是跳过。长度字段用于定位在链中的下一个表。当固件看到具有零的长度的表，它知道它已到达的数据的结束，并且没有更多的表来处理。

When your firmware needs to read the data out of the EEPROM, it starts reading at the first table. If the firmware recognizes the table ID and supports the listed table version, it loads the data out of the body of the table (after validating the checksum, of course). If the ID, version, or checksum don't check out, the table is simply skipped. The length field is used to locate the next table in the chain. When firmware sees a table with a length of zero, it knows that it has reached the end of the data and that there are no more tables to process.

我觉得这种格式灵活的（我可以添加任何类型的数据到表体）和强大的（保留标题格式常数和数据表将是既向前和向后兼容）。

I find this format flexible (I can add any type of data into the body of a table) and robust (keep the header format constant and the data tables will be both forward- and backwards-compatible).

有一个警告夫妇，虽然他们是不是太沉重的负担。首先，你需要确保你的固件可以处理情况的重要数据要么不在表或使用了不支持的格式版本。您还需要初始化EEPROM存储区的零的第一个字节（这样在第一次开机时，你不开始在垃圾装载认为它是数据）。由于每个表格都知道它的长度是可能的扩大或缩小的表格;但是，你必须移动表存储区域的其余部分，以围绕确保不存在任何洞（如表的整个产业链无法在设备的内存中放不下，那么这个过程可能会讨厌）。就个人而言，我没有发现任何这些是那么大的一个问题，这是非常值得的麻烦我节省超过使用数据存储的其他一些方法。

There are a couple of caveats, though they are not too burdensome. First, you need to ensure that your firmware can handle the case where important data either isn't in the table or is using an unsupported format version. You will also need to initialize the first byte of the EEPROM storage area to zero (so that on the first boot, you don't start loading in garbage thinking that it's data). Since each table knows its length it is possible to expand or shrink a table; however, you have to move the rest of the table storage area around in order to ensure that there are no "holes" (if the entire chain of tables can't fit in your device's memory, then this process can be annoying). Personally, I don't find any of these to be that big of a problem, and it is well worth the trouble I save over using some other methods of data storage.

这篇关于安全存储和访问EEPROM的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！