spi相关调试

      上一篇博客聊了聊I2C相关的项目心得，这一篇打算聊一聊SPI相关心得体会。说说标题吧，为什么叫SPI相关调试，我们都知道SPI是一种板级总线，如果单纯描述SPI协议，个人觉得网上有更好的资源，没有必要进行重复性的工作。然后从目的出发，我们要做的是应用SPI总线来完成相应通信任务，以用为主。综上两点，此篇博客名叫做SPI相关调试。

       SPI是主芯片与从设备之间“美好”的桥梁，我在项目中常见的有SPI_fram、SPI_Flash，意思就是CPU通过SPI总线连接fram（铁电），连接Flash之类的存储设备，将用户所需的数据通过SPI总线传入该存储类设备中进行掉电保存。除了通过SPI总线进行数据上的传输，在其他项目中还见过fram、norflash之类的设备挂在Local_bus（local_bus相关资料大家可以上网进行相应查找）上。关于总线、设备之类的，个人觉得宏观的概念有时比细节更为重要，没有宏观上的认识，在调式相关代码时，你对于代码的把握就会缺少灵魂。当缺少灵魂的时候，对于有些细节，你就不知道为什么这么写，感觉比较空洞。

       回到项目中，在项目中CPU通过SPI总线挂了fram、flash，要做的工作是对fram、flash进行驱动调式。这里主要讲讲SPI_fram的调试（fram驱动就是参考flash改的），那么这个驱动该如何调，没有现成的fram驱动可以参考。这里首先得进行宏观上的把握，fram驱动看似一件事情，但是你心中应该明白这件事应该分为两层首先是SPI、然后是fram硬件本身。

       我这里说点废话，说说我这里调式fram的相关参考代码背景，给我参考代码是vx下的代码。其种fram驱动走的是Vxbus（当时我心中只有一句mmp），这又带入了新的概念Vxbus，Vxbus是什么呀，我这里用一句话简单概括就是一种软件架构。当时刚刚调fram驱动的时候没有这些概念，宏观上就是一脸懵逼，代码也是越看越糊涂。由于我们适配的系统下是不走Vxbus的，当时单位同事给的建议是将Vxbus进行剥离。这个过程很痛苦，因为这件事情做得没有方向，一种迷路的感觉。这时候对于fram，你得分为三件事来分析了Vxbus+SPI+fram，我当时感觉从Vxbus的架构中调出fram驱动比较迷茫。当时就换了思路，与其从Vxbus中挑驱动，不如直接找一个可以用SPI代码，然后再来驱动Fram（当然做件事你的方向就变成了找spi相似驱动代码）。很幸运公司有其他同事调过ESPI，对比一下相关寄存器信息，目测应该是可以拿过来使用的。说了一大圈就是想提醒大家得有宏观上的把控，尤其是碰到自己不熟悉的知识概念。我在碰到这个问题时，第一种思路从Vxbus的细节概念中摘除Vxbus显然不适合现在的我，越摘越迷茫；第二种思路从宏观上摘除Vxbus，索性找一个与Vxbus没有关联的驱动，可能效果来得更快。

       来到spi驱动本身，代码细节我就不讲了，无法就是初始化，以及SPI的读写。接下来就是调试Fram的读写，在调试之前总得验证一下SPI工具好不好用吧，所以第一步找个软柿子，试试SPI。通过先来读读此设备的ID，如果能正确读出硬件ID号，说明寄存器相关配置基本可以用，SPI指令也没问题，接着再来调读写。fram没有现成驱动，可以参考flash，只是从端改变了，SPI基本上不用改变，改改相应读写指令即可，逻辑基本上可以复用。至于具体分析fram如何写，如何读，这种事情我不干。具体情况大家自己具体分析。