I2C读写基础原理：I2C通信原理和操作

相信很多人都用过这种类型的I2C读写。 但背后还存在很多相关问题。 今天我就为大家写一些相关的内容。

1I2C读写基本原理

市面上大部分采用I2C通信的控制序列和读写流程都是相同的，或者类似。 这是我们最常看到的。

I2C通信原理。 之前关注这个问题的朋友都看过我分享的内容。 应该很多使用单片机进行底层开发或者研究底层开发的朋友都知道I2C通信的原理。

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

以前写文章不太注重布局，所以阅读体验不是很好，但内容还是要写到位。

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

低级驱动程序

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

大多数从事相关开发的初学者或应届毕业生很少考虑代码可移植性、可重用性或容错性等问题。

下面，我简单列出了我在项目中使用的两个常用操作。

1.写入，再次读取，验证写入是否成功

这种方法很容易理解：写入后，再次读取这部分数据，一一匹配，验证与写入的数据是否一致。

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

该方法可以简单解决由于异常导致写入失败的问题。

2.添加验证信息

基于上面一层读验证，在保存一些参数时，我通常会在参数末尾添加“和校验”或“CRC校验”之类的内容。

如果连续存储一个10字节的参数（数据结构），如果其中一个字节参数因异常而被修改，你读出验证后发现不正确，则认为该参数无效。

相信从我上面举的例子中就可以清楚的看出添加这个检查的目的，就是为了解决多字节参数中的某个字节被恶意修改，导致参数无效的问题。

3.多任务中添加互斥锁

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

例如：线程A在网络上写入10字节的数据。 当达到6字节时，线程B想要抢占并写入数据。 你认为线程A应该放弃I2C总线而让线程B写入吗？

答案肯定是不允许的，于是就有了互斥锁这个东西。 即等待最先占用I2C总线的线程完成其操作，然后再释放总线以允许其他线程操作。

这三点可能是我最常用的。 网上还有其他相关的容错处理机制。 如果您有兴趣，不妨搜索一下。

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

硬件、软件I2C

我的代码应该使用硬件 I2C 吗？ 或者模拟I2C的软件？

很多朋友都在问这个问题。 说实话，对于这种有争议的问题，我通常保持中立。

遇到这种问题，一般都是根据实际情况来判断。 例如：您的I2C产品需要提供给不同平台的用户进行二次开发。 我认为软件IO模拟更好，对用户来说更方便。

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

STM32硬件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，你接受不了，就别用了，还得到处说。

哦，抱歉，我写到这里偏离了主题，所以我就到此为止。 希望以上内容对大家有所帮助。

本文来自个人微信公众号“ID：”，经原作者授权发布。 原创公众号是由嵌入式工程师“”精心整理和维护的。 重点分享的内容包括：Keil、IAR、STM8、STM32、μC/OS、、、...