在现代嵌入式系统中，一个MCU往往不再孤立工作。随着传感器、执行器和功能模块数量的增加，如何高效、可靠地组织多设备通信成为设计的关键。I²C总线凭借其仅需两根线（SCL和SDA）即可连接多个设备的能力，成为低速外设互联的首选方案。而当你的STM32不再是通信的发起者，而是作为“被访问”的角色时——比如主机读取温度数据或下发控制命令——你就必须掌握 将STM32配置为I2C从机 的技术。
这听起来简单，但在实际开发中，很多工程师会遇到中断不触发、地址匹配失败、总线锁定等问题。尤其是使用HAL库进行非阻塞操作时，若对回调机制理解不到位，很容易陷入调试困境。本文将带你避开这些坑，用一套稳定可靠的中断驱动方式实现STM32的I2C从机功能。
从协议到硬件：I2C从机到底怎么工作？
I2C是主从架构的同步串行总线，所有通信都由主机启动。从机始终处于“监听”状态，等待自己的地址出现在总线上。一旦匹配成功，它就会根据R/W位决定进入接收模式（主机写）还是发送模式（主机读）。
STM32内部的I2C外设支持完整的从机模式，包括：
- 自动识别7位/10位地址
- 硬件生成ACK信号
- 检测起始/停止条件
- 触发中断响应事件
这意味着你不需要手动翻转引脚电平或精确计时，只要正确配置外设并处理好中断逻辑，就能让STM32像“听话的仆人”一样响应主机请求。
不过要注意，并非所有STM32型号都对从机模式支持完善。例如一些早期F1系列芯片的I2C模块存在缺陷，在高负载下可能丢失字节。因此建议优先选择F4、G4、L4及以上系列，并查阅参考手册确认“I2C slave mode”是否完整支持。
HAL库中的从机API：不只是调用函数那么简单
ST的HAL库提供了清晰的API来管理I2C从机行为：
HAL_I2C_Slave_Receive_IT(&hi2c1, buffer, size); // 开启中断接收
HAL_I2C_Slave_Transmit_IT(&hi2c1, data, len); // 启动中断发送
看似简单两行代码，背后却隐藏着几个关键点：
地址为什么要左移一位？
这是最常见的陷阱之一。I2C帧中，前7位是设备地址，第8位是读写标志（0=写，1=读）。当我们设置 OwnAddress1 = 0x50 << 1; ，实际上是告诉HAL库：“我的7位地址是0x50”，然后库会自动将其左移一位，留出最低位给R/W。
如果你直接写成 0x50 而不左移，那等于告诉外设“我的地址是0x28”，这显然会导致主机无法寻址。
正确做法：***使用 your_addr << 1
为什么推荐使用中断而非轮询？
轮询方式虽然简单，但会阻塞整个程序运行，不适合需要同时处理其他任务的系统。而中断模式允许CPU在等待通信时去做别的事，只有当主机真正开始访问时才跳转到中断服务程序，效率更高。
DMA则更进一步，连数据搬运都不用CPU插手，特别适合音频流、批量传感器数据上传等场景。
实战代码解析：构建一个可响应读写的智能节点
我们以STM32F407为例，搭建一个典型的I2C从机应用：主机可以通过写操作发送指令，STM32收到后准备响应数据；当主机发起读操作时，返回预设信息。
初始化配置
static void MX_I2C1_Init(void)
{
hi2c1.Instance = I2C1;
hi2c1.Init.ClockSpeed = 100000; // 标准模式100kHz
hi2c1.Init.DutyCycle = I2C_DUTYCYCLE_2; // 快速模式下可选不同占空比
hi2c1.Init.OwnAddress1 = 0x50 << 1; // 本机地址0x50，左移！
hi2c1.Init.AddressingMode = I2C_ADDRESSINGMODE_7BIT;
hi2c1.Init.DualAddressMode = I2C_DUALADDRESS_DISABLE;
hi2c1.Init.OwnAddress2 = 0;
hi2c1.Init.GeneralCallMode = I2C_GENERALCALL_DISABLE;
hi2c1.Init.NoStretchMode = I2C_NOSTRETCH_ENABLE; // 关闭时钟延展
if (HAL_I2C_Init(&hi2c1) != HAL_OK) {
Error_Handler();
}
}
其中最关键的参数是 NoStretchMode = ENABLE 。启用该选项后，即使CPU还没准备好，I2C外设也不会拉低SCL来“拖延时间”。虽然牺牲了一点灵活性，但能避免因响应延迟导致主机超时的问题，尤其在中断繁忙或调试阶段非常有用。
主循环逻辑设计
int main(void)
{
HAL_Init();
SystemClock_Config();
MX_GPIO_Init();
MX_I2C1_Init();
uint8_t rx_buffer[10] = {0};
uint8_t tx_data[] = "Hello Host!";
uint8_t ready_to_respond = 0;
// 启动从机接收，等待主机写入
HAL_I2C_Slave_Receive_IT(&hi2c1, rx_buffer, 10);
while (1)
{
if (ready_to_respond) {
// 主机之前写了'R'，现在可以响应读请求
HAL_I2C_Slave_Transmit_IT(&hi2c1, tx_data, sizeof(tx_data));
ready_to_respond = 0;
}
// 其他任务：LED闪烁、传感器采集等...
HAL_Delay(10);
}
}
这里的关键在于： 接收和发送不能连续启动 。必须等一次事务完成后再开启下一轮。否则可能导致状态混乱。
回调函数才是真正的控制中心
HAL库通过回调函数通知应用层事件的发生。你需要实现以下三个核心回调：
void HAL_I2C_SlaveRxCpltCallback(I2C_HandleTypeDef *hi2c)
{
if (hi2c->Instance == I2C1) {
// 接收完成，检查是否为主机发出的读请求
if (rx_buffer[0] == 'R') {
ready_to_respond = 1;
}
}
}
void HAL_I2C_SlaveTxCpltCallback(I2C_HandleTypeDef *hi2c)
{
if (hi2c->Instance == I2C1) {
// 发送完毕，重新开启接收以等待下次交互
HAL_I2C_Slave_Receive_IT(hi2c, rx_buffer, 10);
}
}
void HAL_I2C_ErrorCallback(I2C_HandleTypeDef *hi2c)
{
// 出现错误：NACK、总线错误、仲裁丢失等
HAL_I2C_DeInit(hi2c);
MX_I2C1_Init(); // 重初始化恢复
HAL_I2C_Slave_Receive_IT(hi2c, rx_buffer, 10);
}
注意几点实践细节：
- 在 SlaveRxCpltCallback 中不要做耗时操作，只做标记即可。
- SlaveTxCpltCallback 里一定要重新启动接收，否则后续通信将无法触发。
- 错误回调中务必包含恢复机制，防止一次异常导致整个I2C“死掉”。
别忘了打开中断通道
很多初学者配置完一切却发现没反应，问题往往出在这里： 没有使能中断向量 。
确保在 stm32f4xx_it.c 中添加：
void I2C1_EV_IRQHandler(void)
{
HAL_I2C_EV_IRQHandler(&hi2c1);
}
void I2C1_ER_IRQHandler(void)
{
HAL_I2C_ER_IRQHandler(&hi2c1);
}
并在主函数中使能NVIC：
HAL_NVIC_SetPriority(I2C1_EV_IRQn, 0, 1);
HAL_NVIC_EnableIRQ(I2C1_EV_IRQn);
HAL_NVIC_SetPriority(I2C1_ER_IRQn, 0, 2);
HAL_NVIC_EnableIRQ(I2C1_ER_IRQn);
EV 是事件中断（如地址匹配、数据寄存器就绪）， ER 是错误中断（如总线错误、上溢/下溢）。两者缺一不可。
常见问题与调试技巧
1. 主机找不到从机？先看地址对不对
最常见原因是地址未左移。可以用逻辑分析仪抓包查看主机发送的地址字节是不是 0xA0 或 0xA1 （对应地址0x50的写/读）。如果看到的是 0x50 ，说明你在代码里漏了左移。
另一个可能是上拉电阻缺失。I2C是开漏输出，必须接4.7kΩ上拉才能正常拉高电平。没有上拉，总线***处于低电平，通信无法建立。
2. 接收中断不触发？检查是否真的启动了IT模式
有时候开发者只调用了 HAL_I2C_Init() ，却没有调用 HAL_I2C_Slave_Receive_IT() ，结果外设根本没有进入监听状态。记住：初始化≠启动接收！
可以在调试器中查看 hi2c1.State 变量，正常应为 HAL_I2C_STATE_BUSY_RX ，表示正在接收中。
3. 总线锁定怎么办？
当I2C进入错误状态且未及时恢复时，可能出现“Bus Busy”标志一直置位的情况。此时即使重启也无效。
解决办法有两种：
- 软件复位：调用 DeInit/Init 重建外设
- 硬件模拟释放：临时把SCL和SDA配置为推挽输出，手动输出9个时钟脉冲唤醒从机
后者更彻底，适用于严重锁死场景。
4. 如何提升稳定性？
缓冲区大小要合理 ：太小容易溢出，太大浪费内存。建议按最大预期报文长度+2字节冗余设计。
中断优先级要足够高 ：I2C事件中断应高于普通任务，避免因延迟响应导致NACK。
避免在回调中打印日志 ： printf 可能阻塞数十毫秒，足以破坏时序。
加入看门狗监控 ：长时间无通信可触发软重启，防止单点故障扩散。
典型应用场景举例
设想这样一个系统：一块主控MCU通过I2C管理三类子板——环境监测（温湿度）、显示屏驱动、继电器控制。每块子板上的STM32都是从机，拥有独立地址：
[主MCU]
│
├─→ [0x50] 温湿度采集 → 返回 float 类型数据
├─→ [0x60] OLED显示驱动 → 接收字符串刷新屏幕
└─→ [0x70] 继电器模块 → 接收ON/OFF指令
在这种架构下，主机只需依次寻址各从机即可完成全局状态同步。而每个从机只需专注自身职责，无需关心网络拓扑变化，极大提升了系统的模块化程度和可维护性。
写在最后：从“能用”到“好用”的跨越
把STM32设为I2C从机并不难，难的是让它在各种工况下都能稳定工作。HAL库为我们屏蔽了大部分底层复杂性，但也带来了新的挑战：如何正确使用回调机制？如何设计健壮的错误恢复流程？如何平衡性能与资源消耗？
真正优秀的嵌入式工程师，不是只会调通Demo的人，而是能在噪声干扰、电源波动、主机异常等各种现实条件下仍保证通信可靠的实践者。掌握I2C从机技术，不仅是学会一个API的使用，更是培养一种系统级的设计思维。
当你能把每一个从机节点都做得像“即插即用”的标准部件时，你的产品离工业化部署就不远了。
————————————————
版权声明：本文为CSDN博主「咖啡JSON」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/i1j2k/article/details/154452806
|
|
