今天給大家介紹的是在串口波特率識別實例里逐步展示i.MXRT上提升代碼執行性能的十八般武藝。

恩智浦 MCU SE 團隊近期一直在加班加點趕 SBL 項目（解決客戶產品 OTA 需求），這個項目里集成了 ISP 本地升級（UART/USB）功能，其中 UART 口下載升級實現里加入了自動波特率識別支持，具體識別方法見 《串口(UART)自動波特率識別程序設計與實現(中斷)》 一文，這一套 ISP 代碼其實是移植于 i.MXRT Flashloader（更早期的時候叫 KBOOT）。

ISP 代碼放在 SBL 工程里會出現高波特率（比如115200）無法識別的問題，但在低波特率的情況下（比如9600，19200），ISP 代碼是功能正常的，說明代碼本身并不存在邏輯缺陷，但高波特率下就異常了，大概率是遇到了代碼執行性能瓶頸。今天痞子衡就嘗試在 i.MXRT 上使用各種方法去提升性能來解決這個高波特率無法識別問題：

一、SBL項目里ISP串口高波特率識別問題

SBL 項目是支持全系列 i.MXRT 平臺的，為了具體化問題，我們就選取 i.MXRT1062 型號為例，官方配套 MIMXRT1060-EVK 板子上搭配了一顆四線串行 NOR Flash（芯成IS25WP064A）用于存放代碼。

SBL 程序主體是 XIP 執行的，僅部分涉及 IAP 操作的代碼被分散加載到了 RAM 里。SBL 中 ISP 功能代碼主體當然也是 XIP 為主，且在 SBL 程序里是最先執行的（本地升級超時后才進入 SBL 主體），SBL 工程里跟串口波特率識別相關的源文件一共如下三個：

microseconds_pit.c                 -- 存放 PIT 計時函數
autobaud_irq.c                     -- 存放 GPIO 中斷回調、波特率識別計算函數
pinmux_utility_imxrt_series.c      -- 存放 GPIO 配置與中斷處理函數

MIMXRT1060-EVK 板子上串口是 GPIO1[13:12]，其中 RXD - GPIO1[13] 是核心的用于波特率識別的引腳，為了便于直觀地感受代碼執行性能，我們用另一個 GPIO1[12] 來輔助，將其配置為 GPIO 輸出模式，初值為高電平，在 GPIO 中斷處理函數里保持低電平來標示執行總時間：

• Note ：下述代碼里中斷處理函數實際上有點小缺陷，《中斷處理函數(IRQHandler)的標準流程》 一文里給出了改進方法，但這里為了觀察中斷處理代碼是否能在下一次中斷來臨前執行完畢特意舍棄了文中 2.2.2 小節里的改進）

voidGPIO1_Combined_0_15_IRQHandler(void)
{
//****輔助調試：進入中斷時拉低 GPIO1[12]，標志執行時間起點
GPIO1->DR&=(uint32_t)~(1U<12);

uint32_tinterrupt_flag=(1U<13);
//僅當GPIO1[13]下降沿中斷發生時
if((GPIO_GetPinsInterruptFlags(GPIO1)&interrupt_flag)&&s_pin_irq_func)
{
//執行一次回調函數
s_pin_irq_func();
//清除GPIO1[13]中斷標志
GPIO_ClearPinsInterruptFlags(GPIO1,interrupt_flag);
__DSB();
}

//****輔助調試：退出中斷時拉高 GPIO1[12]，標志執行時間結束
GPIO1->DR|=(1U<12);
}

現在我們用示波器同時抓取 GPIO1[13:12] 信號，分別測試 9600 低波特率（下圖一）和 115200 高波特率（下圖二）下實際波形，根據測量第一次 GPIO 中斷處理執行時間大概是 32.8us（7 次中斷因代碼分支執行不同略有區別），這個時間對于 9600 波特率下單 bit 傳輸耗時約 104us 的情況來說是足夠快的，但是對于 115200 波特率下單 bit 傳輸耗時約 8.68us 的情況來說就顯得有點慢了（最小的下降沿之間間隔是 2bit 傳輸耗時 17.36us ），這也是 115200 無法被識別的原因，因為有 4 個下降沿中斷被漏掉了。

• Note: ISP 功能代碼里配置的系統環境是：396MHz CPU 主頻、不使能 L1 Cache、100MHz Flash 工作頻率，普通 SPI 下 Fast Read Quad I/O SDR Non-Continuous 工作模式，并且使能了 FlexSPI 的 Prefetch 特性（AHB RX Buffer 為 1KB）。

二、提升代碼性能的多種方法

既然代碼執行性能不夠，那就努力提升性能，文章標題叫十八般武藝，這只是一種夸張說法，不過痞子衡確實收集了如下六種提升性能的方法，讓我們一一嘗試吧，注意下述結果都是疊加前面方法而得的（所有測試均是在 115200 波特率下進行）。

Level 1：提升CPU主頻

ISP 功能代碼里配置的 CPU 主頻是 396MHz，實際上這是根據 BootROM 默認運行配置而來的，而 i.MXRT1062 是可以跑到 600MHz 主頻的，將 SDK 代碼里 armPllConfig_BOARD_BootClockRUN.loopDivider 由 66 調大到 100 即可。

