EEPROM，在项目中我一般会做几项特殊操作

市面上大部分使用I2C通信的EEPROM，控制时序和读写流程都相同，或类似。我们最常见的就是AT24C0x这类EEPROM。

I2C通信原理，这个问题关注我较早的朋友看过我分享的内容，应该很多使用MCU进行底层开发，或者学习底层的朋友都知道I2C通信原理。

如果还有不明白I2C通信基础的朋友，可以回看一下我之前分享的文章：

1.STM32F10x_模拟I2C读写EEPROM

2.STM32F10x_硬件I2C读写EEPROM

以前写文章没怎么注重排版，阅读体验不是很好，但内容应该还是写到位了。

还有，文中的参考代码在我“底部菜单”下载区可以找到。

真正实际做过项目的人都知道，好的底层驱动，会给上层应用开发带来很大便利，节省开发时间，以及减少bug发生率。

而大部分初学者，或者应届毕业生从事相关开发，一般很少考虑代码的移植性，复用性，或者说容错处理等问题。

下面，我简单列两点我在项目中，对EEPROM常用的几项操作。

1.写，再读，验证写入成功

这种方法很好理解：写入之后，再次读去这部分数据，进行一一匹配，验证是否与写入数据一致。

一般我是会重复操作3次，也就是说：写入，再读取，如果超过3次都还失败，那么我则放弃写入，认为写入失败，或芯片异常。

这个方法可以简单解决因异常导致写入失败的问题。

2.添加校验信息

在上面一层读验证基础上，对保存一些参数，我一般还会：在参数末尾添加类似“和校验”，或“CRC校验”。

假如你连续存储一个有10字节的参数（数据结构），如果因异常修改了中间某一个字节参数，你读出来进行校验，发现不对，则认为这个参数无效。

添加这个校验的目的相信从上面我举例已经明白，就是解决多字节参数中某个字节被恶意修改，导致这个参数无效的问题。

3.EEPROM在多任务中添加互斥锁

使用过操作系统的朋友都知道，多线程访问一个资源，一般都存在互斥的关系。简单的说：一个资源，在同一时刻，只能被一个线程操作。

那EEPROM举例：线程A在网EEPROM写10字节数据，刚6个字节时，线程B想要抢占，往EEPROM写入数据。你觉得线程A应不应该放弃I2C总线，让线程B写入呢？

答案肯定是不允许的，所以，就有了互斥锁这么一说。也就是等先占用I2C总线的线程操作完，才释放总线，让其他线程进行操作。

这三点应该是我比较常用了，网上还有其他一些相关的容错处理机制，感兴趣的不妨搜索一下。

我这里就不贴代码了，因芯片型号不同，应用不同，代码就存在差异。但我们目的：在保证满足应用的同时，需考虑代码的移植、复用、以及容错。

我们代码应该使用硬件I2C？ 还是软件模拟I2C？

这个问题有许多朋友都在问，说句实话，遇到这类有争议的问题，我一般还是保持中立。

我遇到这类问题，一般会根据实际情况而定。比如：你的I2C产品要提供给一些不同平台用户，进行二次开发，我觉得软件IO模拟比较好，方便用户嘛。

假如你们公司开发的产品都使用STM32这家公司芯片开发I2C产品，我觉得，你代码可以使用硬件I2C。

相信很多朋友都知道这个问题，在官网也能找到相关说明，这里再描述一下吧。

问题描述

如果没有在传输当前字节之前处理EV7、 EV7_1、 EV6_1、 EV2、 EV8和EV3事件，有可能产生问题，如收到一个额外的字节、两次读到相同的数据或丢失数据。

暂时解决办法

当不能在传输当前字节之前和当改变ACK控制位送出相应脉冲之前，处理EV7、EV7_1、EV6_1、EV2、EV8和EV3事件时，建议如下操作：

1.使用I2C的DMA模式，除非作为主设备时只接收一个字节。

2.使用I2C的中断并把它的优先级设为最高级别，使得它不能被中断。

这里就想简单说下，很多人看到STM32的I2C有bug，就在在网上恶意吐槽，或者开骂。

有的人看不惯，或者不允许别人有一点点错误。同样，我分享的内容有些人觉得不好就开始恶语攻击了。

这类人我其实很不解，别人芯片有bug，你不能接收，不用就行了，还非得到处说着说那。

哦，抱歉，一下写来偏离主题了，就到这里吧，希望上面内容对大家有帮助。