手里的项目开发在一个月前就已经结束了，最近这一个月一直在对代码、进行调整，查找BUG，对显示效果进行细节上的调整。首先，说一下对CPU频率，操作系统的新的体验。原来一直认为在处理过程中，显示停顿、功能不能成功的原因是CPU主频不够，毕竟NXP的2214只有50M左右的速度，后来发现，原来50M可以干这么多事，才明白在PC上开发原来是一件这么令人开心的事--不用为存储空间、CPU速度考虑太多，实现功能就是了。而手头的嵌入式应用，在功能完成后，离产品还有一段距离那。并且在对其进行优化过程中，会强迫自己进行很多方面的考虑。对嵌入式应用来讲，瓶颈是多方面的，CPU速度不够，RAM，flash空间比较小。这就导致很多东西都需要调整。而这几方面很多时候是关联在一起的，占用的flash空间比较大，就必然有指令上的冗余，执行自然比较慢。近1个月来，对其调整总结如下--调整备忘录
由于使用CPU配置FPGA，FPGA的配置文件必然放在flash空间中，这就导致flash空间中既运行程序代码，有需要读取配置数据，执行速度自然很慢，由于我们目前有2块flash，一块是CPU内的片内flash，比较小，另一块是片外用于存放程序的4M Norflash，将FPGA配置数据放在片内flash中，将程序代码放在片外flash内，这样可以避免读取指令与读取数据上的冲突，小幅提升速度，在这个过程中发现系统的主要瓶颈在于对flash的写操作，以及CPU读取片外flash指令的速度上，将CPU超频到88M，速度提升很多，似乎问题就此解决，但CPU超频是产品开发中的禁忌，当时我也一筹莫展，思维局限在CPU速度慢，处理速度不够上，似乎除了超频没有更好的办法了。仔细分析系统运行瓶颈所在，发现主要原因是CPU读取片外flash中的指令太慢，由于使用片外flash，不像片内flash那样有8条指令缓冲，读取flash速度、执行速度极快。不过就是没有缓冲，似乎也不应该执行片外指令这么慢。最终发现，问题出在对片外flash芯片读写速度的控制上，最初为了保险起见，将flash的读取、写入速度都按等待最大时钟周期设定的，就是NXP 2214的BCFG0寄存器，仔细根据NORFLASH芯片手册其最短读取、写入周期，及CPU速度计算，重新填写该寄存器，速度有了大幅提升，执行指令速度加快，相应的读写flash速度变快。性能有了大幅提升。
但在进行flash速度优化后，进行FPGA配置过程中，还是速度太慢，当时的想法是已经没有什么可以优化的了，就申请使用FPGA配置芯片进行配置，不使用CPU配置了。事情似乎就此解决了。但对代码的优化并没有停止，通读代码，将代码中很多调试代码删除，对系统各项功能进一步测试。在整理编译的makefile时，突然想起，在编译过程中没有开启编译优化选项，马上开启试一下，哈哈，发现开启后对FPGA的配置速度又提升很多很多，性能已经能够满足系统要求，FPGA配置芯片可以省去。这个东西就像编译器免费提供的黑科技一样，大体了解一下编译优化通过很多方式减少编译后代码长度，提高执行效率，真是不可多得的好东西。但同时也产生了一个很关键的问题，那就是----由于编译器如何优化是我们所不知道的，优化中会修改指令的顺序，也就是编译器按照自己对代码的理解修改代码，这就导致最终的程序并不是完全按照我们的代码生成的，所以如果这个优化在性能能够满足的情况下，还是不开启的好，虽然编译器手册上说，不优化用于DEBUG，优化用于RELEASE，但开启优化后，我的代码在运行中就发现了一个莫名其妙的错误，由于问题只是在优化后出现的，错误实在不好定位，不得不挨个文件的开启/关闭优化选项，编译、测试，最终确认就是一个文件的优化造成这种结果，取消对该文件的编译优化，问题解决，对该文件代码仔细阅读，没有发现代码有错误。由于编译器并不会告诉你他是如何优化的，所以即使定位到问题所在的文件，依然不能修正该错误，只要取消对该文件优化，进行编译。这中间的过程非常耗费时间。所以如果不是因为性能达不到要求，或者不是嵌入式应用，我还是感觉这优化选项可开可不开。
最后调整系统中每个线程所分配的堆栈空间大小，减少系统RAM使用空间，为下一步开发留出比较大的资源。 |
楼主
标题置顶
标题高亮