constclock_arm_pll_config_tarmPllConfig_BOARD_BootClockRUN={
.loopDivider=100,/*PLLloopdivider,Fout=Fin*50*/
.src=0,/*Bypassclocksource,0-OSC24M,1-CLK1_PandCLK1_N*/
};

voidBOARD_BootClockRUN(void)
{
//...

CLOCK_SetDiv(kCLOCK_AhbDiv,0);
CLOCK_SetDiv(kCLOCK_ArmDiv,1);
CLOCK_InitArmPll(&armPllConfig_BOARD_BootClockRUN);
CLOCK_SetMux(kCLOCK_PrePeriphMux,3);
CLOCK_SetMux(kCLOCK_PeriphMux,0);

//...
}

CPU 主頻提升后第一次 GPIO 中斷處理執行時間從 32.8us 下降到了 32.2us，性能僅有微小提升，看來此時主要性能瓶頸不在 CPU 主頻上，應該是 Flash 訪問性能在拖后腿。

Level 2：提升Flash訪問速度

SBL 工程里啟動頭 FDCB 配置的是 100MHz Flash 工作頻率，但 MIMXRT1060-EVK 板載 Flash（芯成IS25WP064A）最大工作頻率是 133MHz，所以我們可以提升 Flash 工作頻率。修改 qspiflash_config.memConfig.serialClkFreq 為 kFlexSpiSerialClk_133MHz 即可。不了解 FDCB 結構體工作機制的可以翻閱痞子衡舊文 《從頭開始認識i.MXRT啟動頭FDCB里的lookupTable》 。

constflexspi_nor_config_tqspiflash_config={
.memConfig=
{
.tag=FLEXSPI_CFG_BLK_TAG,
.version=FLEXSPI_CFG_BLK_VERSION,
.readSampleClkSrc=kFlexSPIReadSampleClk_LoopbackFromDqsPad,
.csHoldTime=3u,
.csSetupTime=3u,
.sflashPadType=kSerialFlash_4Pads,
//.serialClkFreq=kFlexSpiSerialClk_100MHz,

.serialClkFreq=kFlexSpiSerialClk_133MHz,
.sflashA1Size=8u*1024u*1024u,
.lookupTable=
{
FLEXSPI_LUT_SEQ(CMD_SDR,FLEXSPI_1PAD,0xEB,RADDR_SDR,FLEXSPI_4PAD,0x18),
FLEXSPI_LUT_SEQ(DUMMY_SDR,FLEXSPI_4PAD,0x06,READ_SDR,FLEXSPI_4PAD,0x04),
},
},
.pageSize=256u,
.sectorSize=4u*1024u,
.blockSize=64u*1024u,
.isUniformBlockSize=false,
};

Flash 工作頻率提升后第一次 GPIO 中斷處理執行時間從 32.2us 下降到了 27.8us，這次的性能提升算有點明顯了，但是還是不夠，解決不了問題。

Level 3：配置FlexSPI至最優模式

讓我們繼續從 Flash 傳輸模式上做文章，ISP 功能代碼里配置的是普通 SPI 下 Fast Read Quad I/O SDR Non-Continuous 工作模式，這個模式已經算是非常高效的傳輸模式了，如果還想改進，要么是切換到 QPI 模式（將 CMD 子序列也從一線變到四線）要么是使能 Continuous Read（除了第一個 CMD 子序列，其后 CMD 子序列全部省掉），綜合考慮應該是使能 Continuous Read 性能提升更大一些，具體方法參考 《在i.MXRT啟動頭FDCB里使能串行NOR Flash的Continuous read模式》。

constflexspi_nor_config_tqspiflash_config={
.memConfig=
{
//...
.lookupTable=
{
FLEXSPI_LUT_SEQ(CMD_SDR,FLEXSPI_1PAD,0xEB,RADDR_SDR,FLEXSPI_4PAD,0x18),
//FLEXSPI_LUT_SEQ(DUMMY_SDR,FLEXSPI_4PAD,0x06,READ_SDR,FLEXSPI_4PAD,0x04),

//插入JUMP_ON_CS子序列
FLEXSPI_LUT_SEQ(MODE8_SDR,FLEXSPI_4PAD,0xA0,DUMMY_SDR,FLEXSPI_4PAD,0x04),
FLEXSPI_LUT_SEQ(READ_SDR,FLEXSPI_4PAD,0x04,JMP_ON_CS,FLEXSPI_1PAD,0x01),
},
},
//...
};

使能 Flash Continuous Read 后第一次 GPIO 中斷處理執行時間從 27.8us 下降到了 27.4us，性能僅有微小提升，這應該跟我們使能了 FlexSPI prefetch 特性有關，1KB AHB RX Buffer 的存在導致 CMD 子序列在總傳輸時序中占比不明顯。不過有點收獲的是漏掉的下降沿中斷從 4 個減少到了 3 個。

Level 4：打開L1 Cache

