最近ST的MCU真是一片难求，国产可代替的芯片真是雨后春笋，焊接几篇做实验，同样的程序，效果还不错，程序完美下载，运行也没什么问题。随着项目的继续进行，慢慢发现也有些不一样。用的事ARM的亲儿子Mbed OS，里面的固件驱动都是Mbed自带的，没有采用ST的HAL库。在用IIC控制EEPROM的时候就出现让我很迷惑的情况。写EEPROM没问题，但是连续读取数据的时候，最后一个总是0xFF，这样每次都得多读一个byte。
        开始笨方法测试：        只读一个byte，正确的；
        连续读2个byte，也是正确的；

        连续读3个byte，前2个byte是正确的，第3个byte就是0xFF；
        连续读4个byte，前3个byte是正确的，第4个byte就是0xFF；
        。。。。。。这不闹呢吗？
        用STM32F103的时候，从来没出现这种情况啊，我从来没怀疑过Mbed OS的固件问题，因为人家不可能有问题。看了半天源代码，也没什么别恶意改动的迹象。先用逻辑分析仪抓波形看看再说。下图是连续write操作，从图中看，每个write之后，EEPROM都会ACK，符合datasheet。
                        
        下图是连续read的操作，从图中看，要连续读取4个byte，按照datasheet的要求，前3个read操作，MCU会发送ACK，第4个read操作之后，MCU不会发送ACK，EEPROM会知道读取数据个数。但是从截图来看，在第2个read操作之后，MCU就没发送ACK，但是MCU还需要进行1次read操作，这样EEPROM就不会有动作，MCU读取的就是0xFF。错误的原因就在这里。
                        
         没办法了，换回仅有的几个STM32F103，就没出现上述情况，程序正常运行。看来Mbed的固件驱动，还不能和国产MCU完美契合。找到原因，毕竟也耽误了很长时间，暂时跳岛战术，下一步就用别的驱动，IIC就不用Mbed自带的驱动了。国产MCU型号为HK32F103RET6，99.999%代替STM32F103RET6，其实这么说不对，毕竟是驱动的问题，跟芯片关系不大。但是谁叫人家ST先出现，驱动就是给他们配套的。现在只是模仿，以后就是超越，希望国产越来越好。