最近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先出现，驱动就是给他们配套的。现在只是模仿，以后就是超越，希望国产越来越好。
开始笨方法测试： 只读一个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先出现，驱动就是给他们配套的。现在只是模仿，以后就是超越，希望国产越来越好。
作者： 小六子， 来源：面包板社区
链接： https://mbb.eet-china.com/blog/uid-me-1589624.html
版权声明：本文为博主原创，未经本人允许，禁止转载！
- 上一篇： 无线模块板载天线调整
- 下一篇： 【2022年终总结】回归
文章评论（5条评论）
登录后参与讨论-
返回顶部
-
自做自受 2022-6-1 15:46
知乎网站上一文《中国的科技水平和美国差距有多大？》有说法。
反思，欧美国家也搞这样如此强调的国产替代吗？
忆轻狂 2022-6-1 13:50
自做自受 2022-5-18 16:18
手头事做合格，大战略可以想，思考也学习，也乐趣。
呵呵，我想来想去，感觉坑是绕不过去的，比如当下为何又这么注重“国产替代”？要能替代，早该替代了？
小六子 2022-5-17 20:59
自做自受 2022-5-16 23:00