EEPW论坛

顺便吐槽下这个芯片的烧录。每次需要烧录的时候，需要重新拔插相关管脚的连接。烧录完再取下来，换上测试用线路。唉，这一点真不如STC的方便。STC的MCU烧录时，都不用改动测试线路的连接。在线烧录是真的方便啊。

让大伙见笑了，哈哈哈。我也没想到有这么棘手。下午暂停了一下，静下心来，重新想想之前的调试过程以及结果，捋了捋，调整思路，重新启动了测试。结果是不太好，怀疑是芯片的问题，或者说，可能还是我哪个地方理解不到位，没有正确操作这个MCU的IIC外设。最后决定不再纠缠IIC的调试了。继续其它外设。虽然花了很多时间，走过一些弯路，但作为经历，还是觉得挺好的。像我这样的普通人，不可能做什么事儿都一帆风顺。遇到问题，能解决，就是能力的提高。不能解决，也没关系，可以作为一个经历，记下来，为以后做事儿提供一个参考。

补充一点，虽然作为标准外设，调试没成功，但是用IO方式模拟IIC通讯，这个芯片也是没问题，已经通过程序测试了。模拟方式，有一点不好，就是容易受到中断等处理的干扰，引起时序不正常，从而导致IIC通讯失败。而独立的IIC设备可以自己去处理，不受影响。这也我为啥坚持了两天，想把IIC搞通的原因，虽然结果并没达到预期。

根据上周的测试结果，我决定放弃了。因为真不是靠自己用软件能解决的了。

今天使10月31日，因为不死心，又重新测试了那个IIC的程序，终于找到问题出现的原因了。在

控制寄存器 IICCON中有一个AA的位，这个位在描述中：

应答标志位

 0：回复 NACK（SDA 上为高电平）

 1：回复 ACK（SDA 上为低电平）

之前我以为是从机收到数据后，主机会根据从机的回应来设置这个“AA”标志位。今天做的测试程序中，在发送要传送给从机的数据之前，根据从机的应答方式，提前设置这个位。比如从机在收到从机地址+写指令时，如果回应信号为ACK（即SDA=0），则设置：

IICCON |= 0x04;        // AA=1，确认子机回复ACK信号

这样测试后，终于实现主机****模式下的完整处理过程，和资料说明的一致了。

真不容易啊。隋然资料中没有明晰说明这个AA位应该如何处理，但我没有真正理解才是内因啊。