測量性能

　　在早期的一些日子里，我的好奇心促使我想知道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.h庫來設置參數是輕而易舉的事情。

　　是我開始嘗試移植第12章中代碼的時候了：“黑屏”確實是一件有趣的事情。用PIC24，我能夠演示SPI端口是如何的簡單，只需要三只電阻器，幾個中斷，以及一些創新就可以產生一個復合視頻信號，特別是可以將任意的電視機轉換成單色顯示器。要產生一個視頻信號，需要中斷代碼與外設之間的精密協調。實際上，因為即便是在輸出定時上只差一個時鐘周期，在顯示器屏幕的左側就會產生可見的抖動（所有的豎直線都變得像鋸齒一樣），故訓練結果將是用于中斷“決策”的一個理想放大鏡，這是PIC架構傳統上一直出眾的特性。然而不幸的是，根據定義，指令預取和存儲器緩存機制都是非確定的。