AVR32 TWI多主机仲裁机制详解与寄存器级编程实战-洪萨配资

1. 从TWI到I2C：一个接口的两种视角

如果你用过AVR单片机，尤其是像AT32UC3系列这类AVR32内核的芯片，在数据手册里翻找I2C模块时，大概率会看到一个叫“TWI”的玩意儿。第一次见可能会愣一下：这和我熟悉的I2C是一回事吗？答案是：本质上，是的，但名字背后有故事。

TWI，全称Two-Wire Interface，翻译过来就是“两线接口”。这个名字是Atmel（现在被Microchip收购了）给它自家微控制器上实现的I2C兼容接口起的商标名。为什么不用I2C这个通用名？主要是因为I2C这个商标当时属于飞利浦（现在的NXP），其他厂商要生产兼容的硬件，不能直接用这个名字，所以就有了TWI、SMBus（系统管理总线）等变体。但它们在协议层面，与I2C是高度兼容的，特别是基础通信部分。所以，当你看到AVR32的TWI模块时，完全可以把它理解为一个功能完整的I2C主从控制器。

那么，为什么我们今天要专门聊AVR32的TWI，而不是泛泛地讲I2C？原因在于，AVR32的TWI模块在实现上，尤其是对多主机仲裁这一高级特性的硬件支持上，有其独特的设计和配置要点。很多开发者用I2C，大多停留在单主机、多从机的简单读写操作上，一旦系统复杂度上升，需要多个主设备（比如两个MCU都要去操作同一个EEPROM）时，软件模拟的I2C或者一些简化硬件的I2C模块就会捉襟见肘，而AVR32的TWI硬件则能优雅地处理这种冲突。理解它，意味着你能设计出更可靠、更健壮的多主控嵌入式系统。

这篇文章，我就以一个实际在AT32UC3A0512上调试过多主I2C系统的过来人身份，带你深入AVR32 TWI的寄存器级操作，并重点拆解那个让很多人觉得神秘又头疼的“多主机仲裁”机制。我们会从最基础的波形开始，一直讲到如何配置TWI模块参与仲裁、如何处理仲裁失败，以及如何避免常见的坑。目标很明确：让你不仅能看懂手册，更能写出稳定、高效的多主I2C代码。

2. I2C协议精要：不止是SDA和SCL

在深入TWI模块之前，我们必须统一语言，确保对I2C协议本身的理解在同一频道上。很多人对I2C的印象就是两根线（SDA数据线、SCL时钟线）、7位地址、起始停止条件。这没错，但这是骨架。要让多主机系统跑起来，我们必须理解它的“血液”和“神经”——也就是时序、应答以及最核心的仲裁与时钟同步机制。

2.1 基础时序与数据有效性

I2C的通信是同步、半双工的。所有数据位的传输都伴随着时钟信号。一个关键规则是：SDA线上的数据必须在SCL为低电平期间变化（即准备数据），在SCL为高电平期间保持稳定（即数据有效，可供读取）。起始条件（S）和停止条件（P）是特例：当SCL为高时，SDA一个从高到低的跳变是起始条件；一个从低到高的跳变是停止条件。AVR32 TWI硬件会自动检测和生成这些信号，这大大减轻了我们的负担。

关于速度，I2C有标准模式（100 kbps）、快速模式（400 kbps）、快速模式+（1 Mbps）和高速模式（3.4 Mbps）。AVR32的TWI模块通常支持到400kbps的快速模式。设置速度是通过配置时钟分频器实现的，计算公式在数据手册里，核心是依据你的主时钟频率（CLK_TWI）来计算一个CKDIV值，写入TWI_CWGR寄存器。这里有个经验：在计算出的理论值附近，可以稍微调大一点分频系数，给信号边沿留点余量，特别是在板子布线不太理想的时候，稳定性比极限速度更重要。

2.2 从地址、读写位与应答（ACK/NACK）

