EEPW论坛

问题背景

      最近在拿nxp的板子点圆形屏玩（搞明白圆形屏是怎么管理显示区域的），一开始仅仅使用了MCUXpresso Config Tools生成了基础工程（仅仅打印hello world），无任何外围。在添加spi功能的时候，突然出现以下提示：

      一见这问题，心理咯噔了一下，难不成这工具还有坑？之后便跑去拿公版SDK里的spi例程玩了一遍，发现公版例程也好好的，这就更疑惑了。之后打开公版例程的mex文件查看，问题出来了，好家伙，公版例程压根就不用外设框架，直接手撸的代码，难怪不报错。

解决过程

    再回到我自己的工程，看那个有报错，就还是强行点生成代码看看，这个时候神奇的现象出来了，代码居然能生成，编译也能通过，但是实际操作时发现问题来了，整个工程里找不到操作spi的入口，也就是说，lpspi 相关操作的代码没在工程里面。

       知道问题点后，下一步就是手动添加缺失的lpspi文件了，由于整个工程都是基于nxp生成的基础SDK生成的，因此缺失的文件，在基础SDK中肯定也能找到，于是我跑到基础SDK的目录中搜索lpspi，还真能找到这个文件

       之后把文件拷贝到工程的驱动目录下

      并从工程中将缺失的文件添加至工程后再点编译

      神奇的现象来了，mex不报错了。

反思

      相比较于瑞萨的fsp操作，nxp采用了另一条路子，不把生成代码集成到MCUXpresso Config Tools中，而是两个单独隔离，这样解决了我一直吐槽的fsp过于臃肿的问题（最新的fsp大小达到了1.67G。而真正与我们所使用的芯片相关的代码只有那么几十兆左右）。但是mcx工具也做得不够完美，使用SDK生成工程后，并没有再去使用基础SDK，也就导致了我们在使用外设框架时，若导入新的外设，则需要从基础SDK中寻找并手动添加对应的驱动文件，其路径如下：

//SDK_PATH : SDK所在路径
//CHIP_NAME: 所需要芯片的名称
SDK_PATH\devices\CHIP_NAME\drivers

      这也可能是nxp自己的基础工程默认不启用外设框架，而是直接手撸代码的原因吧。毕竟重新生成工程，对应的依赖不能自动添加，仅仅是出提示挺不友好的，或许后面nxp能找到直接解决该问题的办法吧。