提升MCU代码执行性能的十八般武艺

撞上电子

大家好，我是痞子衡，是正经搞技术的痞子。今天痞子衡给大家介绍的是在串口波特率识别实例里逐步展示i.MXRT上提升代码执行性能的十八般武艺。
& |3 Z: l1 H) y5 B: g0 e2 t恩智浦 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 中断回调、波特率识别计算函数
7 p2 e; i# c% \8 T, apinmux_utility_imxrt_series.c      -- 存放 GPIO 配置与中断处理函数
& J; m4 s; Y5 {: E! EMIMXRT1060-EVK 板子上串口是 GPIO1[13:12]，其中 RXD - GPIO1[13] 是核心的用于波特率识别的引脚，为了便于直观地感受代码执行性能，我们用另一个 GPIO1[12] 来辅助，将其配置为 GPIO 输出模式，初值为高电平，在 GPIO 中断处理函数里保持低电平来标示执行总时间：
' w& M% k4 T8 V6 [. Y8 B' r) {3 Z

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);
; i+ y: k8 X' r$ t5 @    // 仅当 GPIO1[13] 下降沿中断发生时
0 h+ ~" o% Q" Y8 o9 k- t/ `: \    if ((GPIO_GetPinsInterruptFlags(GPIO1) & interrupt_flag) && s_pin_irq_func)
& e. H1 M: G  H% h# _    {
        // 执行一次回调函数
        s_pin_irq_func();
% e2 S: o8 o" l$ N1 G6 `        // 清除 GPIO1[13] 中断标志
        GPIO_ClearPinsInterruptFlags(GPIO1, interrupt_flag);
        __DSB();
5 N4 F! t* ]; o/ `2 f' s    }
    // ****辅助调试：退出中断时拉高 GPIO1[12]，标志执行时间结束
' d7 u& F1 T7 B3 q6 k4 g: P& j    GPIO1->DR |= (1U 12);
}
. ^5 W4 O/ ?  L' N! e9 [现在我们用示波器同时抓取 GPIO1[13:12] 信号，分别测试 9600 低波特率（下图一）和 115200 高波特率（下图二）下实际波形，根据测量第一次 GPIO 中断处理执行时间大概是 32.8us（7 次中断因代码分支执行不同略有区别），这个时间对于 9600 波特率下单 bit 传输耗时约 104us 的情况来说是足够快的，但是对于 115200 波特率下单 bit 传输耗时约 8.68us 的情况来说就显得有点慢了（最小的下降沿之间间隔是 2bit 传输耗时 17.36us ），这也是 115200 无法被识别的原因，因为有 4 个下降沿中断被漏掉了。

5wyr4imwhr56405722241.png