每个I2C帧始于一个地址字节。这个字节的前7位是从设备地址，第8位是读写方向位（0表示主设备要写数据给从设备，1表示主设备要从从设备读数据）。发送完这个字节后，主设备会释放SDA线（输出高电平），并在第9个时钟脉冲期间检测SDA线是否为低电平。如果是低，表示从设备应答（ACK）；如果是高，表示从设备无应答（NACK）。

AVR32 TWI模块在TWI_SR（状态寄存器）里有明确的位（例如RXRDY,TXRDY,NACK）来指示这些状态。我们的驱动代码需要紧密地查询或配合中断来处理这些状态。一个常见的误区是只检查数据是否发送/接收完成，而忽略了NACK状态。如果从设备不存在或忙，主设备会收到NACK，此时正确的做法不是盲目重试，而是根据协议发送停止条件终止本次传输，并进行错误处理。TWI模块的NACK标志位就是用来干这个的。

2.3 多主系统的基石：时钟同步与仲裁

这是本文的重头戏，也是硬件TWI价值凸显的地方。假设总线上有两个主设备（Master A和Master B）同时开始传输。

首先，它们会进行时钟同步。SCL线是“线与”的（通过上拉电阻接高电平，任何设备都可以拉低它）。每个主设备都会产生自己的SCL时钟。当它们同时输出时钟时，SCL线的实际低电平周期，将由那个输出最长低电平周期的主设备决定；而SCL线的高电平周期，则由那个输出最短高电平周期的主设备决定。最终，总线上的SCL是所有主设备时钟的“与”结果。这个过程是硬件自动完成的，AVR32 TWI模块在作为主机时会自动同步到总线的SCL上，我们无需干预。

接着，更关键的是仲裁。仲裁发生在SDA数据线上。同样基于“线与”原理。在SCL高电平期间，每个主设备都会把自己想要发送的数据位（或地址位）放到SDA上，并同时回读SDA线的实际电平。如果回读到的电平与自己发送的电平一致，说明它“抢”总线成功，可以继续。如果不一致（例如，自己发送了高电平‘1’，但回读到的是低电平‘0’），说明总线上有另一个主设备发送了更强的‘0’（因为‘0’是拉低线路），自己就仲裁失败了。

仲裁是一个逐位进行的过程，从地址字节的最高位（MSB）开始比较。谁的地址数值小，谁就在仲裁中胜出。因为二进制中，先出现‘0’的数值更小。例如，Master A发送地址0x50 (二进制 101_0000)，Master B发送地址0x68 (二进制 110_1000)。在比较第一位（bit7）时，A发‘1’，B发‘1’，总线为‘1’，都通过。比较第二位（bit6）时，A发‘0’，B发‘1’。此时，A拉低了SDA线，总线实际为‘0’。B检测到自己发‘1’但读到‘0’，就知道仲裁失败，会立即切换到从机接收模式，并监听总线，看胜出的主设备是否在呼叫自己（地址匹配）。

AVR32 TWI模块的硬件会自动处理整个仲裁过程。当它检测到自己仲裁失败时，会设置一个状态标志（通常是TWI_SR里的ARBLST，仲裁丢失位），并产生一个中断（如果使能了）。同时，硬件会自动将自身从主机发送模式切换到从机接收模式，并释放SDA和SCL线。我们的软件责任是：及时检测到这个ARBLST标志，然后执行清理操作（比如清除状态标志，重置内部状态机），并等待下一次发送机会。绝对不能忽略这个标志，否则TWI模块可能会卡在一个奇怪的状态，导致后续通信全部失败。

3. AVR32 TWI模块寄存器级编程指南

理解了协议，我们来看如何操作AVR32的TWI模块。我将以AT32UC3A系列为例，其他AVR32型号的寄存器名可能略有不同，但思想相通。我们主要关注几个核心寄存器：TWI_CR（控制寄存器）、TWI_MMR（主模式寄存器）、TWI_CWGR（时钟波形发生器寄存器）、TWI_THR（发送保持寄存器）、TWI_RHR（接收保持寄存器）和最重要的TWI_SR（状态寄存器）。

