牛人工程师与PIC32一个月发生的研发故事

数很多的 32位芯片中是所期望的，PIC32在加电时通过默认的方式将这两个接口都激活了。如果为了利用一些PORTA I/O而不需要这些JTAG接口，则依赖应用程序来将其关闭。

　　自从我注意了JTAG接口后，我的第一个PIC32项目开始按期望工作，并发送出它的首个"Hello"，如图1所示。

　　图1：用PIC32产生字符串。

　　至此所学到的简单经验（振荡器配置和JTAG接口）迅速地证明了它们与我16位器件一书中前面各章节中绝大多数项目兼容性的关键，在随后几天的开发中移植都比较顺利。我利用UART与PC通信，用SPI接口与串行EEPROM通信，而利用Parallel Master Port与LCD模块通信。我利用A/D先读取电位器，然后读取温度传感器，演示了PIC32如何与模拟应用接口。除了模块的一些扩展功能以外，所有这些模块的工作都与我所预期的完全一致。我发现我的16位代码完全可以照用，几乎不需要任何的改变。

　　测量性能

　　在早期的一些日子里，我的好奇心促使我想知道PIC32究竟带来什么好性能。在我的16位器件一书的第四章中，即"Numb3rs"，我对执行基本的算术运算所需的指令周期数进行了统计，并将它们与各类整数和浮点类型进行了比较。这在时钟周期与所执行的指令密切相关的场合，如PIC24和dsPIC DSC内核中那样，这种方法是合理的。但在PIC32内核中，由于采用了MIPS的传统，为"比赛"增加了"难度"。每个时钟周期所执行的指令是可变的，因为当执行代码快于闪存额定速度（每30MHz只插入一个时钟周期）时可以插入等待状态，或者可以无关，这要归功于预取状态机（能够一次预取四条指令）。最后，激活一个高速缓存，进一步改进了高速性能。

　　PIC32的高速缓存使得周期数有点不可预测，也许变得没有意义。我好像觉得我从货物推车一下子升级到了一级方程式赛车一样！于是，我决定需要在32位器件一书中增加一章关于PIC32的性能调整内容。为了给PIC32加上重载荷，我找到我在大学读书时学习基本数字信号处理的一个老代码程序：即快速付里叶变换。我采用的是标准浮点结构，没有手工和编译器优化。另外还用了一个32 位定时器，让PIC32自己计时，随后我逐步地开始选用一些新的程序选项。

　　开始时，我激活指令预取，然后我找到高速缓存，再随后我通过人工方式调整等待状态。一开始性能改善极大，并且随着之后对配置进行进一步的细调，性能改善更多。最终，我意识到最佳的配置必须随应用定制，但必须由标准器件库中的SYSTEMConfigPerformance（）提供一个好的起点。

　　学习外设库

　　这是我第一次使用"标准"外设库，也是这种爱/恨关系的开始。由于我在非常小型的8位器件上使用汇编进行代码开发已经许多年了，且通常都是需要采用手工优化客户代码，我基本上都是自己亲自工作，最终我开发出了一些自己的器件库。

　　这一次，在投放PIC32产品之前一年多的时间，我不仅移植了16位器件的库，还对它们进行了扩展来支持一系列新功能。我没有更多的理由-唯一理由就是我自己必须掌握并学会如何使用它们。参见用于一个使用该外设库的程序代码段的Listings1和2，见图2。

　　图2：代码移植时用于一个使用该外设库的程序代码段的Listings1和2。

　　通过利用这个新库，16位和32位应用之间的代码兼容"绝对"没有问题。即便是外设寄存器上的极小差别也可以通过应用代码完全消除。实际上，这使得一个应用在16位器件和32位器件上都可以运行，从而开发人员面向两种架构，却维护统一的代码基。

　　不过，虽然在器件数据页中对硬件控制寄存器名称已有注明（甚至每一位都很详细），但却没有所有的功能/宏名及其参数。很多时候，我发现必须将单个的包含文件与器件数据页进行比较，尝试着去猜测究竟有哪些控制位与一个特定的库参数相关。当利用最简单的库（比如I/O端口操作）时，这是一件特别麻烦的事情，对我来说，在这里，库抽象层的优点更值得质疑。

　　最终，我发现可以采取一个平衡折中。即可以采用传统的方法访问绝大部分的基本外设 （例如I/O端口和计时器），而在使用更复杂/新外设时才使用库。于是，我迅速通过了有关代码的几个章节，实际上什么都没有改。这些章节包括：SD /MMC接口，FAT16文件I/O甚至包括WAV音乐文件重放。

　　当我决定再深入地研究中断时，以及后来开始使用PIC32的新DMA模块时，这些库的好处就变得很明显了。

PIC32提供两种中断选择：一种是非常类似于PIC16/18 8位架构操作方式的单矢量模式（顺便指出，与RTOS也更加友好），另一种是更类似于16位PIC24 MCU和dsPIC DSC工作模式的多矢量模式。利用interrupt.