热度 8
2022-5-15 21:54
3919 次阅读|
5 个评论
最近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先出现,驱动就是给他们配套的。现在只是模仿,以后就是超越,希望国产越来越好。