3.1 初始化：主模式与时钟配置

初始化TWI为主机模式，主要做三件事：配置引脚、设置时钟速度、使能主模式。

// 假设使用TWI0， SDA: PA3, SCL: PA4 void twi_master_init(void) { // 1. 配置GPIO为外设功能，开启上拉（内部或外部上拉电阻必须接！） // AVR32的GPIO配置略过，具体参考芯片的GPIO模块，将PA3和PA4功能选择为TWI。 // 2. 设置时钟速度 (以主时钟CLK_TWI = 60MHz, 目标100kHz为例) // 计算公式: T_low + T_high = (CLK_TWI / (2 * SCL频率)) - 4 // 通常令 T_low = T_high，所以每个半周期计数值 CKDIV = (CLK_TWI / (2 * SCL频率) - 4) / 2 // 对于100kHz: CKDIV = (60,000,000 / (2 * 100,000) - 4) / 2 = (300 - 4) / 2 = 148 // TWI_CWGR 格式: {CLDIV, CHDIV, CKDIV}。 简单模式下，CLDIV=CHDIV=CKDIV。 TWI0->TWI_CWGR = (148 << 16) | (148 << 8) | 148; // 3. 使能主模式 (通过向TWI_CR写入MSEN位) TWI0->TWI_CR = AVR32_TWI_CR_MSEN_MASK; }

注意：TWI_CWGR的计算是精确时序的关键。数据手册的公式可能更复杂，涉及CLDIV、CHDIV、CKDIV三个字段来分别控制SCL低电平、高电平和时钟分频。对于大多数标准应用，将它们设为相同的值（如上述例子）是可行的。但对于需要精确调整占空比以匹配特定从设备需求的情况，就需要分开配置。

3.2 发送流程：从起始条件到数据写入

一次完整的写操作（主发送）流程如下，我们需要严格遵循状态机的引导：

