【无标题】

浅析光模块固件之PC-MCU-Combo的I2C主从机编程

（对不起，我不是很明白如何在CSDN中插入图片。读者如果想看图，请email我给你带图的pdf，14518918@qq.com）

如下图，目前大部分光模块，在硬件上的通讯模式，是上位机PC通过USB转I2C芯片（比如CH341），去访问光模块内置的MCU的I2C从机（比如GD32E232），然后MCU再开一个I2C主机去访问更下层的Combo芯片（比如GNA4218）。所以，这里的MCU，在上层的CH341眼中是一个I2C从机，但是在下层的Combo眼中是一个I2C主机。

所以MCU的固件设计，就需要考虑在这种复杂的三角恋关系中，如何正确读写Combo的I2C寄存器，注意Combo的I2C寄存器，有部分是只读的比如ADC寄存器，有部分是可读可写的比如DAC寄存器。三者通过MCU中开辟的一片RAM缓存做数据交换。注意到，PC可通过I2Cs中断读写MCU的RAM映射区Buffer，而MCU也可通过I2Cm顺序读写Combo并更新到MCU的RAM映射区Buffer，显然MCU的RAM映射区Buffer既可以被PC写下值改写，也可以被Combo回读值刷新，所以MCU固件为了避免这个数据来源冲突，特意引入了控制模式这个命令字，默认是自动模式，但PC可更改成手动模式。

注意到， combo芯片上电复位后，其寄存器值会恢复成默认值，所以MCU在上电复位后之后，应该在初始化阶段，首先从MCU的FLASH读出历史数据并赋值到RAM映射区Buffer，然后还需要将次Buffer写入到Combo寄存器，这样Combo芯片就有了一个我们想要的工作状态。
比如，仅当固件处于自动模式下，MCU才可以循环读取Combo寄存器（比如Combo的ADC寄存器）并更新到MCU的RAM映射区Buffer；而当固件处于手动模式下时，PC必须要发特定的命令字，才能通知MCU去读取Combo寄存器（比如Combo的ADC/DAC寄存器）并更新到MCU的RAM映射区Buffer，这样固件在手动或自动模式下PC都可以读到变化着的Combo的ADC寄存器。
比如，仅当固件处于自动模式下，才允许MCU到温度查找表搜索出对应数据然后更新到MCU的RAM映射区Buffer并转而由MCU写入到Combo的DAC寄存器；而当固件无论处于自动模式还是手动模式下，MCU都会将RAM映射区Buffer写入到Combo的DAC寄存器。
注意到，PC更改MCU的RAM映射区Buffer是在I2C中断服务函数中完成的，而不是在主循环中完成，所以即使在自动模式下，前一步查找表更新了RAM映射区Buffer中的Combo芯片DAC值，后一脚PC通过I2C中断服务程序又改写了RAM映射区Buffer中的Combo芯片DAC值，那这之后在Combo中生效的DAC值是来自于PC下发的；但这是一次性的，之后的轮询又会在自动模式下用查找表中的DAC值覆盖掉RAM映射区Buffer 中的Combo芯片DAC值，然后Combo中生效的DAC值就是来自于温度查找表了。况且，一般客户没有工厂密码，MCU只能在自动模式下工作，所以是安全的。
注意到，PC改写combo的DAC值，可能将写很多次DAC才能找到最优值，所以固件被设计成在MCU手动模式下，PC写RAM映射区Buffer然后MCU再转写到Combo寄存器，并不会立即触发MCU将RAM映射区Buffer保存到FLASH的事件。意思是，如果PC想把当前的RAM映射区Buffer保存到FLASH，还是得必须发送存FLASH的命令字到MCU，MCU才会将当前RAM映射区Buffer写入到FLASH。

以上，苍白的文字太绕了，请参考下面的固件流程图，可能不那么烧脑：

下图展示了从流程图到源代码的对应关系：