如何提升RT1050的代碼運行速度，使其發(fā)揮最大性能

本文以RT1050為例，講解如何提升RT1050的代碼運行速度，使其發(fā)揮最大性能，并列出在提升性能過程中可能會遇到的問題以及解決辦法。

1.是誰影響了代碼運行速度？

在一般的MCU開發(fā)中，我們習慣性的將代碼直接下載到MCU的內部Flash中，并直接在內部Flash中運行，在I-CODE、D-CODE總線以及自帶的Flash加速器加持下，這么做似乎也沒什么問題。但作為一款高性能并擁有最高600M主頻的跨界MCU，RT1050并沒有內置Flash。那么在實際開發(fā)中，就必須外置一塊 NOR Flash用于代碼的存儲。

如果此時我們還像之前開發(fā)一般MCU那樣，讓代碼在Flash運行，就會受限于Flash的讀寫速度，以及MCU與Flash之間的通信速度。那感覺，就像開著V12引擎的布加迪，跑在限速40的公路上，完全發(fā)揮不出來600M主頻的性能，更別談讓代碼的運行速度飛起來了。

2. 如何讓代碼運行速度飛起來！

代碼必須存儲在Flash中實現(xiàn)掉電不丟失，而與此同時，我們又要求發(fā)揮600M主頻的最大性能，讓代碼的運行速度飛起來，可能你還沒想好怎么做，那就跟著小編一起，由淺到深，用實際可行的方案，一步步提升代碼運行速度，并解決在提升代碼速度時遇到的阻礙，最后讓代碼的運行速度飛起來。

2.1運行域和加載域的概念

既然在Flash中運行代碼效率不高，那我們首先想到的辦法，就是不讓代碼在Flash中運行，那就不得不提到運行域和加載域的概念。

代碼在通過編譯器鏈接器的處理后生成了固件文件，此時有兩個相關概念需要留意，就是加載域和運行域。

加載域的意思是代碼要下載到哪里。這里肯定要選擇下載到Flash中。運行域的意思是代碼在哪里運行。例如我們可以指定代碼在RAM中運行，那么在__main中，就會將相關代碼都拷貝到RAM中，在程序運行時，就會去RAM空間取指、譯碼、執(zhí)行。加載域和運行域的定義可以在分散加載文件中完成。

聽起來是個不錯的想法，但是在實施的過程中，就會遇到一個問題，我們所說的代碼，也就是固件的CODE部分，也包含了中斷復位函數(shù)。我們知道，程序在上電時，硬件會去相對地址0x00處取棧指針，而后偏移一個字，取復位中斷函數(shù)地址，并在復位中斷函數(shù)中執(zhí)行系統(tǒng)初始化函數(shù)SystemInit和__mian函數(shù)，并在__mian函數(shù)中實現(xiàn)不同運行域的代碼拷貝。按照這種硬件機制，有一些代碼是要在代碼拷貝之前運行的。

因此我們并不能將所有代碼的運行域都拷貝到RAM中運行。這也是為什么分散加載文件規(guī)定，加載域中的第一個運行域，其起始地址必須和該加載域起始地址相同。

一種可行的辦法是將不能更改運行域的代碼提出來，放在加載域的第一個運行域，用于上電啟動過程，然后將其他代碼段的運行域放在RAM中，這樣一來，在上電啟動過程完成，進入到mian函數(shù)后，代碼都是在RAM中運行的，其速度會有飛一樣的提升。分散加載文件中相關示例配置和注釋如圖1所示。

圖1 運行域分配

2.2RAM空間的優(yōu)化

以為上述的配置完成之后就可以起飛了嗎？不，還差一點。如果再對RT1050的存儲結構多點了解，就會發(fā)現(xiàn)其內部的RAM空間被分成了三個部分。包括ITCM、DTCM和OCRAM。這三個部分共享512K的RAM空間。在默認配置下，ITCM和DTCM各占128K、OCRAM占256K。

根據RT1050的內部總線結構，將代碼段放在ITCM、數(shù)據段放在DTCM中，可以帶來更高的性能和更快的代碼速度。其分散加載的示例配置如圖2所示。

圖2 DTCM空間和ITCM空間分配

