简介：STM32F103 I2C通信-中断接收数据是一份面向嵌入式开发者的标准库工程资源，专注解决STM32F103CB在I2C通信中通过中断方式高效接收数据的实现问题，适用于工业控制、医疗设备、消费电子等板级短距离通信场景。包内共227个文件，包含.h/.c源码、I2C库函数与配置头文件，以及标准库工程所需的uvprojx/uvoptx工程文件、编译中间文件（.o/.crf/.lst）、可烧录的hex文件，并附axf/map镜像与映射文件便于排错，压缩包整体约7.09MB。内容涵盖I2C接口初始化、中断优先级配置、中断服务函数编写、数据发送及GPIO引脚配置等关键步骤，也涉及总线冲突与时序异常等常见问题的处理思路，对理解标准库调用和中断接收逻辑很有帮助。资源另含作者整理的批处理脚本与删除编译垃圾文件的小工具，便于直接调试验证。已有427人学习下载，适合希望快速上手STM32 I2C中断通信的初级与中级嵌入式开发者。1. 为什么F103的I2C中断接收值得上手：从轮询卡死说起用过STM32F103硬件I2C的人，多半被坑过两次：一次是网上铺天盖地的“硬件I2C有bug”传闻，另一次是自己用轮询写法把外设卡在某个状态机里出不来。其实换个思路，把I2C从机端接到中断事件上，按地址匹配、每字节到达、停止条件三个节点来收数据，驱动逻辑会清晰很多，CPU也不需要一直空转等待寄存器翻转。这份资源围绕F103的I2C从机中断接收展开，适合给传感器小板、主从板卡、上位机模拟器这类场景做低延迟数据通道，也适合想彻底搞懂F103硬件I2C事件机制的开发者。从初始化到中断处理再到排错，每个环节按可复现的方式写，踩坑记录直接对着抄。2. 硬件I2C与外设中断：先把事件拆清楚再动针脚I2C协议在物理层上只是一根时钟线SCL和一根数据线SDA，但F103的I2C外设把所有传输过程拆成了十几个事件。用中断接收数据之前，得先把这些事件映射到自己的接收流程里，不然中断服务函数写出来只剩一堆if嵌套，看着像在猜谜。2.1 I2C外设结构：从机模式不看时序图也能算清事件F103的I2C外设核心是一组状态寄存器SR1和SR2。SR1里的每位代表一个事件标志，SR2则存放当前总线状态和从机地址等附加信息。从机接收模式下，重点关注四个事件：事件标志位置含义需要做的动作ADDRSR1.ADDR总线上出现了匹配本机地址的帧读SR1再读SR2清标志，准备接收缓冲区RXNESR1.RXNEDR寄存器里有一个新收到的字节立刻读DR，把数据搬进缓冲区BT FSR1.BTF一个字节传输完成，数据已经锁存通常在连续多字节时需要配合处理STOPSR1.STOPF主机发出了停止条件提交当前帧数据，复位接收状态这几个事件是串行出现的，但中断服务函数每次只能看到一个“当前最高优先级”的事件，所以判断顺序很关键。典型顺序是先看ADDR、再看RXNE、最后看STOP，这样每帧数据从开始到结束的事件流是连贯的。从机模式下一个容易被忽略的细节是时钟延展（Clock Stretching）：F103在收到匹配地址后，硬件会自动拉低SCL，给自己争取时间等待软件来清除ADDR标志。这个过程保证了从机CPU来不及处理时主机不会把下一字节硬塞进来，是中断接收能稳定工作的硬件基础。2.2 中断映射与优先级：EV和ER双通道各管什么F103的I2C1中断分成两个向量：事件中断I2C1_EV_IRQn和错误中断I2C1_ER_IRQn。两者触发源不同，处理内容也不同。NVIC_InitTypeDef NVIC_InitStructure; NVIC_InitStructure.NVIC_IRQChannel = I2C1_EV_IRQn; NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 1; NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0; NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE; NVIC_Init(&NVIC_InitStructure); NVIC_InitStructure.NVIC_IRQChannel = I2C1_ER_IRQn; NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 1; NVIC_InitStructure.NVIC_IRQChannelSubPriority = 1; NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE; NVIC_Init(&NVIC_InitStructure);上面这段把EV和ER都打开了。EV抢占优先级为1，ER为1但子优先级更低，这样正常事件永远比错误事件先被响应，避免在总线异常时错误处理把正常接收流程打断。经验值：优先级的抢占部分不要设成0，F103上0留给系统滴答定时器比较稳妥；也不要低于2，否则I2C在400kHz快速传输时，RXNE到达和ISR响应之间的延迟会超过一个字节的时间窗口，导致数据覆盖。实际项目中，ER中断里最常出现的标志是AF（应答失败）和BERR（总线错误）。这两个标志在F103硬件I2C上很容易被干扰信号触发，所以ER中断处理函数要做得越短越好，进去只做标志清除和状态复位，不要试图在里面做协议解析。2.3 参数选型：地址、时钟、上升时间这几个数字别乱填I2C初始化参数里最容易出问题的不是模式选择，而是RiseTime和ClockSpeed的匹配。RiseTime表示总线上数据线从低电平到高电平所需时间，单位是微秒。如果这个值填小了，I2C外设计算SCL高电平宽度时会出错，实测表现为总线频率偏差大或者STOP条件无法被外设正确识别。I2C_InitTypeDef I2C_InitStructure; I2C_InitStructure.I2C_Mode = I2C_Mode_I2C; I2C_InitStructure.I2C_ClockSpeed = 100000; /* 100kHz 标准模式 */ I2C_InitStructure.I2C_Ack = I2C_Ack_Enable; I2C_InitStructure.I2C_AcknowledgedAddress = I2C_AcknowledgedAddress_7bit; I2C_InitStructure.I2C_OwnAddress1 = 0x58; /* 从机自身地址 */ I2C_InitStructure.I2C_DutyCycle = I2C_DutyCycle_2; /* 400kHz时用Fast Mode */ I2C_InitStructure.I2C_RiseTime = 17; /* 对应100kHz，使用4.7k上拉时典型值 */ I2C_Init(I2C1, &I2C_InitStructure);几个参数的选择逻辑再展开说。I2C_OwnAddress1填的是7位地址，如果主机那边配置的从机地址是0xB0，那这个字段要填0x58，因为0xB0是8位视角下的地址，最低位是读写位。这个换算关系经常让新人在联调时翻车，主机发0xB0，从机填0x58，两边都对得上。I2C_RiseTime的取值跟总线上拉电阻值直接相关。100kHz时上拉4.7k，典型上升沿约1微秒，保险起见填17微秒；改为400kHz时RiseTime要填小，通常在2到5之间。如果拿不准，用示波器实测SDA上升沿时间乘2填入，宁大勿小。OwnAddress2在从机模式下默认关闭。除非你确实要用双地址模式，否则不要打开它。打开OwnAddress2后，外设会多监听一个地址，中断里判断地址来源时还要多写一层逻辑，对接收流程没有好处。3. 从机中断接收状态机：ADDR、RXNE、STOP三段式实现从机中断接收最忌讳的是在ISR里做业务处理、等待数据慢慢到齐。正确做法是把接收过程拆成三段：地址匹配之后准备缓冲区，每字节到达立刻搬走，停止条件触发后提交给上层。下面给出一套可用性较高的标准写法，这套逻辑可以覆盖绝大多数单主多从场景。3.1 状态机三段式：ADDR、RXNE、STOP的事件边界ADDR事件发生在主机发出地址帧且与从机地址匹配成功的那一刻。此时外设已经自动回复ACK并拉低SCL，程序需要先读SR1再读SR2来清除ADDR标志，否则外设会一直停在地址阶段，后续数据字节根本进不到DR寄存器。同时，这一段还需要把接收计数清零，保证上一帧残留数据不会混进新帧。RXNE事件说明DR寄存器里已经有一个完整的新字节。这里有个细节值得强调：F103在读DR寄存器后会自动清除RXNE标志，所以代码里不要画蛇添足去操作CR1的某些位来清标志，只读DR即可。如果缓冲区满，可以主动调用I2C_AcknowledgeConfig关闭ACK，这样主机在发下一个字节时会收到NACK，从而中断传输。这个动作叫“接收方主动终止”，在不定长协议里很实用。STOP事件代表主机发送了停止条件，整帧数据真正结束。这时候要把缓冲区里的数据提交给应用层，并把ACK重新打开，准备接收下一帧。对从机来说，STOP事件是判定一帧数据完整性最重要的依据，比任何超时机制都可靠。3.2 中断服务函数完整实现下面这份代码是基于标准外设库的写法，实测在F103C8T6上稳定运行，接收64字节以内数据无丢失。/* I2C1 从机中断接收：标准外设库版本 */ volatile uint8_t i2c_rx_buf[64]; volatile uint16_t i2c_rx_len = 0; volatile uint8_t i2c_rx_flag = 0; /* 一帧数据接收完成后置1 */ void I2C1_EV_IRQHandler(void) { uint16_t event = I2C_GetLastEvent(I2C1); /* 1. 地址匹配事件：清ADDR，准备接收新帧 */ if ((event & I2C_EVENT_SLAVE_RECEIVE_ADDRESS_MATCHED) != 0) { /* 清ADDR标志：读SR1再读SR2，返回值全部丢弃 */ (void)I2C1->SR1; (void)I2C1->SR2; i2c_rx_len = 0; } /* 2. 每收到一个字节：立即从DR寄存器取走数据 */ if ((event & I2C_EVENT_SLAVE_BYTE_RECEIVED) != 0) { if (i2c_rx_len < sizeof(i2c_rx_buf)) { i2c_rx_buf[i2c_rx_len++] = I2C_ReceiveData(I2C1); } else { /* 缓冲已满，发送NACK让主机停止继续发送 */ I2C_AcknowledgeConfig(I2C1, DISABLE); (void)I2C_ReceiveData(I2C1); } } /* 3. 停止条件：整帧数据落地，交给应用层处理 */ if ((event & I2C_EVENT_SLAVE_STOP_DETECTED) != 0) { /* 从机模式下写STOP位，让外设内部状态复位 */ I2C_GenerateSTOP(I2C1, ENABLE); /* 把ACK重新打开，方便接收下一帧 */ I2C_AcknowledgeConfig(I2C1, ENABLE); i2c_rx_flag = 1; } }这段代码的逻辑对应前面说的三段式：第一步清地址标志并重置计数，第二步把DR里的字节搬进缓冲区，第三步在停止条件到来后置标志位通知主循环。三块互相独立，即使某个事件在这一帧没出现，也不会影响另外两个事件的处理。代码里最容易漏掉的是第三段的I2C_GenerateSTOP。在从机模式下，这个操作不是真的在总线上产生停止条件，而是把外设内部的传输状态机复位，使它重新回到监听地址的状态。如果漏了这一步，下一帧主机再发地址时，从机可能因为上一帧状态残留在错误的阶段里，导致地址匹配不成功。还有第二段的NACK分支，当缓冲区满时，先关ACK再读DR，顺序不能颠倒，否则读DR把RXNE清了，后续字节还会继续进来。3.3 关于HAL库和标准外设库的差异如果用的是CubeMX生成的HAL库代码，中断入口变成了HAL_I2C_EV_IRQHandler内部的分发机制，最终会落到几个回调函数上：HAL_I2C_AddrCallback负责地址匹配，HAL_I2C_RxCpltCallback负责接收完成，HAL_I2C_ListenCpltCallback负责监听结束时提交数据。HAL库把SR1/SR2的读取顺序封装好了，写起来确实省事，但在F103上有一个实际体会：HAL库的从机接收回调默认只触发一次，需要手动重新调用HAL_I2C_Slave_Receive_IT或HAL_I2C_EnableListen_IT来恢复接收状态，否则第二帧数据会“静默丢失”。标准外设库的写法更贴近寄存器底层，ISR里每个事件分支都能和SR1的位对应上，排查问题时直接用调试器看SR1寄存器即可，不需要翻回调注册链。两种库的核心逻辑一致，差别只在封装层。对完全新手，用HAL库起步更快；对需要反复调时序或者做故障注入的老手，标准外设库更直接。这份资源里的状态机逻辑两种库都适用，只是中断服务函数内部写法不同。4. CubeMX配置与验证Demo：从初始化到逻辑分析仪理论讲完就该动手。这一章把从新建工程到抓波形的完整路径跑一遍，新手照着走能避开一半的坑。所有配置以标准外设库和CubeMX两种方式对照来说明，哪个顺手用哪个。4.1 CubeMX引脚与I2C参数配置CubeMX配置步骤如下，以F103C8T6为例：新建工程，选F103C8T6封装；RCC里把HSE设为Crystal/Ceramic Resonator；在Pinout视图点击PB6选择I2C1_SCL，点击PB7选择I2C1_SDA，引脚自动变成开漏复用模式；Connectivity > I2C1，参数按表格填写；NVIC里勾选I2C1 event interrupt和I2C1 error interrupt；时钟树保持默认72MHz，直接生成代码。参数填写的值说明I2C ModeI2C标准I2C模式Clock Speed100000 Hz起步用100kHz，联调成功后再试400kHzOwn Address 10x58作为从机时的本机地址Address Length7 bit绝大多数传感器和从机设备都用7位地址Rise Time17 ns对应100kHz，若跑400kHz改为2到5生成代码后，在main函数里调用HAL_I2C_EnableListen_IT进入监听状态。这句调用放在MX_I2C1_Init之后、主循环开始之前。int main(void) { HAL_Init(); SystemClock_Config(); MX_GPIO_Init(); MX_I2C1_Init(); /* 进入从机监听状态，等待主机发送地址 */ HAL_I2C_EnableListen_IT(&hi2c1); while (1) { /* 主循环空转，接收逻辑在I2C中断回调里完成 */ } }HAL_I2C_EnableListen_IT让I2C外设从“关闭”状态进入“监听”状态。这条语句要保证只执行一次。如果放在循环里反复调用，会重复注册回调，导致中断里收到地址后行为异常。4.2 硬件接线与上拉电阻的选择I2C总线必须外接上拉电阻，F103虽然某些引脚内部有弱上拉，但不足以驱动I2C总线快速翻转。至少要外接2.2k到4.7k的电阻到3.3V电源。信号从机侧接法主机侧接法SCLPB6，上拉4.7kSCL线，上拉4.7kSDAPB7，上拉4.7kSDA线，上拉4.7kGND与主机共地与从机共地上拉电阻选值逻辑：板内短走线用4.7k，板间长走线或400kHz高速模式用2.2k甚至1.8k。上拉太大，SCL上升沿太慢，波形爬不到高电平阈值；上拉太小，总线低电平时的灌电流增大，超过MCU引脚容忍范围。F103在3.3V供电、2.2k上拉时，灌电流大约1.5mA，在数据手册允许范围内。有个更容易忽略的点：如果主机那边已经接了上拉电阻，从机这边不接也能工作，因为I2C总线上所有上拉电阻是并联关系。如果两边都接4.7k，并联等效约2.35k，反而更接近高速模式的推荐值。千万别一个接4.7k、一个接10k却不计算并联效果，那会让总线上等效上拉偏高。4.3 验证步骤：从波形到打印初始化做完后，需要验证两件事：主机能不能正常发起传输，从机能不能完整收到。我一般用串口打印从机缓冲区内容来确认，同时用逻辑分析仪看SCL/SDA波形。while (1) { if (i2c_rx_flag) { printf("[I2C] len=%d data=", i2c_rx_len); for (uint16_t i = 0; i < i2c_rx_len; i++) { printf("%02X ", i2c_rx_buf[i]); } printf("\r\n"); i2c_rx_flag = 0; } }从机收到完整帧后，i2c_rx_flag置1，主循环打印数据和长度。注意这里用串口打印一定要放在主循环里，不能放在中断里。串口打印耗时太长，放在中断里会影响I2C字节接收，容易把RXNE覆盖。如果打印结果里总是比主机发的数据多一个字节，那通常是地址帧被当成数据处理了。如果打印出来是乱码，优先看逻辑分析仪的波形，确认SDA上是否有多余毛刺，以及地址字节的ACK阶段是否真的被从机拉低。硬件I2C在调试时，逻辑分析仪比示波器好用，因为它能直接解码出地址和读写位，省去手动数时钟周期的工作。5. 避坑记录：F103 I2C中断接收的5条血泪点这一章不是代码规范，是实打实测出来的坑，每条按“现象→原因→解决”写。遇到类似问题可以直接对照排查，能省不少时间。5.1 坑A：地址匹配事件里误读DR导致首字节丢失现象：主机发送0x58后紧接着发0x01 0x02 0x03，从机收到的数据变成0x02 0x03，首字节0x01消失不见。原因：在ADDR事件处理时调用了I2C_ReceiveData。地址匹配事件的清除条件是读SR1再读SR2，但如果在该读SR2的时候顺手去读DR，就会把地址帧读走。更隐蔽的版本是把SR2的值当作地址校验来做，读SR2后去和预期地址比较，结果占用了本该留给RXNE的DR读取时间。F103在地址匹配后DR并不是空的，强行读会得到不可预期的值，后续RXNE事件又不会重新产生，首字节就丢了。解决：地址匹配阶段只清ADDR标志，绝对不碰DR。清ADDR的操作是读SR1再读SR2，每次读取的返回值直接丢弃。从地址匹配到第一个RXNE之间，程序只做一件事：清标志、重置计数、准备缓冲区。从那以后我每次写这个分支，都会用注释把“不要在这里读DR”这句话标进去。5.2 坑B：RXNE清除太慢导致字节错位或丢字节现象：主机连续发3个字节，从机只收到第1个和第3个，第2个字节丢失，但ISR里i2c_rx_len显示收到了3个字节，数据内容却是0x01 0x02 0x02。原因：F103的I2C外设在RXNE置位后，如果没有及时读走DR，新字节到来时会覆盖旧数据。理论上从机会用时钟延展拉住SCL给CPU时间，但在实际板子上，如果NVIC里面I2C1_EV_IRQn的优先级太低，或者ISR里在处理RXNE之前还做了别的事，比如打印或延时，读DR的操作就可能晚于下一个字节的到达时间。解决：提升I2C事件中断的抢占优先级，从默认的2调到1；ISR里RXNE分支只做搬运，不做任何业务逻辑；缓冲区写指针的更新放在一条语句里完成，避免编译器在多条语句之间被中断插队。在400kHz总线速度下，ISR从触发到读走DR的平均时间应该控制在10微秒以内，超过这个就有丢字节风险。5.3 坑C：STOP事件没接入提交逻辑，数据包烂尾现象：每次接收完数据，应用层拿到的长度总是0，或者上一次的数据混进本次数据里。原因：很多初版代码只在RXNE事件里堆数据，堆完就结束，忽略了STOP事件。停止条件是I2C帧结束的唯一标识，如果不在STOP事件里把数据提交给应用层，缓冲区里的数据就永远留在ISR里，应用层根本看不到。更糟的是，下一帧地址匹配时如果不清空i2c_rx_len，新数据和旧数据会连在一起，形成一帧“混合包”。解决：在ISR的STOP分支里做三件事：调用I2C_GenerateSTOP复位外设内部状态、把ACK重新使能、把当前缓冲区的长度和数据一次性提交给主循环。同时，在ADDR分支里清空i2c_rx_len。这样每一帧都是从零开始的干净数据，上一帧残留被彻底隔离。5.4 坑D：上电瞬间AF标志反复触发，ER中断刷屏现象：板子刚上电，还没接主机，I2C1_ER_IRQHandler就不停进入，AF标志清零后立刻置位。原因：总线上电瞬间，各个设备的电源轨上升时间不同，SCL和SDA线上会有毛刺或电平抖动。F103从机把这些毛刺误判为非法地址帧，由于地址不匹配，硬件自动置位AF错误标志。更常见的场景是主机和从机没有共地，SDA线上有压差，导致总线状态混乱。解决：在ER中断里清掉AF后，加一个几十毫秒的软件延时再重新使能中断，给总线电平一个稳定时间。同时检查主机和从机是否共地，GND线必须连接。如果板子上I2C总线上有多个设备，还要确认每个设备的上电顺序，最好让主机最后上电。实测把RiseTime配置从默认值改成与实际上升沿匹配的参数后，这个现象也明显减少。5.5 坑E：工程里混用不同版本外设库，事件判断错位现象：同一份中断处理代码在A工程编译运行正常，拷贝到B工程后编译通过，但中断永远不触发，或者收到数据后程序跑飞进入HardFault。原因：不同版本的标准外设库或HAL库，对I2C事件的处理方式有差异。有的版本把地址匹配和数据接收放在一个事件枚举里，有的版本拆成两个独立事件。把旧工程的事件定义直接搬到新版外设库里，编译时可能因为宏定义相同而校验不出来，但运行时的事件值已经不匹配了。解决：整个工程只保留一套外设库，不要混用。工程迁移时先检查外设库版本，再检查事件枚举定义是否和当前库匹配。可以用一个简单方法测试：在ISR入口处把SR1的原始值通过串口打印出来，对比实际触发条件和代码里的判断条件，一目了然。从那以后我每次建新工程，都会先确认外设库版本，再开始写中断函数。6. 进阶用法：用DMA接管I2C从机接收，加上软超时兜底中断接收在低速、短帧场景下很稳，但主机连续发送几百字节、每字节间隔只有几个微秒时，ISR逐字节搬移会占用大量CPU时间。F103的I2C从机可以借助DMA直接搬运接收寄存器，把原来中断里的“搬字节”变成“搬缓冲区”，CPU只在整帧完成时介入一次。HAL库下启动DMA接收只需要两行代码：HAL_I2C_EnableListen_IT(&hi2c1); HAL_I2C_Slave_Receive_DMA(&hi2c1, rx_buf, RX_BUF_MAX);RX_BUF_MAX是要预设的接收上限，比如256字节。主机发送的帧长度达不到这个上限时，从机怎么判断一帧结束了？答案是依赖STOP事件。当主机发出停止条件，DMA传输会被截断，同时I2C外设会触发监听完成回调。在这个回调里，用DMA剩余计数器的值反推出实际收到的字节数。void HAL_I2C_ListenCpltCallback(I2C_HandleTypeDef *hi2c) { if (hi2c->Instance == I2C1) { uint16_t remain = __HAL_DMA_GET_COUNTER(&hdma_i2c1_rx); i2c_rx_len = RX_BUF_MAX - remain; HAL_I2C_Slave_Receive_DMA(hi2c, rx_buf, RX_BUF_MAX); i2c_rx_flag = 1; } }有几个细节要提醒。DMA接收的初始长度就是预设上限，主机发20字节时，DMA计数器从RX_BUF_MAX倒数到剩余值，用总量减去剩余量就是实际长度。但如果主机发送长度超过了RX_BUF_MAX，DMA会填满整个缓冲后继续覆盖前面的数据，那时候i2c_rx_len就不再可信。所以这个方案适合帧长上限明确的协议。DMA方式下还需要关闭I2C的PEC校验，开了PEC后DMA接收的数据末尾会多出一个校验字节，反而破坏帧格式。DMA接收还有一个隐患：如果主机在发送中途异常停止，既不发停止条件也不再发数据，DMA就会一直等待，从机永远不会触发ListenCplt回调。这个场景下没有任何中断会唤醒CPU，整个接收通道像死了一样。常见处理是为I2C配一个低速定时器做超时，比如1毫秒中断一次，记录DMA计数器值的变化。如果连续多次定时器中断里计数器值都没有变化，则认为主机已放弃传输，此时主动复位I2C外设，重新进入监听状态。这个软超时给协议加了一层保险，无论主机是断电还是死机，从机都能自动恢复，不需要人工复位。从那以后，我每次做F103的I2C从机都会强制走一遍：先确认总线上拉存在、EV和ER两个中断都打开、事件处理里把ADDR、RXNE、STOP三段拆开，再考虑是否上DMA加软超时兜底。这套流程帮我避开了大部分F103硬件I2C的玄学问题，希望帮到你。本文还有配套的精品资源，点击获取
简介：STM32F103 I2C通信-中断接收数据是一份面向嵌入式开发者的标准库工程资源，专注解决STM32F103CB在I2C通信中通过中断方式高效接收数据的实现问题，适用于工业控制、医疗设备、消费电子等板级短距离通信场景。包内共227个文件，包含.h/.c源码、I2C库函数与配置头文件，以及标准库工程所需的uvprojx/uvoptx工程文件、编译中间文件（.o/.crf/.lst）、可烧录的hex文件，并附axf/map镜像与映射文件便于排错，压缩包整体约7.09MB。内容涵盖I2C接口初始化、中断优先级配置、中断服务函数编写、数据发送及GPIO引脚配置等关键步骤，也涉及总线冲突与时序异常等常见问题的处理思路，对理解标准库调用和中断接收逻辑很有帮助。资源另含作者整理的批处理脚本与删除编译垃圾文件的小工具，便于直接调试验证。已有427人学习下载，适合希望快速上手STM32 I2C中断通信的初级与中级嵌入式开发者。1. 为什么F103的I2C中断接收值得上手：从轮询卡死说起用过STM32F103硬件I2C的人，多半被坑过两次：一次是网上铺天盖地的“硬件I2C有bug”传闻，另一次是自己用轮询写法把外设卡在某个状态机里出不来。其实换个思路，把I2C从机端接到中断事件上，按地址匹配、每字节到达、停止条件三个节点来收数据，驱动逻辑会清晰很多，CPU也不需要一直空转等待寄存器翻转。这份资源围绕F103的I2C从机中断接收展开，适合给传感器小板、主从板卡、上位机模拟器这类场景做低延迟数据通道，也适合想彻底搞懂F103硬件I2C事件机制的开发者。从初始化到中断处理再到排错，每个环节按可复现的方式写，踩坑记录直接对着抄。2. 硬件I2C与外设中断：先把事件拆清楚再动针脚I2C协议在物理层上只是一根时钟线SCL和一根数据线SDA，但F103的I2C外设把所有传输过程拆成了十几个事件。用中断接收数据之前，得先把这些事件映射到自己的接收流程里，不然中断服务函数写出来只剩一堆if嵌套，看着像在猜谜。2.1 I2C外设结构：从机模式不看时序图也能算清事件F103的I2C外设核心是一组状态寄存器SR1和SR2。SR1里的每位代表一个事件标志，SR2则存放当前总线状态和从机地址等附加信息。从机接收模式下，重点关注四个事件：事件标志位置含义需要做的动作ADDRSR1.ADDR总线上出现了匹配本机地址的帧读SR1再读SR2清标志，准备接收缓冲区RXNESR1.RXNEDR寄存器里有一个新收到的字节立刻读DR，把数据搬进缓冲区BT FSR1.BTF一个字节传输完成，数据已经锁存通常在连续多字节时需要配合处理STOPSR1.STOPF主机发出了停止条件提交当前帧数据，复位接收状态这几个事件是串行出现的，但中断服务函数每次只能看到一个“当前最高优先级”的事件，所以判断顺序很关键。典型顺序是先看ADDR、再看RXNE、最后看STOP，这样每帧数据从开始到结束的事件流是连贯的。从机模式下一个容易被忽略的细节是时钟延展（Clock Stretching）：F103在收到匹配地址后，硬件会自动拉低SCL，给自己争取时间等待软件来清除ADDR标志。这个过程保证了从机CPU来不及处理时主机不会把下一字节硬塞进来，是中断接收能稳定工作的硬件基础。2.2 中断映射与优先级：EV和ER双通道各管什么F103的I2C1中断分成两个向量：事件中断I2C1_EV_IRQn和错误中断I2C1_ER_IRQn。两者触发源不同，处理内容也不同。NVIC_InitTypeDef NVIC_InitStructure; NVIC_InitStructure.NVIC_IRQChannel = I2C1_EV_IRQn; NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 1; NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0; NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE; NVIC_Init(&NVIC_InitStructure); NVIC_InitStructure.NVIC_IRQChannel = I2C1_ER_IRQn; NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 1; NVIC_InitStructure.NVIC_IRQChannelSubPriority = 1; NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE; NVIC_Init(&NVIC_InitStructure);上面这段把EV和ER都打开了。EV抢占优先级为1，ER为1但子优先级更低，这样正常事件永远比错误事件先被响应，避免在总线异常时错误处理把正常接收流程打断。经验值：优先级的抢占部分不要设成0，F103上0留给系统滴答定时器比较稳妥；也不要低于2，否则I2C在400kHz快速传输时，RXNE到达和ISR响应之间的延迟会超过一个字节的时间窗口，导致数据覆盖。实际项目中，ER中断里最常出现的标志是AF（应答失败）和BERR（总线错误）。这两个标志在F103硬件I2C上很容易被干扰信号触发，所以ER中断处理函数要做得越短越好，进去只做标志清除和状态复位，不要试图在里面做协议解析。2.3 参数选型：地址、时钟、上升时间这几个数字别乱填I2C初始化参数里最容易出问题的不是模式选择，而是RiseTime和ClockSpeed的匹配。RiseTime表示总线上数据线从低电平到高电平所需时间，单位是微秒。如果这个值填小了，I2C外设计算SCL高电平宽度时会出错，实测表现为总线频率偏差大或者STOP条件无法被外设正确识别。I2C_InitTypeDef I2C_InitStructure; I2C_InitStructure.I2C_Mode = I2C_Mode_I2C; I2C_InitStructure.I2C_ClockSpeed = 100000; /* 100kHz 标准模式 */ I2C_InitStructure.I2C_Ack = I2C_Ack_Enable; I2C_InitStructure.I2C_AcknowledgedAddress = I2C_AcknowledgedAddress_7bit; I2C_InitStructure.I2C_OwnAddress1 = 0x58; /* 从机自身地址 */ I2C_InitStructure.I2C_DutyCycle = I2C_DutyCycle_2; /* 400kHz时用Fast Mode */ I2C_InitStructure.I2C_RiseTime = 17; /* 对应100kHz，使用4.7k上拉时典型值 */ I2C_Init(I2C1, &I2C_InitStructure);几个参数的选择逻辑再展开说。I2C_OwnAddress1填的是7位地址，如果主机那边配置的从机地址是0xB0，那这个字段要填0x58，因为0xB0是8位视角下的地址，最低位是读写位。这个换算关系经常让新人在联调时翻车，主机发0xB0，从机填0x58，两边都对得上。I2C_RiseTime的取值跟总线上拉电阻值直接相关。100kHz时上拉4.7k，典型上升沿约1微秒，保险起见填17微秒；改为400kHz时RiseTime要填小，通常在2到5之间。如果拿不准，用示波器实测SDA上升沿时间乘2填入，宁大勿小。OwnAddress2在从机模式下默认关闭。除非你确实要用双地址模式，否则不要打开它。打开OwnAddress2后，外设会多监听一个地址，中断里判断地址来源时还要多写一层逻辑，对接收流程没有好处。3. 从机中断接收状态机：ADDR、RXNE、STOP三段式实现从机中断接收最忌讳的是在ISR里做业务处理、等待数据慢慢到齐。正确做法是把接收过程拆成三段：地址匹配之后准备缓冲区，每字节到达立刻搬走，停止条件触发后提交给上层。下面给出一套可用性较高的标准写法，这套逻辑可以覆盖绝大多数单主多从场景。3.1 状态机三段式：ADDR、RXNE、STOP的事件边界ADDR事件发生在主机发出地址帧且与从机地址匹配成功的那一刻。此时外设已经自动回复ACK并拉低SCL，程序需要先读SR1再读SR2来清除ADDR标志，否则外设会一直停在地址阶段，后续数据字节根本进不到DR寄存器。同时，这一段还需要把接收计数清零，保证上一帧残留数据不会混进新帧。RXNE事件说明DR寄存器里已经有一个完整的新字节。这里有个细节值得强调：F103在读DR寄存器后会自动清除RXNE标志，所以代码里不要画蛇添足去操作CR1的某些位来清标志，只读DR即可。如果缓冲区满，可以主动调用I2C_AcknowledgeConfig关闭ACK，这样主机在发下一个字节时会收到NACK，从而中断传输。这个动作叫“接收方主动终止”，在不定长协议里很实用。STOP事件代表主机发送了停止条件，整帧数据真正结束。这时候要把缓冲区里的数据提交给应用层，并把ACK重新打开，准备接收下一帧。对从机来说，STOP事件是判定一帧数据完整性最重要的依据，比任何超时机制都可靠。3.2 中断服务函数完整实现下面这份代码是基于标准外设库的写法，实测在F103C8T6上稳定运行，接收64字节以内数据无丢失。/* I2C1 从机中断接收：标准外设库版本 */ volatile uint8_t i2c_rx_buf[64]; volatile uint16_t i2c_rx_len = 0; volatile uint8_t i2c_rx_flag = 0; /* 一帧数据接收完成后置1 */ void I2C1_EV_IRQHandler(void) { uint16_t event = I2C_GetLastEvent(I2C1); /* 1. 地址匹配事件：清ADDR，准备接收新帧 */ if ((event & I2C_EVENT_SLAVE_RECEIVE_ADDRESS_MATCHED) != 0) { /* 清ADDR标志：读SR1再读SR2，返回值全部丢弃 */ (void)I2C1->SR1; (void)I2C1->SR2; i2c_rx_len = 0; } /* 2. 每收到一个字节：立即从DR寄存器取走数据 */ if ((event & I2C_EVENT_SLAVE_BYTE_RECEIVED) != 0) { if (i2c_rx_len < sizeof(i2c_rx_buf)) { i2c_rx_buf[i2c_rx_len++] = I2C_ReceiveData(I2C1); } else { /* 缓冲已满，发送NACK让主机停止继续发送 */ I2C_AcknowledgeConfig(I2C1, DISABLE); (void)I2C_ReceiveData(I2C1); } } /* 3. 停止条件：整帧数据落地，交给应用层处理 */ if ((event & I2C_EVENT_SLAVE_STOP_DETECTED) != 0) { /* 从机模式下写STOP位，让外设内部状态复位 */ I2C_GenerateSTOP(I2C1, ENABLE); /* 把ACK重新打开，方便接收下一帧 */ I2C_AcknowledgeConfig(I2C1, ENABLE); i2c_rx_flag = 1; } }这段代码的逻辑对应前面说的三段式：第一步清地址标志并重置计数，第二步把DR里的字节搬进缓冲区，第三步在停止条件到来后置标志位通知主循环。三块互相独立，即使某个事件在这一帧没出现，也不会影响另外两个事件的处理。代码里最容易漏掉的是第三段的I2C_GenerateSTOP。在从机模式下，这个操作不是真的在总线上产生停止条件，而是把外设内部的传输状态机复位，使它重新回到监听地址的状态。如果漏了这一步，下一帧主机再发地址时，从机可能因为上一帧状态残留在错误的阶段里，导致地址匹配不成功。还有第二段的NACK分支，当缓冲区满时，先关ACK再读DR，顺序不能颠倒，否则读DR把RXNE清了，后续字节还会继续进来。3.3 关于HAL库和标准外设库的差异如果用的是CubeMX生成的HAL库代码，中断入口变成了HAL_I2C_EV_IRQHandler内部的分发机制，最终会落到几个回调函数上：HAL_I2C_AddrCallback负责地址匹配，HAL_I2C_RxCpltCallback负责接收完成，HAL_I2C_ListenCpltCallback负责监听结束时提交数据。HAL库把SR1/SR2的读取顺序封装好了，写起来确实省事，但在F103上有一个实际体会：HAL库的从机接收回调默认只触发一次，需要手动重新调用HAL_I2C_Slave_Receive_IT或HAL_I2C_EnableListen_IT来恢复接收状态，否则第二帧数据会“静默丢失”。标准外设库的写法更贴近寄存器底层，ISR里每个事件分支都能和SR1的位对应上，排查问题时直接用调试器看SR1寄存器即可，不需要翻回调注册链。两种库的核心逻辑一致，差别只在封装层。对完全新手，用HAL库起步更快；对需要反复调时序或者做故障注入的老手，标准外设库更直接。这份资源里的状态机逻辑两种库都适用，只是中断服务函数内部写法不同。4. CubeMX配置与验证Demo：从初始化到逻辑分析仪理论讲完就该动手。这一章把从新建工程到抓波形的完整路径跑一遍，新手照着走能避开一半的坑。所有配置以标准外设库和CubeMX两种方式对照来说明，哪个顺手用哪个。4.1 CubeMX引脚与I2C参数配置CubeMX配置步骤如下，以F103C8T6为例：新建工程，选F103C8T6封装；RCC里把HSE设为Crystal/Ceramic Resonator；在Pinout视图点击PB6选择I2C1_SCL，点击PB7选择I2C1_SDA，引脚自动变成开漏复用模式；Connectivity > I2C1，参数按表格填写；NVIC里勾选I2C1 event interrupt和I2C1 error interrupt；时钟树保持默认72MHz，直接生成代码。参数填写的值说明I2C ModeI2C标准I2C模式Clock Speed100000 Hz起步用100kHz，联调成功后再试400kHzOwn Address 10x58作为从机时的本机地址Address Length7 bit绝大多数传感器和从机设备都用7位地址Rise Time17 ns对应100kHz，若跑400kHz改为2到5生成代码后，在main函数里调用HAL_I2C_EnableListen_IT进入监听状态。这句调用放在MX_I2C1_Init之后、主循环开始之前。int main(void) { HAL_Init(); SystemClock_Config(); MX_GPIO_Init(); MX_I2C1_Init(); /* 进入从机监听状态，等待主机发送地址 */ HAL_I2C_EnableListen_IT(&hi2c1); while (1) { /* 主循环空转，接收逻辑在I2C中断回调里完成 */ } }HAL_I2C_EnableListen_IT让I2C外设从“关闭”状态进入“监听”状态。这条语句要保证只执行一次。如果放在循环里反复调用，会重复注册回调，导致中断里收到地址后行为异常。4.2 硬件接线与上拉电阻的选择I2C总线必须外接上拉电阻，F103虽然某些引脚内部有弱上拉，但不足以驱动I2C总线快速翻转。至少要外接2.2k到4.7k的电阻到3.3V电源。信号从机侧接法主机侧接法SCLPB6，上拉4.7kSCL线，上拉4.7kSDAPB7，上拉4.7kSDA线，上拉4.7kGND与主机共地与从机共地上拉电阻选值逻辑：板内短走线用4.7k，板间长走线或400kHz高速模式用2.2k甚至1.8k。上拉太大，SCL上升沿太慢，波形爬不到高电平阈值；上拉太小，总线低电平时的灌电流增大，超过MCU引脚容忍范围。F103在3.3V供电、2.2k上拉时，灌电流大约1.5mA，在数据手册允许范围内。有个更容易忽略的点：如果主机那边已经接了上拉电阻，从机这边不接也能工作，因为I2C总线上所有上拉电阻是并联关系。如果两边都接4.7k，并联等效约2.35k，反而更接近高速模式的推荐值。千万别一个接4.7k、一个接10k却不计算并联效果，那会让总线上等效上拉偏高。4.3 验证步骤：从波形到打印初始化做完后，需要验证两件事：主机能不能正常发起传输，从机能不能完整收到。我一般用串口打印从机缓冲区内容来确认，同时用逻辑分析仪看SCL/SDA波形。while (1) { if (i2c_rx_flag) { printf("[I2C] len=%d data=", i2c_rx_len); for (uint16_t i = 0; i < i2c_rx_len; i++) { printf("%02X ", i2c_rx_buf[i]); } printf("\r\n"); i2c_rx_flag = 0; } }从机收到完整帧后，i2c_rx_flag置1，主循环打印数据和长度。注意这里用串口打印一定要放在主循环里，不能放在中断里。串口打印耗时太长，放在中断里会影响I2C字节接收，容易把RXNE覆盖。如果打印结果里总是比主机发的数据多一个字节，那通常是地址帧被当成数据处理了。如果打印出来是乱码，优先看逻辑分析仪的波形，确认SDA上是否有多余毛刺，以及地址字节的ACK阶段是否真的被从机拉低。硬件I2C在调试时，逻辑分析仪比示波器好用，因为它能直接解码出地址和读写位，省去手动数时钟周期的工作。5. 避坑记录：F103 I2C中断接收的5条血泪点这一章不是代码规范，是实打实测出来的坑，每条按“现象→原因→解决”写。遇到类似问题可以直接对照排查，能省不少时间。5.1 坑A：地址匹配事件里误读DR导致首字节丢失现象：主机发送0x58后紧接着发0x01 0x02 0x03，从机收到的数据变成0x02 0x03，首字节0x01消失不见。原因：在ADDR事件处理时调用了I2C_ReceiveData。地址匹配事件的清除条件是读SR1再读SR2，但如果在该读SR2的时候顺手去读DR，就会把地址帧读走。更隐蔽的版本是把SR2的值当作地址校验来做，读SR2后去和预期地址比较，结果占用了本该留给RXNE的DR读取时间。F103在地址匹配后DR并不是空的，强行读会得到不可预期的值，后续RXNE事件又不会重新产生，首字节就丢了。解决：地址匹配阶段只清ADDR标志，绝对不碰DR。清ADDR的操作是读SR1再读SR2，每次读取的返回值直接丢弃。从地址匹配到第一个RXNE之间，程序只做一件事：清标志、重置计数、准备缓冲区。从那以后我每次写这个分支，都会用注释把“不要在这里读DR”这句话标进去。5.2 坑B：RXNE清除太慢导致字节错位或丢字节现象：主机连续发3个字节，从机只收到第1个和第3个，第2个字节丢失，但ISR里i2c_rx_len显示收到了3个字节，数据内容却是0x01 0x02 0x02。原因：F103的I2C外设在RXNE置位后，如果没有及时读走DR，新字节到来时会覆盖旧数据。理论上从机会用时钟延展拉住SCL给CPU时间，但在实际板子上，如果NVIC里面I2C1_EV_IRQn的优先级太低，或者ISR里在处理RXNE之前还做了别的事，比如打印或延时，读DR的操作就可能晚于下一个字节的到达时间。解决：提升I2C事件中断的抢占优先级，从默认的2调到1；ISR里RXNE分支只做搬运，不做任何业务逻辑；缓冲区写指针的更新放在一条语句里完成，避免编译器在多条语句之间被中断插队。在400kHz总线速度下，ISR从触发到读走DR的平均时间应该控制在10微秒以内，超过这个就有丢字节风险。5.3 坑C：STOP事件没接入提交逻辑，数据包烂尾现象：每次接收完数据，应用层拿到的长度总是0，或者上一次的数据混进本次数据里。原因：很多初版代码只在RXNE事件里堆数据，堆完就结束，忽略了STOP事件。停止条件是I2C帧结束的唯一标识，如果不在STOP事件里把数据提交给应用层，缓冲区里的数据就永远留在ISR里，应用层根本看不到。更糟的是，下一帧地址匹配时如果不清空i2c_rx_len，新数据和旧数据会连在一起，形成一帧“混合包”。解决：在ISR的STOP分支里做三件事：调用I2C_GenerateSTOP复位外设内部状态、把ACK重新使能、把当前缓冲区的长度和数据一次性提交给主循环。同时，在ADDR分支里清空i2c_rx_len。这样每一帧都是从零开始的干净数据，上一帧残留被彻底隔离。5.4 坑D：上电瞬间AF标志反复触发，ER中断刷屏现象：板子刚上电，还没接主机，I2C1_ER_IRQHandler就不停进入，AF标志清零后立刻置位。原因：总线上电瞬间，各个设备的电源轨上升时间不同，SCL和SDA线上会有毛刺或电平抖动。F103从机把这些毛刺误判为非法地址帧，由于地址不匹配，硬件自动置位AF错误标志。更常见的场景是主机和从机没有共地，SDA线上有压差，导致总线状态混乱。解决：在ER中断里清掉AF后，加一个几十毫秒的软件延时再重新使能中断，给总线电平一个稳定时间。同时检查主机和从机是否共地，GND线必须连接。如果板子上I2C总线上有多个设备，还要确认每个设备的上电顺序，最好让主机最后上电。实测把RiseTime配置从默认值改成与实际上升沿匹配的参数后，这个现象也明显减少。5.5 坑E：工程里混用不同版本外设库，事件判断错位现象：同一份中断处理代码在A工程编译运行正常，拷贝到B工程后编译通过，但中断永远不触发，或者收到数据后程序跑飞进入HardFault。原因：不同版本的标准外设库或HAL库，对I2C事件的处理方式有差异。有的版本把地址匹配和数据接收放在一个事件枚举里，有的版本拆成两个独立事件。把旧工程的事件定义直接搬到新版外设库里，编译时可能因为宏定义相同而校验不出来，但运行时的事件值已经不匹配了。解决：整个工程只保留一套外设库，不要混用。工程迁移时先检查外设库版本，再检查事件枚举定义是否和当前库匹配。可以用一个简单方法测试：在ISR入口处把SR1的原始值通过串口打印出来，对比实际触发条件和代码里的判断条件，一目了然。从那以后我每次建新工程，都会先确认外设库版本，再开始写中断函数。6. 进阶用法：用DMA接管I2C从机接收，加上软超时兜底中断接收在低速、短帧场景下很稳，但主机连续发送几百字节、每字节间隔只有几个微秒时，ISR逐字节搬移会占用大量CPU时间。F103的I2C从机可以借助DMA直接搬运接收寄存器，把原来中断里的“搬字节”变成“搬缓冲区”，CPU只在整帧完成时介入一次。HAL库下启动DMA接收只需要两行代码：HAL_I2C_EnableListen_IT(&hi2c1); HAL_I2C_Slave_Receive_DMA(&hi2c1, rx_buf, RX_BUF_MAX);RX_BUF_MAX是要预设的接收上限，比如256字节。主机发送的帧长度达不到这个上限时，从机怎么判断一帧结束了？答案是依赖STOP事件。当主机发出停止条件，DMA传输会被截断，同时I2C外设会触发监听完成回调。在这个回调里，用DMA剩余计数器的值反推出实际收到的字节数。void HAL_I2C_ListenCpltCallback(I2C_HandleTypeDef *hi2c) { if (hi2c->Instance == I2C1) { uint16_t remain = __HAL_DMA_GET_COUNTER(&hdma_i2c1_rx); i2c_rx_len = RX_BUF_MAX - remain; HAL_I2C_Slave_Receive_DMA(hi2c, rx_buf, RX_BUF_MAX); i2c_rx_flag = 1; } }有几个细节要提醒。DMA接收的初始长度就是预设上限，主机发20字节时，DMA计数器从RX_BUF_MAX倒数到剩余值，用总量减去剩余量就是实际长度。但如果主机发送长度超过了RX_BUF_MAX，DMA会填满整个缓冲后继续覆盖前面的数据，那时候i2c_rx_len就不再可信。所以这个方案适合帧长上限明确的协议。DMA方式下还需要关闭I2C的PEC校验，开了PEC后DMA接收的数据末尾会多出一个校验字节，反而破坏帧格式。DMA接收还有一个隐患：如果主机在发送中途异常停止，既不发停止条件也不再发数据，DMA就会一直等待，从机永远不会触发ListenCplt回调。这个场景下没有任何中断会唤醒CPU，整个接收通道像死了一样。常见处理是为I2C配一个低速定时器做超时，比如1毫秒中断一次，记录DMA计数器值的变化。如果连续多次定时器中断里计数器值都没有变化，则认为主机已放弃传输，此时主动复位I2C外设，重新进入监听状态。这个软超时给协议加了一层保险，无论主机是断电还是死机，从机都能自动恢复，不需要人工复位。从那以后，我每次做F103的I2C从机都会强制走一遍：先确认总线上拉存在、EV和ER两个中断都打开、事件处理里把ADDR、RXNE、STOP三段拆开，再考虑是否上DMA加软超时兜底。这套流程帮我避开了大部分F103硬件I2C的玄学问题，希望帮到你。本文还有配套的精品资源，点击获取