痞子衡嵌入式：在串口波特率識別實例裏逐步展現i.MXRT上提高代碼執行性能的十八般武藝

時間 2021-07-25

標籤 html 微信 ide 函數 oop 性能測試 fetch flex 優化欄目主板简体版

原文原文鏈接

　　你們好，我是痞子衡，是正經搞技術的痞子。今天痞子衡給你們介紹的是在串口波特率識別實例裏逐步展現i.MXRT上提高代碼執行性能的十八般武藝。html

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

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

1、SBL項目裏ISP串口高波特率識別問題

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

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

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）。

2、提高代碼性能的多種方法

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

Level 1：提高CPU主頻

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

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上提高代碼執行性能的十八般武藝痞子衡便介紹完畢了，掌聲在哪裏~~~