大家好，我是痞子衡，是正經搞技術的痞子。今天痞子衡給大家介紹的是在串列埠波特率識別例項裡逐步展示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 小節裡的改進）
void GPIO1_Combined_0_15_IRQHandler(void)
{
// ****輔助除錯：進入中斷時拉低 GPIO1[12]，標誌執行時間起點
GPIO1->DR &= (uint32_t)~(1U << 12);
uint32_t interrupt_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 即可。
const clock_arm_pll_config_t armPllConfig_BOARD_BootClockRUN = {
.loopDivider = 100, /* PLL loop divider, Fout = Fin * 50 */
.src = 0, /* Bypass clock source, 0 - OSC 24M, 1 - CLK1_P and CLK1_N */
};
void BOARD_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》 。
const flexspi_nor_config_t qspiflash_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模式》。
const flexspi_nor_config_t qspiflash_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讀訪問情形（全加速）》 。
int main(void)
{
// 將 MPU 配置提到 ISP 程式碼之前
BOARD_ConfigMPU();
#if (defined(COMPONENT_MCU_ISP))
bool isInfiniteIsp = false;
isp_boot_main(isInfiniteIsp);
#endif
// BOARD_ConfigMPU();
// ...
}
使能 Cache 後第一次 GPIO 中斷處理執行時間從 27.4us 下降到了 19us，後面的 GPIO 中斷執行耗時更是大大縮短（原因是中斷處理函式相關程式碼在第一次中斷觸發執行時被順便放到 Cache 裡了），這時候 115200 高波特率已經能夠被正常識別了。
到這裡問題已經解決了，但我們還沒有榨乾 MCU 最後一滴血，優化繼續。上圖波形裡第一次 GPIO 中斷處理執行時間相比其後面的 6 次中斷執行耗時要明顯長，這還是有風險的，比如再高的波特率 256000 還是無法正常識別（至少第一次識別會失敗，後面上位機再重複發暗號做第二次識別就可以了）。為了讓第一次 GPIO 中斷處理時間也大大縮短，我們可以在系統初始化的時候故意呼叫一下這些中斷處理相關函式，將這些程式碼事先裝載到 I-Cache裡。
void autobaud_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上提升程式碼執行效能的十八般武藝痞子衡便介紹完畢了，掌聲在哪裡~~~
歡迎訂閱
文章會同時釋出到我的 部落格園主頁、CSDN主頁、知乎主頁、微信公眾號 平臺上。
微信搜尋"痞子衡嵌入式"或者掃描下面二維碼，就可以在手機上第一時間看了哦。