uint8_t twi_master_write(uint8_t slave_addr, uint8_t reg_addr, uint8_t data) { uint32_t status; uint32_t timeout = 100000; // 超时计数器 // 1. 设置主模式寄存器 (MMR): 从机地址 + 写方向 TWI0->TWI_MMR = 0; TWI0->TWI_MMR = (slave_addr << 16) | AVR32_TWI_MMR_MREAD_MASK; // MREAD=0 表示写 // 2. 发送起始条件 (START) TWI0->TWI_CR = AVR32_TWI_CR_START_MASK; // 3. 等待TXRDY（发送保持寄存器空），准备发送第一个数据字节（寄存器地址） while (!((status = TWI0->TWI_SR) & AVR32_TWI_SR_TXRDY_MASK)) { if (--timeout == 0) return TWI_ERROR_TIMEOUT; // 检查仲裁丢失或NACK错误 if (status & AVR32_TWI_SR_ARBLST_MASK) { // 处理仲裁丢失 TWI0->TWI_CR = AVR32_TWI_CR_STOP_MASK; // 发送停止条件（某些型号需要） TWI0->TWI_SR; // 读SR以清除标志（根据手册要求） return TWI_ERROR_ARBITRATION; } if (status & AVR32_TWI_SR_NACK_MASK) { // 从机无应答 TWI0->TWI_CR = AVR32_TWI_CR_STOP_MASK; TWI0->TWI_SR; return TWI_ERROR_NACK; } } // 4. 写入寄存器地址到发送保持寄存器(THR) TWI0->TWI_THR = reg_addr; // 5. 再次等待TXRDY，发送数据字节 timeout = 100000; while (!((status = TWI0->TWI_SR) & AVR32_TWI_SR_TXRDY_MASK)) { if (--timeout == 0) return TWI_ERROR_TIMEOUT; if (status & (AVR32_TWI_SR_ARBLST_MASK | AVR32_TWI_SR_NACK_MASK)) { // 错误处理同上 TWI0->TWI_CR = AVR32_TWI_CR_STOP_MASK; TWI0->TWI_SR; return (status & AVR32_TWI_SR_ARBLST_MASK) ? TWI_ERROR_ARBITRATION : TWI_ERROR_NACK; } } TWI0->TWI_THR = data; // 6. 等待数据发送完成 (TXCOMP标志) timeout = 100000; while (!((status = TWI0->TWI_SR) & AVR32_TWI_SR_TXCOMP_MASK)) { if (--timeout == 0) return TWI_ERROR_TIMEOUT; // 同样需要检查错误 if (status & (AVR32_TWI_SR_ARBLST_MASK | AVR32_TWI_SR_NACK_MASK)) { TWI0->TWI_CR = AVR32_TWI_CR_STOP_MASK; TWI0->TWI_SR; return (status & AVR32_TWI_SR_ARBLST_MASK) ? TWI_ERROR_ARBITRATION : TWI_ERROR_NACK; } } // 7. 发送停止条件 (STOP)。注意：有些TWI模块在TXCOMP置位后会自动发送STOP，需查手册。 // 如果不会自动发送，则需要手动发送。 TWI0->TWI_CR = AVR32_TWI_CR_STOP_MASK; return TWI_SUCCESS; }

这段代码展示了最基础的轮询式发送。几个关键点：

顺序：先配置MMR，再发START。
状态查询：每一步操作后都要等待相应的状态位（TXRDY,TXCOMP），并且在等待循环中必须持续检查错误标志（ARBLST,NACK）。这是写出健壮TWI驱动的核心。
错误恢复：一旦检测到ARBLST或NACK，应立即发送STOP条件（如果总线还没被释放）来清理总线状态，并清除状态寄存器标志（通常通过读TWI_SR实现），然后返回错误码。对于仲裁丢失，主设备应延迟一个随机时间后重试，以避免和另一个主设备持续冲突。

3.3 接收流程与重复起始条件

读操作稍微复杂一点，因为它通常涉及一个“写地址-读数据”的过程，中间用重复起始条件（Repeated START， Sr）衔接，而不是停止条件。

uint8_t twi_master_read(uint8_t slave_addr, uint8_t reg_addr, uint8_t *data) { uint32_t status; uint32_t timeout = 100000; // --- 第一阶段：发送寄存器地址（写操作）--- TWI0->TWI_MMR = (slave_addr << 16) | 0; // MREAD=0, 写 TWI0->TWI_CR = AVR32_TWI_CR_START_MASK; // 等待并发送寄存器地址 while (!((status = TWI0->TWI_SR) & AVR32_TWI_SR_TXRDY_MASK)) { if (--timeout == 0) return TWI_ERROR_TIMEOUT; if (status & (AVR32_TWI_SR_ARBLST_MASK | AVR32_TWI_SR_NACK_MASK)) { /* 错误处理 */ } } TWI0->TWI_THR = reg_addr; // --- 第二阶段：发送重复起始条件，切换为读模式 --- // 等待寄存器地址发送完成（不是整个传输完成，所以不是TXCOMP） // 可以等待TXRDY再次置位，表示THR已空，地址字节已移出。 timeout = 100000; while (!((status = TWI0->TWI_SR) & AVR32_TWI_SR_TXRDY_MASK)) { if (--timeout == 0) return TWI_ERROR_TIMEOUT; if (status & (AVR32_TWI_SR_ARBLST_MASK | AVR32_TWI_SR_NACK_MASK)) { /* 错误处理 */ } } // 现在发送重复起始条件 (RESTART) TWI0->TWI_CR = AVR32_TWI_CR_START_MASK; // 再次写入START命令即产生Sr // 重新配置主模式寄存器为读模式 TWI0->TWI_MMR = (slave_addr << 16) | AVR32_TWI_MMR_MREAD_MASK; // MREAD=1, 读 // --- 第三阶段：读取数据 --- // 对于单字节读取，需要在启动接收后，发送停止条件（或NACK+停止） // 先等待接收数据就绪 (RXRDY) timeout = 100000; while (!((status = TWI0->TWI_SR) & AVR32_TWI_SR_RXRDY_MASK)) { if (--timeout == 0) return TWI_ERROR_TIMEOUT; // 读模式下也要检查仲裁丢失 if (status & AVR32_TWI_SR_ARBLST_MASK) { /* 错误处理 */ } } // 读取一个字节前，先设置“收到下一个字节后发送NACK并停止” // 这通过向TWI_CR写入STOP命令实现。注意时机：在读取最后一个字节前。 TWI0->TWI_CR = AVR32_TWI_CR_STOP_MASK; // 现在读取数据 *data = TWI0->TWI_RHR; // 等待传输完全结束 (TXCOMP) timeout = 100000; while (!(TWI0->TWI_SR & AVR32_TWI_SR_TXCOMP_MASK)) { if (--timeout == 0) return TWI_ERROR_TIMEOUT; } return TWI_SUCCESS; }

重要提示：重复起始条件的处理是TWI编程中的一个难点。不同厂商、甚至同一厂商不同系列的TWI模块，对“何时发送STOP命令来产生读操作后的NACK和停止条件”的时序要求可能不同。有些需要在读RHR之前发送STOP，有些需要在之后。务必仔细阅读你所用的AVR32型号的数据手册中关于“主接收器”模式的流程图和描述，这里的示例代码是一种常见模式，但可能需要调整。

4. 多主机仲裁实战：从硬件标志到软件策略

现在，让我们聚焦到多主机仲裁。硬件帮我们检测到了ARBLST，但软件策略决定了系统在冲突下的行为是否优雅。

4.1 仲裁丢失的检测与即时处理

当TWI模块在主机模式下参与仲裁并失败时，硬件会：

立即停止驱动SDA和SCL线。
将自身模式从主机切换到从机（监听模式）。
在TWI_SR寄存器中置位ARBLST标志。
可能产生一个中断（如果使能了）。

你的驱动代码必须在每次状态查询中检查这个位。就像前面示例代码里做的那样。一旦检测到，必须：

发送STOP条件：尽管硬件已经释放总线，但发送一个STOP命令是良好的习惯，确保状态机完全复位。有些情况下，如果仲裁丢失发生在地址阶段，胜出的主设备可能会继续通信，你不需要也不应该再发STOP，但为了代码通用性，通常还是发一个更安全。
清除标志：通过读取TWI_SR寄存器来清除ARBLST位（读操作会自动清除某些状态位，具体请查手册）。
重置内部状态：你的应用程序或驱动状态机应该回到“空闲”或“准备发送”状态。
计划重试：这是关键。不能立即重试，否则两个主设备又会立刻冲突，导致活锁（livelock）。必须引入退避机制。

4.2 退避算法：避免活锁的简单策略

最简单的退避算法是指数退避。在仲裁失败后，主设备等待一段随机时间再重试。

void twi_handle_arbitration_lost(void) { // 1. 清理TWI模块状态 TWI0->TWI_CR = AVR32_TWI_CR_STOP_MASK; (void)TWI0->TWI_SR; // 读SR以清除ARBLST等标志 // 2. 指数退避 static uint16_t backoff_delay = 1; uint32_t delay_ms = (rand() % (1 << backoff_delay)); // 随机延迟 0 到 (2^backoff_delay - 1) ms if (backoff_delay < 10) { // 设置一个上限，比如10 backoff_delay++; } delay_ms(delay_ms); // 自定义的毫秒延迟函数 // 3. 重试上一次失败的操作（这需要你的上层逻辑来保存上下文） // retry_last_transaction(); }

更复杂的系统可能会根据主设备的优先级或消息紧急程度来调整退避时间。核心思想是：引入随机性，打破冲突的对称性。

4.3 作为从设备参与仲裁：监听与响应

当你的AVR32作为从设备时，它也可能被总线上仲裁胜出的主设备访问。TWI模块的从机模式需要正确配置（设置TWI_SMR从机模式寄存器中的自身地址，并使能从机模式SVDIS位清零）。

在多主系统中，从设备的行为和单主系统一样：地址匹配则应答，否则忽略。但有一个细微差别：由于仲裁可能在任何时候发生，从设备必须能处理被意外中断的通信（尽管这种情况很少，因为仲裁通常发生在起始条件后的地址字节阶段）。稳健的从机代码应该设置超时，如果在一段时间内没有收到完整的报文，就复位自己的接收状态机。

5. 调试多主TWI系统的实用技巧与坑点

调试I2C本身就不易，多主系统更是把难度提升了一个级别。以下是我在实际项目中积累的一些经验：

1. 一定要用逻辑分析仪或示波器这是铁律。软件打印日志在时序问题上几乎没用。你需要亲眼看到SDA和SCL线上的波形，看起始、停止、地址、数据、ACK/NACK位，特别是看仲裁发生时波形的变化。逻辑分析仪配合I2C解码功能是神器。

2. 上拉电阻是关键I2C总线依靠上拉电阻将线路拉到高电平。电阻值的选择是门学问：

阻值太大：上升沿太慢，在高速模式下可能达不到高电平阈值，导致通信错误。
阻值太小：当器件拉低线路时，电流过大，增加功耗，可能超出IO口的驱动能力。
典型值：对于3.3V系统，100kHz用4.7kΩ，400kHz用2.2kΩ是常见的起点。但最终要根据总线电容（线长、连接设备数）调整。总线电容（C_bus）越大，RC时间常数越大，上升越慢。公式R_max = (t_r) / (0.8473 * C_bus)可以作为参考，其中t_r是协议允许的上升时间。

3. 注意电源与电平兼容性如果总线上的主从设备使用不同电压（如3.3V和5V），必须进行电平转换，不能直接连接。可以使用专用的I2C电平转换芯片（如TXS0102、PCA9306等）。

4. 仲裁测试的“土方法”在没有两个真实主设备时，如何测试仲裁逻辑？一个办法是用一个主设备（MCU的TWI）和一个能模拟I2C主机的工具（如FTDI的FT232H/FT2232H芯片配合MPSSE命令，或者专用的I2C主机适配器）。让它们同时尝试访问同一个从设备地址，用逻辑分析仪抓取波形，观察ARBLST标志是否被正确置位。

5. 中断 vs 轮询对于简单的单主系统，轮询足够。但对于多主系统，或者主设备需要同时处理其他任务时，使用TWI中断是更好的选择。可以使能TWI_IER（中断使能寄存器）中的TXRDY、RXRDY、TXCOMP以及ARBLST、NACK等错误中断。在中断服务程序（ISR）中，根据状态标志位来驱动一个状态机，完成整个传输序列。这能大大提高CPU效率，并确保对总线事件的快速响应。

6. 软件模拟I2C的局限性很多教程教用GPIO模拟I2C（软件I2C）。这在单主、低速、从设备简单的场合可行。但它无法实现多主机仲裁，因为仲裁依赖于在SCL高电平期间“回读”SDA线并与自身输出比较，这个动作需要硬件在单个指令周期内完成，软件模拟的时序精度和原子性都无法保证。所以，如果你需要多主功能，必须使用硬件TWI模块。

深入AVR32的TWI接口，特别是吃透它的多主机仲裁机制，就像获得了一把处理复杂嵌入式系统内部通信的钥匙。它不再是简单的点对点读写，而是一套带有冲突检测和恢复机制的微型网络协议。从理解“线与”逻辑和逐位仲裁的原理，到熟练操作MMR、CWGR、SR这些寄存器，再到在驱动代码中妥善处理每一个ARBLST和NACK标志，每一步都需要耐心和严谨。调试过程可能会充满挫折，但当你看到两个MCU通过同一组导线有序地交替访问一个传感器，而不会互相干扰时，那种成就感是对这些复杂细节最好的回报。记住，硬件提供了强大的基础，但最终系统的稳健性，取决于你的软件对每一个边角情况的考量与处理。