講道理，經過這樣的處理之后，我們已經將代碼和數(shù)據的運行域放在了整個RT1050運行最快的位置，其600M主頻的性能也能最大力度的發(fā)揮出來。但是這樣做是不是就大功告成了呢？可能還不是，在實際的項目開發(fā)中，還會遇到一些其他的問題。

2.3其他的一些問題

2.3.1 代碼和數(shù)據容量的問題

如果不考慮整個工程的代碼大小，之前所做的一切都是很OK的，但是往往會遇到一種情況，就是代碼量或者數(shù)據量太大，已經超出了范圍。

如果只是超過了RAM默認的配置范圍，那可以將RAM的空間重新分配，以32K為單位，可以按照實際需要調整ITCM和DTCM的空間大小，不過有兩點需要注意，一是OCRAM至少要保留32K的空間大小、二是一定要在__main之前調整好RAM的分區(qū)，否則在__mian函數(shù)中拷貝函數(shù)拷貝代碼時就會因為空間不足而產生硬件錯誤。

一種可行的辦法是在復位中斷函數(shù)的起始位置通過匯編指令去調整RAM的分區(qū)，示例代碼如圖3所示。主要是修改三個寄存器中內容，詳細信息可查閱參考手冊中相關的部分。

圖3 通過匯編指令調整RAM分區(qū)

如果代碼或者數(shù)據的容量已經超出了RAM區(qū)域能調整的范圍，那就不能將代碼和數(shù)據的運行域都放在RAM中了。例如使用libpng解碼庫解碼png圖片，可能需要1M以上的堆空間。在這種情況下，可以使用一塊大容量的SDRAM作為輔助，雖然代碼運行的速度沒有在RAM中高，但是解決了RAM空間本身不是很充足的問題，且在SDRAM中運行代碼肯定會比在Flash中運行代碼要快上很多。

有了SDRAM的加持，就可以選擇性的將需要高速運行的代碼或者關鍵數(shù)據放在RAM的空間。一些不需要高速運行的代碼或者數(shù)據放在SDRAM的空間。如果需要使用的堆太大，也可以將堆的空間放在SDRAM中。

通過這種策略靈活的調整之后，在最佳性能和代碼量之間能找到一個平衡點，以更好的應用于一些大型的工程，例如帶了操作系統(tǒng)、lwip協(xié)議棧、emWin等。

2.3.2 中斷響應的問題

在前面的操作中，我們一直沒有留意中斷這個對嵌入式系統(tǒng)十分重要的部分。由前面的操作可知，我們將中斷向量表加載到了Flash中用于上電啟動，而后就一直沒有管它，只是專注于代碼的運行域。但是如果中斷向量表還在Flash中，那么當產生中斷的時候，硬件還是會到Flash中的中斷向量表位置去查找相應的中斷服務函數(shù)，這樣一去一回，無疑就拖慢了中斷的響應速度，要知道，在零等待的情況下，RT1050的中斷響應時間可是能達到20ns的。

可以將中斷向量表也拷貝到RAM中，然后重新對中斷向量表的地址進行映射。一種可行的方式是修改啟動文件。在啟動文件中再命名一個中斷向量表，該中斷向量表中添加原中斷向量表中除復位中斷函數(shù)之外的其他部分，而原中斷向量表中只保留復位中斷函數(shù)和棧指針。將新做的中斷向量表的運行域放在RAM的起始位置。這樣在程序上電的時候。__main會將該中斷向量表拷貝到RAM的起始地址，而后在main函數(shù)的開頭，對中斷向量表進行重映射。不過需要注意的是，這種操作有一個弊端，就是需要保證在復位到執(zhí)行中斷向量表重映射期間，不能產生除了復位中斷之外的其他中斷，否則會造成硬件異常。

3. 代碼運行速度已經起飛

經過上面的處理之后，怎么能不感受一下實際的起飛效果，可做一個LED燈翻轉的小例程用于測試，在例程中用軟件延時的方式翻轉小燈。先在Flash中運行，讓軟件延時達到200ms左右的延時效果。能正常顯示之后，不改變代碼內容，只是將代碼運行域放在RAM中，再次運行代碼，就能看到，此時小燈翻轉的頻率，已經達到了起飛的效果。