對于 XIP 工程來說，不開 L1 I-Cache 加速性能是非常吃虧的一件事，i.MXRT1062 內部有 32KB I-Cache，不把這個 Cache 用起來簡直是暴殄天物。雖然工程 SystemInit() 函數里會執行一次 SCB_EnableICache()，但這只是一個 Cache 總開關，要想 Cache 對 Flash 映射地址（0x60000000 之后）產生作用還得借助 BOARD_ConfigMPU() 函數來具體配置 MPU。關于 Cache 對 Flash 讀取的性能提升見 《實抓Flash信號波形來看i.MXRT的FlexSPI外設下AHB讀訪問情形（全加速）》 。

intmain(void)
{
//將MPU配置提到ISP代碼之前
BOARD_ConfigMPU();

#if(defined(COMPONENT_MCU_ISP))
boolisInfiniteIsp=false;
isp_boot_main(isInfiniteIsp);
#endif

//BOARD_ConfigMPU();
//...
}

使能 Cache 后第一次 GPIO 中斷處理執行時間從 27.4us 下降到了 19us，后面的 GPIO 中斷執行耗時更是大大縮短（原因是中斷處理函數相關代碼在第一次中斷觸發執行時被順便放到 Cache 里了），這時候 115200 高波特率已經能夠被正常識別了。

到這里問題已經解決了，但我們還沒有榨干 MCU 最后一滴血，優化繼續。上圖波形里第一次 GPIO 中斷處理執行時間相比其后面的 6 次中斷執行耗時要明顯長，這還是有風險的，比如再高的波特率 256000 還是無法正常識別（至少第一次識別會失敗，后面上位機再重復發暗號做第二次識別就可以了）。為了讓第一次 GPIO 中斷處理時間也大大縮短，我們可以在系統初始化的時候故意調用一下這些中斷處理相關函數，將這些代碼事先裝載到 I-Cache里。

voidautobaud_init(void)
{
s_transitionCount=0;
s_firstByteTotalTicks=0;
s_secondByteTotalTicks=0;
s_lastToggleTicks=0;
s_ticksBetweenFailure=microseconds_convert_to_ticks(kMaximumTimeBetweenFallingEdges);
enable_autobaud_pin_irq(pin_transition_callback);

//故意調用一下，讓I-Cache事先將代碼Cache住
GPIO1_Combined_0_15_IRQHandler();
pin_transition_callback();//即第一節代碼中的s_pin_irq_func()
}

將中斷處理函數相關代碼預裝載到 I-Cache 后第一次 GPIO 中斷處理執行時間從 19us 銳降到了 2.12us，跟其他中斷處理執行差不多的耗時，現在即使是 256000 高波特率也能一次識別成功。

Level 5：拷貝到TCM里

靠 Cache 這種無法精準控制的優化策略始終讓我們無法放心，還是將中斷處理相關代碼直接放到 TCM 里更可靠，我們在工程鏈接文件（MIMXRT1062xxxxx_flexspi_nor.icf）里做如下修改將第一節里列出了三個源文件全部弄到 RAM 區里執行（對于 XIP 工程來說，RAM 區是 DTCM， 當然對于代碼來說 ITCM 效率要更高，不過 DTCM 也夠用了）。

initialize by copy {
  readwrite,
  /* Place in RAM flash and performance dependent functions */

  object microseconds_pit.o,
  object autobaud_irq.o,
  object pinmux_utility_imxrt_series.o,

  // ...
  section .textrw
};

do not initialize  { section .noinit };

將中斷處理函數相關代碼重定位到 DTCM 執行后第一次 GPIO 中斷處理執行時間從 2.12us 再降到了 520ns，這下 1M 超高波特率也能被識別了。

Level 6：指定函數地址以八字節對齊

性能提升結束了嗎？痞子衡還有一招，參見 《鏈接函數到8字節對齊地址或可進一步提升i.MXRT1xxx內核執行性能》 一文，將中斷處理相關函數全部鏈接到八字節對齊地址還可以再利用 Cortex-M7 內核指令雙發射特性。我們查看下工程映射文件(sbl.map)，三個相關函數僅有計時函數 microseconds_get_ticks() 被自動分配到了八字節對齊的地址，其他兩個函數不是，所以還有提升空間。

Entry                       Address   Size  Type      Object
;----                       -------   ----  ----      ------

GPIO1_Combined_0_15_IRQHandler
                        0x2000'0b2f   0x3e  Code  Gb  pinmux_utility_imxrt_series.o [1]
pin_transition_callback 0x2000'0175   0x8e  Code  Gb  autobaud_irq.o [1]
microseconds_get_ticks  0x2000'08e9   0x22  Code  Gb  microseconds_pit.o [1]

將非八字節地址對齊的中斷處理相關函數調整到八字節地址對齊后（具體方法這里就不展開介紹了），第一次 GPIO 中斷處理執行時間從 520ns 降到了 480ns，這幾乎是性能極限了。

至此，在串口波特率識別實例里逐步展示i.MXRT上提升代碼執行性能的十八般武藝痞子衡便介紹完畢了，掌聲在哪里~~~

審核編輯 ：李倩