1. 从“跑分”到“选型”为什么要在MCU上做CoreMark测试如果你和我一样长期在嵌入式领域摸爬滚打肯定遇到过这样的场景面对一堆参数表上看起来差不多的微控制器MCU比如都是Cortex-M0内核主频都是48MHz内存都是16KB到底该选哪个数据手册上的DMIPS/MHz数字各家都说自己“高达”多少但总觉得有点“王婆卖瓜”的嫌疑。这时候一个客观、可复现的基准测试工具就成了我们做技术选型和性能摸底的关键武器。CoreMark就是这样一个在嵌入式圈子里公认的“标尺”。CoreMark不是一个复杂的应用它是一套用C语言写成的小型基准测试程序专门用来衡量微控制器核心CPU的处理能力。它避开了I/O、外设等不确定因素专注于测试核心的整数运算、控制逻辑、内存访问等基本能力。最终得出的分数就是CoreMark值。这个值越高通常意味着核心的“纯计算”性能越强。在项目初期尤其是在资源受限的XMC1100这类入门级MCU上进行CoreMark测试意义重大第一它能验证芯片的实际性能是否与数据手册宣称相符避免“纸上谈兵”第二在后续的算法选型或代码优化时CoreMark分数可以作为一个基线参考帮你量化优化效果第三当需要在不同编译工具链比如ARMCC、GCC、IAR之间做选择时CoreMark能直观地告诉你哪套工具链生成的代码效率更高。这次我们就拿英飞凌的XMC1100系列MCU开刀它是基于ARM Cortex-M0内核的典型代表主打高性价比和低功耗。而测试所用的编译器则是经典的ARM Compiler 5也就是常说的ARMCC。选择ARMCC一方面是因为它在ARM生态中历史悠久优化稳定很多老项目都在用另一方面也是想看看在这样一个“经典组合”下我们能把这颗小芯片的性能“压榨”到什么程度过程中又会遇到哪些编译、链接上的“坑”。整个实验我会从环境搭建、代码移植、编译配置、优化技巧一直讲到结果分析和那些数据手册不会告诉你的细节。无论你是刚接触XMC1100的新手还是想深入了解CoreMark测试门道的老鸟这篇实操记录都能给你带来直接的参考。2. 实验环境搭建与工程初始化工欲善其事必先利其器。在XMC1100上跑CoreMark我们需要的不仅仅是一块开发板。2.1 硬件与软件准备清单首先清点一下我们的“装备”硬件平台一块XMC1100 Boot Kit或XMC1100 XMC2Go开发板。我手头用的是XMC1100 Boot Kit它板载了J-Link OB调试器非常方便。核心芯片是XMC1100-Q024F006464KB Flash16KB RAM主频最高32MHz外部晶振或通过PLL倍频。软件工具链Keil MDK-ARM这是集成ARMCC编译器、调试器的IDE。我们需要其内部的ARM Compiler 5通常版本号如ARMCC 5.06 update 6 (build 750)。确保安装时勾选了对应的Device Family Pack for Infineon XMC1000。CoreMark源码从EEMBC官网获取最新版本如1.0。核心文件就几个core_list_join.c,core_main.c,core_matrix.c,core_state.c,core_util.c, 以及最重要的core_portme.c端口层实现和core_portme.h。XMC外设库XMCLib从英飞凌官网下载对应XMC1000系列的外设库。我们主要用它来配置系统时钟、初始化基本外设如UART用于打印结果。这里有个关键点CoreMark测试要求提供一个精确的计时器用于测量算法运行时间。XMC1100的Cortex-M0内核没有DWTData Watchpoint and Trace周期计数器这个高级功能因此我们不能像在M3/M4内核上那样方便地使用CYCCNT。我们必须依赖一个硬件定时器比如SysTick或者通用的GPT通用定时器。我选择使用SysTick因为它最简单且是ARM内核标准组件。2.2 在Keil中创建XMC1100基础工程打开Keil MDK创建一个新工程选择设备Infineon::XMC1100-Q024x0064。在管理运行时环境Manage Run-Time Environment对话框中通常我们只需要Device::Startup和Compiler::Compiler I/O用于printf重定向。对于CoreMark这种裸机测试不需要操作系统。工程创建好后首先需要解决系统时钟问题。XMC1100默认使用内部8MHz RC振荡器OSC。但为了获得更精确的计时和更高的性能我们通常启用外部晶振并通过PLL倍频。例如假设板载外部晶振是8MHz我们可以配置PLL将其倍频到32MHz这是XMC1100的典型最高频率。这部分代码需要写在system_XMC1100.c文件的SystemCoreClockUpdate()函数中或者在main函数开始处调用XMCLib的时钟配置API。一个常见的初始化顺序是初始化调试用的串口UART方便我们打印信息。配置系统时钟到目标频率如32MHz。初始化SysTick定时器将其配置为每1ms产生一次中断或一个固定的计时单位并在中断服务程序ISR中更新一个全局计时变量如system_ms_ticks。这个全局计时变量将作为core_portme.c中计时函数barebones_clock()的时基。注意CoreMark的默认端口实现core_portme.c里barebones_clock()函数预期返回的是“时钟滴答数”。你需要根据SysTick的配置来定义这个函数。例如如果SysTick每1ms中断一次barebones_clock()可以直接返回system_ms_ticks。但CoreMark计算分数时需要的是“秒”为单位的时间。因此你必须在core_portme.h中正确defineCLOCKS_PER_SEC这个宏例如#define CLOCKS_PER_SEC 1000如果时基是毫秒。2.3 移植CoreMark源码并解决依赖将下载的CoreMark源码文件复制到你的工程目录下并添加到Keil工程中。关键的一步是移植和实现端口层文件。core_portme.c和core_portme.h是CoreMark与具体硬件平台的桥梁。你需要修改以下几个关键部分计时器实现如前所述实现barebones_clock()函数让其返回基于SysTick的计时值。// 假设 system_ms_ticks 是一个由SysTick ISR递增的volatile变量 extern volatile unsigned long long system_ms_ticks; CORE_TICKS barebones_clock() { return (CORE_TICKS)system_ms_ticks; }迭代次数控制CoreMark通过ITERATIONS宏来控制运行次数以确保总运行时间足够长默认要求大于10秒。在core_portme.h中你可以先不定义ITERATIONS让CoreMark自己根据运行时间动态调整。也可以预设一个较大的值比如#define ITERATIONS 1000。打印输出重定向CoreMark内部使用ee_printf来输出结果。你需要实现这个函数。最简单的方法就是将其映射到标准库的printf而printf又通过Keil的Compiler I/O重定向到你初始化好的UART上。在core_portme.c里可以这样写void ee_printf(const char *format, ...) { va_list args; va_start(args, format); vprintf(format, args); // 依赖已重定向的printf va_end(args); }确保在Keil的Target Options - Target中勾选了Use MicroLIB这是一个为嵌入式系统优化的精简C库对printf重定向更友好。内存设置core_portme.h中的MEM_METHOD和MEM_LOCATION通常保持默认即可。对于XMC1100所有数据都放在内部RAM中。完成这些修改后编译工程你很可能会遇到第一个“坑”链接错误——没有足够的栈空间。CoreMark的某些函数尤其是递归或局部变量多的对栈消耗较大。而Keil为XMC1100默认分配的栈大小可能只有0x4001KB这可能导致运行时栈溢出程序跑飞。3. ARMCC编译配置与优化等级深度解析环境搭好了代码也移植了下一步就是让ARMCC编译器为我们生成高效的机器码。编译器的配置选项直接决定了CoreMark分数的上限。3.1 关键编译选项与链接脚本调整在Keil中右键点击工程名选择Options for Target进入配置界面。Target标签页晶振频率这里填写的频率如32.0MHz主要影响调试器的时间计算对代码运行无影响。实际时钟以我们代码中配置的为准。操作系统选择None裸机。ROM/RAM地址与大小确认是否与XMC1100-Q024F0064匹配ROM: 0x10000000, 大小0x10000即64KB; RAM: 0x20000000, 大小0x4000即16KB。这里是重点我们需要调整栈和堆的大小。在IRAM1的Startup文件中或直接在Target页的Read/Write Memory Areas将默认的栈Stack Size改大我建议至少设置为0x8002KB堆Heap Size可以保持较小如0x200512B因为CoreMark基本不动态分配内存。这个修改是为了解决上一节末尾提到的栈溢出问题。C/C标签页优化等级Optimization这是影响性能最关键的部分。ARMCC提供了从-O0到-O3以及-Os优化尺寸等多个等级。为了测试最大性能我们当然选择-O3。但-O3是激进的性能优化可能会增加代码体积。我们需要在Optimization下拉框中选择Level 3 (-O3)。优化侧重Optimization Focus在Optimization框右侧可以选择Favor speed侧重速度或Favor size侧重尺寸。做CoreMark跑分毫无疑问选Favor speed。One ELF Section per Function勾选此选项。它会让编译器将每个函数都放到独立的ELF段中这样链接器在链接时可以进行更彻底的无用函数消除--gc-sections有助于减小最终代码体积对性能影响不大但有益于代码管理。Strict ANSI C取消勾选。CoreMark源码中可能使用了inline等C99特性严格ANSI C模式可能会报错。Linker标签页勾选Use Memory Layout from Target Dialog这样链接器就使用我们在Target页配置的ROM/RAM地址。分散加载文件Scatter File对于简单应用可以不使用自定义的scatter文件。但如果后续代码复杂需要精细控制代码和数据在Flash和RAM中的布局就需要编辑它。本次测试可以暂不修改。3.2 不同优化等级的性能与代码体积对比光说-O3好不够直观我们来做一组对比实验。在相同的硬件和代码基础上仅改变C/C标签页中的Optimization等级分别编译并在XMC1100上运行CoreMark记录结果。优化等级CoreMark分数代码大小 (Flash)备注-O0 (无优化)~15.0约 12KB基线便于调试性能最低。-O1~35.0约 9KB基础优化性能显著提升代码体积反而减小。-O2~42.0约 8.5KB更进一步的优化包括指令调度和循环优化。-O3~48.5约 9KB激进优化包含自动向量化等性能最高。-Os (优化尺寸)~38.0约 7.8KB在保证一定性能下追求最小代码体积。注以上分数为模拟数据实际分数取决于具体时钟频率和实现细节但趋势是准确的。从对比中我们可以解读出什么优化效果显著从-O0到-O3性能提升了超过3倍。这直观地展示了编译器优化的重要性。-O1的魔力-O1在提升性能的同时代码体积竟然比-O0还小。这是因为-O0为了调试保留了所有符号和冗余操作而-O1进行了诸如死代码消除、常量传播等基础优化去掉了冗余。-O3的代价-O3虽然性能最高但代码体积比-O2略有增加。这是因为-O3可能会进行循环展开、函数内联等操作用空间换时间。对于Flash只有64KB的XMC1100需要权衡。但在CoreMark这个特定测试中空间完全足够所以果断用-O3。-Os的适用场景如果你的项目对Flash空间极其敏感且性能要求不是极致-Os是一个很好的折中选择。它只比-O1慢一点但体积更小。3.3 针对CoreMark的微调与常见编译错误除了优化等级还有一些细节需要注意Enum Container在C/C标签页的Misc Controls中可以添加--enum_is_int。这强制枚举类型使用int而不是可能更小的类型避免在某些对齐严格的架构上产生低效的访问。对于Cortex-M0加上通常无害。C99 Mode在Misc Controls中添加--c99确保编译器支持C99标准避免因inline关键字等报错。链接错误L6915E如果你在Linker标签页勾选了Use MicroLIB但代码中又使用了标准的C库函数可能会遇到这个关于__use_two_region_memory的错误。解决方法是在Linker的Misc controls框中添加--library_typemicrolib或者不勾选Use MicroLIB转而使用标准库并正确实现_sys_xxx系列系统调用。配置完成后点击编译。如果一切顺利你会得到一个.axf或.hex文件。接下来就是下载到板子上运行了。4. 测试执行、结果分析与性能陷阱将编译好的程序通过J-Link下载到XMC1100开发板打开串口助手如Putty、Tera Term设置正确的波特率与你代码中UART配置一致复位或上电运行。4.1 解读CoreMark输出结果程序运行后串口会打印出类似下面的信息2K performance run parameters for coremark. CoreMark Size : 666 Total ticks : 30000 Total time (secs): 30.000000 Iterations/Sec : 333.333333 Iterations : 10000 Compiler version : ARMCC 5.06 update 6 (build 750) Compiler flags : -O3 -DCLOCKS_PER_SEC1000 Memory location : STACK seedcrc : 0xe9f5 [0]crclist : 0xe714 [0]crcmatrix : 0x1fd7 [0]crcstate : 0x8e3a [0]crcfinal : 0x3e5f Correct operation validated. See README.md for run and reporting rules. CoreMark 1.0 : 333.333333 / ARMCC 5.06 update 6 (build 750) -O3 -DCLOCKS_PER_SEC1000 / STACK我们来逐行解读Total time (secs) CoreMark测试实际运行的总时间。这个时间是基于我们实现的barebones_clock()和CLOCKS_PER_SEC计算出来的。Iterations 实际运行的迭代次数。CoreMark会动态调整迭代次数使得总时间大于10秒默认值。Iterations/Sec 每秒完成的迭代次数。这是计算CoreMark分数的直接依据。CoreMark 1.0 : 333.333333 / ...这一行就是最终结果。333.333333就是测得的CoreMark分数。后面的信息是编译器版本、编译选项和内存位置。CRC校验值seedcrc,crclist,crcmatrix,crcstate,crcfinal。这是CoreMark用于验证测试是否正确运行的机制。你必须核对crcfinal的值是否为0x3e5f。如果不是说明测试过程出现了错误比如内存被意外修改、编译器优化破坏了算法逻辑、计时不准导致迭代次数计算错误等本次跑分结果无效。4.2 影响分数准确性的关键因素与校准拿到一个分数我们首先要问这个分数准确吗以下几个因素会直接影响结果的可靠性系统时钟精度这是最核心的因素。如果你的SysTick是基于内部RC振荡器精度可能±2%那么计时本身就有误差跑分自然不准。务必使用外部晶振作为时钟源。同时检查PLL配置是否正确系统时钟是否确实运行在了你预设的频率如32MHz。可以通过测量一个GPIO翻转的周期来间接验证。编译器优化导致的“作弊”激进的编译器优化特别是-O3配合-Otime可能会“聪明”地发现CoreMark中的某些计算结果是编译期可知的或者循环是多余的从而将其优化掉。这会导致测试时间变短分数虚高。CoreMark设计时通过volatile变量和core_portme.c中的iterate函数等手段来防止这一点但并非绝对安全。验证CRC值是否正确是检测这种“优化作弊”的最后防线。如果CRC错了分数再高也无效。中断干扰SysTick中断、或者其他使能的中断会在CoreMark运行期间打断它增加其运行时间导致分数降低。确保CoreMark运行在核心循环时只有SysTick中断是活动的并且SysTick中断服务程序尽可能短只做递增计数。内存速度Cortex-M0使用冯·诺依曼架构指令和数据共享同一个总线。当CoreMark的代码和数据都位于Flash中时Flash的访问速度会成为瓶颈。XMC1100的Flash通常需要等待状态。虽然我们无法改变硬件但确保芯片工作在额定最高频率并且Flash加速器如果存在被启用可以最大化性能。如何进行简单的校准你可以写一个简单的“空循环”计时程序让一个循环运行固定的次数比如100万次用同样的计时方法测量时间。然后在不同优化等级下编译运行这个空循环。你会发现-O3优化下空循环甚至可能被完全优化掉耗时接近0。这印证了编译器优化的威力。对比CoreMark测试如果CoreMark在-O3下的耗时减少比例远大于空循环那很可能就是算法本身被优化了。这时就要高度警惕CRC校验。4.3 对比数据与性能瓶颈分析假设我们在32MHz系统时钟下使用ARMCC-O3优化得到了一个48.5的CoreMark分数。如何理解这个数字与理论值对比Cortex-M0的典型性能是0.9 DMIPS/MHz。DMIPS和CoreMark是不同的基准但可以粗略估算。32MHz * 0.9 DMIPS/MHz 28.8 DMIPS。而CoreMark分数大约是这个值的1.5-2倍因为测试集不同48.5在这个范围内说明结果基本合理。与GCC对比你可以尝试用ARM-GCC如通过STM32CubeIDE或直接使用Makefile编译同样的代码。在相同优化等级如-O3下GCC生成的代码性能可能与ARMCC有5%-15%的差异。通常ARMCC在ARM架构上略有优势但GCC是免费的且跨平台。这个对比可以帮助你为项目选择工具链。瓶颈在哪里对于XMC1100这类低端MCUCoreMark的瓶颈主要在于内存带宽频繁的矩阵操作和链表遍历对数据缓存但M0没有缓存和内存总线压力很大。分支预测M0内核没有分支预测循环和条件跳转开销相对较大。CoreMark中的很多控制密集型代码会受此影响。编译器优化天花板即使使用-O3编译器的优化能力也是有限的。手动进行关键循环的内联展开、使用寄存器变量等可能还能榨取一点点性能但对于整体分数提升有限。5. 超越跑分将CoreMark经验应用于实际项目做完测试拿到分数报告一写任务就结束了对于工程师来说这恰恰是开始。CoreMark测试过程中积累的经验能直接反哺到实际项目开发中。5.1 编译选项的实战选择策略我们不会在所有项目中都无脑使用-O3。在实际项目中需要权衡性能、代码体积和调试便利性。开发调试阶段建议使用-O0或-O1。-O0保证了代码顺序与源码完全一致变量不会被优化掉单步调试、查看变量值都非常直观。虽然性能差但便于快速定位逻辑错误。性能测试与发布阶段在功能稳定后切换到-O2或-O3进行性能测试和压力测试。关注关键任务的执行时间是否满足要求。同时必须进行全面的功能回归测试因为激进的优化可能会暴露一些在低优化等级下隐藏的时序问题或未定义行为比如对volatile变量访问顺序的假设。空间极度受限项目优先使用-Os。如果-Os下性能不达标可以尝试-O2配合链接器的--gc-sections并手动剔除不必要的外设驱动和库函数。5.2 基于性能基准的优化实践CoreMark教会我们如何建立性能基准。在你的实际项目中也应该为关键算法或函数模块建立类似的“微基准测试”。隔离测试环境像CoreMark一样创建一个简单的裸机工程只包含系统时钟、定时器和串口驱动然后放入你要测试的算法代码。精确计时复用为CoreMark编写的SysTick计时模块在算法开始前和结束后读取计时器差值。控制变量固定输入数据多次运行取平均消除偶然误差。对比优化效果修改算法实现比如用查表法代替实时计算、调整编译器选项、尝试将关键函数放到RAM中执行如果支持且RAM足够然后用基准测试量化性能提升。例如你有一个传感器滤波算法原来在-Os下需要500us。你尝试了-O3时间降到450us。你又手动将循环展开时间降到420us。每一步都有数据支撑决策就非常清晰。5.3 排查性能问题的通用思路当项目中发现某个功能慢可以借鉴CoreMark测试的排查思路确认时钟首先检查系统时钟配置是否正确是否运行在预期频率。这是所有性能问题的根源。检查优化等级你的Release构建配置真的打开了优化吗有时候IDE的Debug和Release配置搞混了。使用定时器定位像CoreMark一样在可疑代码段前后打点计时精确锁定耗时最长的函数或循环。分析编译器输出ARMCC可以生成汇编列表文件.lst或.asm。查看关键函数的汇编代码看看编译器是否生成了你意想不到的低效指令比如过多的内存访问而非寄存器操作。在Keil中可以在Options for Target - Output中勾选Assembly Listing并指定一个列表文件。考虑内存布局对于频繁执行的函数如中断服务程序、关键循环可以考虑使用__attribute__((section(.fast_code)))将其放到RAM中执行如果芯片支持或者确保其位于Flash的零等待区域以减少指令取指时间。最后回到XMC1100的CoreMark测试本身这个分数本身只是一个数字。更重要的是通过这个过程你深入了解了你的工具链ARMCC掌握了为裸机系统配置时钟和定时器的方法学会了如何移植和适配一个开源测试框架并理解了编译器优化对性能的巨大影响。这些技能在你面对下一个芯片、下一个项目时会远比一个单纯的跑分数字更有价值。下次当你再评估一颗MCU时你会自然地想去跑一下CoreMark并且清楚地知道这个分数背后的每一个字节和时钟周期是怎么来的。