市面上大部分使用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？