1. 项目概述为什么我们需要CoreMark在嵌入式开发领域尤其是基于ARM Cortex-M这类资源受限的微控制器MCU进行选型或性能优化时一个最直接也最令人头疼的问题就是这颗芯片到底有多“快”厂家手册上的主频MHz只是一个理论峰值实际运行效率受内存架构、编译器优化、流水线效率等多重因素影响。早年很多工程师会依赖Dhrystone MIPSDMIPS这个指标但它在今天看来已经有些“力不从心”——它过于依赖编译器的优化能力导致同一颗CPU用不同编译器跑出来的分数可能天差地别失去了横向比较的意义。这时CoreMark的价值就凸显出来了。它是由嵌入式微处理器基准评测协会EEMBC在2009年推出的一个免费、开源、轻量级的基准测试程序。它的核心目标非常明确剥离编译器优化的干扰尽可能真实地反映处理器核心Core本身的整数运算、控制逻辑和内存访问性能。其最终结果是一个简单的数字CoreMark/MHz即每兆赫兹主频能跑出的CoreMark分数。这个数字越高意味着处理器核心的每时钟周期性能越强架构效率越高。我最近在为一个低功耗物联网终端项目进行MCU选型需要在几款主频相近的Cortex-M3和M4内核芯片中做出抉择。数据手册上的参数大同小异最终让我下定决心的正是通过亲自移植和运行CoreMark测试得到的直观性能数据。这个过程不仅帮我选定了芯片也让我对CoreMark的移植细节、结果解读和常见陷阱有了更深的理解。下面我就把这次基于STM32平台的CoreMark移植、测试与深度分析的完整过程记录下来希望能为面临同样问题的朋友提供一份详实的参考。2. CoreMark测试原理与核心价值解析在动手移植之前我们有必要先搞清楚CoreMark到底在测什么以及为什么它的结果被认为比DMIPS更可靠。理解其设计哲学能帮助我们在后续的移植和结果分析中避免很多误区。2.1 CoreMark的测试矩阵四项核心工作负载CoreMark程序并非一个单一的算法它包含了四种不同的工作负载混合执行以模拟真实的嵌入式程序行为链表遍历与处理List Processing 这部分主要考察指针追逐Pointer Chasing能力。它操作一个链表进行序列查找、排序插入排序和元素翻转。这非常考验处理器的分支预测能力和内存访问延迟。因为链表的节点在内存中是非连续存放的CPU无法有效预取缓存命中率会较低能真实反映内存子系统性能。矩阵操作Matrix Manipulate 这部分包含了一个小矩阵的常见操作如矩阵赋值、乘法使用原地算法。它考察的是整数算术运算单元ALU的效率和编译器对循环结构的基本优化能力。矩阵运算涉及大量的乘加操作和嵌套循环是计算密集型任务的代表。状态机State Machine 实现了一个小的确定性有限自动机DFA用于模拟输入流的处理。它包含大量的switch-case或if-else分支跳转主要测试处理器的控制逻辑和分支跳转效率。在嵌入式系统中状态机是极其常见的编程模式。循环冗余校验CRC 执行一个16位的CRC计算。这涉及到大量的位操作移位、异或和查表操作用于测试处理器的位操作指令效率和对常量数据查表的访问速度。这四种工作负载会被循环执行多次迭代。CoreMark的最终分数就是在单位时间内默认为至少10秒这四种工作负载完整完成的次数。这种混合负载的设计使得CoreMark能够相对均衡地反映CPU在多种常见任务下的综合性能而不是偏重某一方面。2.2 为何CoreMark比Dhrystone更受青睐输入材料中提到了Dhrystone的不足这里我结合自己的经验展开说一下编译器“把戏”的受害者 Dhrystone的代码模式相对简单固定现代编译器尤其是高优化等级如-O2, -O3能够对其进行极其激进的优化例如将大量循环和函数调用完全展开Loop Unrolling、内联Inlining甚至直接预计算出结果。这导致测试得分更多反映的是编译器的优化攻击性而非CPU的真实吞吐量。我曾用同一块STM32F4开发板分别使用ARMCCKeil和GCCAC6编译器Dhrystone分数相差超过30%而CoreMark的差异则在5%以内。CoreMark的“防作弊”机制 CoreMark在规则上做了严格限制旨在防止编译器进行“非常规”优化。例如禁止删除“死代码” CoreMark的某些计算其结果仅用于验证正确性并不输出。编译器不能因为觉得这些结果没用就直接把整个计算过程优化掉。数据依赖与易变性 算法中刻意引入了数据依赖和通过指针访问的易变volatile数据使得编译器难以在不改变程序逻辑的前提下进行过度优化。运行时验证 程序会检查每次迭代的输出是否与预期“种子Seed”值匹配确保整个计算过程被完整执行。因此CoreMark得分更能体现在合理的编译器优化下CPU硬件架构本身的执行效率。它成为了嵌入式社区进行CPU核心性能横向对比的“普通话”或“通用货币”。2.3 CoreMark分数的解读CoreMark vs. CoreMark/MHz这是两个关键但不同的指标总CoreMark分数 你的芯片在特定主频下运行完整个测试得到的绝对分值。例如“STM32F429 180MHz 得分为 480 CoreMark”。CoreMark/MHz 将总分除以运行频率单位MHz得到的归一化值。例如“480 CoreMark / 180 MHz ≈ 2.67 CoreMark/MHz”。在对比不同芯片时CoreMark/MHz才是更有价值的指标。因为它剥离了主频的影响直接反映了每时钟周期的性能。一个2.67 CoreMark/MHz的芯片其核心架构效率通常优于一个2.0 CoreMark/MHz的芯片即使后者主频更高。当然最终选型还要结合绝对性能总CoreMark、功耗、外设、价格等因素。3. 实战将CoreMark移植到STM32平台理论说再多不如亲手跑一遍。下面我以最常见的STM32F103C8T6Cortex-M3和STM32F429IGT6Cortex-M4为例详细拆解移植步骤。我使用的是Keil MDK-ARM开发环境但原理通用适用于IAR、GCC等。3.1 工程准备与源码获取首先你需要一个能正常编译、下载和运行的STM32基础工程例如一个简单的LED闪烁工程确保串口打印功能正常CoreMark结果通过串口输出。步骤1获取CoreMark源码访问EEMBC的官方GitHub仓库https://github.com/eembc/coremark下载或克隆最新源码。核心文件在根目录下我们重点关注以下文件core_list_join.c core_main.c core_matrix.c core_state.c core_util.c coremark.h此外我们需要一个与平台相关的移植层Porting Layer。源码在simple/目录下提供了最简单的参考实现simple/core_portme.c // 平台初始化、计时器实现 simple/core_portme.h // 配置参数定义步骤2整合文件到工程在你的STM32工程目录下例如./User/CoreMark/新建一个文件夹将上述8个文件拷贝进去。 在Keil工程中在项目管理器中新建一个名为“CoreMark”的分组。将core_*.c和coremark.h添加到该分组。将simple/core_portme.c和simple/core_portme.h也添加进来。注意因为core_main.c里已经包含了main()函数你需要移除或重命名你原有工程中的main.c文件例如改为main_bak.c否则会有重复定义的链接错误。注意这是一个关键步骤也是第一个容易踩坑的地方。很多朋友直接添加文件而忘了处理原有的main函数导致编译失败。稳妥的做法是在一个全新的工程里做CoreMark移植或者备份好原来的main.c。3.2 移植层深度适配让CoreMark在MCU上跑起来移植的核心工作就是修改core_portme.c和core_portme.h让CoreMark认识你的硬件平台主要是初始化和精确计时。3.2.1 平台初始化 (portable_init)这个函数在CoreMark的main()最开始被调用是我们进行硬件初始化的地方。输入材料中给出了一个示例但我们可以做得更完善。// 在 core_portme.c 文件顶部添加你的硬件驱动头文件 #include stm32f1xx_hal.h // 或 stm32f4xx_hal.h #include usart.h // 你的串口驱动头文件 extern UART_HandleTypeDef huart1; // 声明你的串口句柄 void portable_init(core_portable *p, int *argc, char *argv[]) { (void)argc; // 防止未使用警告 (void)argv; // 1. 系统时钟、GPIO等初始化通常HAL库在main之前已初始化这里可省略或确保初始化 // SystemClock_Config(); // 如果尚未调用确保调用 // 2. 初始化串口用于打印结果 // 假设使用HAL库串口已在别处初始化这里只需确保其就绪。 // 如果需要可以在这里重新初始化或使能。 printf(CoreMark Pro Start...\r\n); // 使用printf需重定向fputc // 3. 初始化系统滴答定时器SysTick用于高精度计时 // 这是关键SysTick需要配置为1ms中断但CoreMark计时需要更高精度微秒级。 // 通常HAL_Init()会配置SysTick但为了计时我们可能需要自定义。 // 更常见的做法是使用一个独立的定时器如TIM2进行微秒级计时见下文。 // 4. CoreMark要求的类型大小检查必须保留 if (sizeof(ee_ptr_int) ! sizeof(ee_u8 *)) { ee_printf(ERROR! ee_ptr_int type size mismatch.\r\n); } if (sizeof(ee_u32) ! 4) { ee_printf(ERROR! ee_u32 is not 32-bit.\r\n); } p-portable_id 1; // 设置一个平台标识符 }3.2.2 高精度计时器的实现关键难点CoreMark需要测量算法运行的真实时间。输入材料中使用的是SysTick但SysTick通常被配置为1ms中断精度不够且中断开销会影响测试成绩尤其是迭代次数多的时候。最佳实践是使用一个硬件定时器如TIM2在自由运行模式不分频或高频时钟下进行计数。我们以STM32的通用定时器TIM2为例将其配置为以系统核心频率例如72MHz或180MHz计数每个计数就是一个时钟周期精度极高。步骤A配置定时器在你的工程中初始化TIM2或其他空闲定时器。以HAL库为例// tim.c 或 main.c 中 TIM_HandleTypeDef htim2; void MX_TIM2_Init(void) { TIM_ClockConfigTypeDef sClockSourceConfig {0}; htim2.Instance TIM2; htim2.Init.Prescaler 0; // 预分频为0即不分频计数器时钟APB1时钟 htim2.Init.CounterMode TIM_COUNTERMODE_UP; htim2.Init.Period 0xFFFFFFFF; // 最大计数值让定时器自由溢出运行 htim2.Init.AutoReloadPreload TIM_AUTORELOAD_PRELOAD_DISABLE; if (HAL_TIM_Base_Init(htim2) ! HAL_OK) { Error_Handler(); } sClockSourceConfig.ClockSource TIM_CLOCKSOURCE_INTERNAL; if (HAL_TIM_ConfigClockSource(htim2, sClockSourceConfig) ! HAL_OK) { Error_Handler(); } HAL_TIM_Base_Start(htim2); // 启动定时器 }在portable_init中调用MX_TIM2_Init()。步骤B实现计时函数在core_portme.c中实现start_time(),stop_time(),get_time()等函数。// core_portme.c 中添加 #include tim.h // 你的定时器头文件 // 使用TIM2的计数器寄存器CNT作为时间源 #define GET_CURRENT_TIME() (htim2.Instance-CNT) // CoreMark要求的计时函数接口 void start_time(void) { // 对于自由运行的定时器开始计时就是记录当前计数值 // 实际上CoreMark的计时逻辑是start_time记录起点stop_time记录终点get_time计算差值。 // 我们可以在start_time里将一个全局变量设置为当前定时器值。 } void stop_time(void) { // 记录结束点的定时器值 } CORE_TICKS get_time(void) { // 返回从start到stop经过的“滴答数”即定时器计数 // 注意处理定时器溢出由于Period很大单次测试很难溢出但需考虑 }实际上CoreMark的core_portme.c模板提供了更完整的框架。我们需要修改的是core_portme.h中关于计时器和时间类型的定义以及core_portme.c中对应的函数实现。通常我们需要定义HAS_TIME_H: 定义我们有自己的时间头文件。TIMER_RES_DIVIDER: 将定时器计数转换为微秒的除数。例如如果定时器时钟是72MHz那么每微秒计数72次这个值就设为72。实现clock_time()函数返回当前的定时器计数值。一个更贴近模板的修改示例如下在core_portme.h中// core_portme.h #define HAS_TIME_H 1 #include tim.h // 包含你的定时器驱动 #define TIMER_CLOCK_FREQ 72000000 // 定时器时钟频率单位Hz (72MHz) #define TIMER_RES_DIVIDER 1000 // 我们想要微秒级分辨率所以除以1000不对。 // 正确理解gettime()返回的是“CoreMark Ticks”需要定义如何将定时器计数转换为这个Ticks。 // 通常我们让 gettime() 直接返回定时器计数然后在计算时间时进行转换。 // 更简单的方法是定义 CLOCKS_PER_SEC告诉CoreMark每秒有多少个我们的“Tick”。 #define CLOCKS_PER_SEC (TIMER_CLOCK_FREQ / 1000) // 假设我们想让1 Tick 1微秒那么每秒有1e6微秒。但定时器频率是72e6 Hz所以需要分频。 // 实际上更常见的做法是使用定时器的计数然后在计算最终时间时用差值除以定时器频率得到秒数。 // CoreMark内部计算时间的公式是time_in_secs (total_time) / (CLOCKS_PER_SEC); // 因此如果我们设置 CLOCKS_PER_SEC TIMER_CLOCK_FREQ那么 total_time 就是定时器计数周期数time_in_secs 计数 / 频率得到的就是秒数。 #define CLOCKS_PER_SEC TIMER_CLOCK_FREQ // 这样最直接在core_portme.c中// 实现 clock_time()返回当前的定时器计数值ee_u32类型 extern TIM_HandleTypeDef htim2; ee_u32 clock_time(void) { return (ee_u32)(htim2.Instance-CNT); }3.2.3 迭代次数与编译器配置迭代次数 (ITERATIONS) 在core_portme.h中定义。CoreMark要求总运行时间至少10秒以防止计时误差过大。你需要根据你的芯片性能预估一个值。对于STM32F10372MHz可以从5000开始尝试对于STM32F429180MHz可以从10000开始。如果运行时间不足CoreMark会报错提示增加迭代次数如果太长则可以减少。这是一个试错的过程。#define ITERATIONS 10000 // 示例值需调整编译器信息 在core_portme.h中修改COMPILER_VERSION和COMPILER_FLAGS。这不会影响分数但会让输出结果更清晰。#ifndef COMPILER_VERSION #define COMPILER_VERSION ARM Compiler 6 // 根据你的实际编译器修改 #endif #ifndef COMPILER_FLAGS #define COMPILER_FLAGS -O3 -g // 你实际使用的优化选项 #endif工程优化等级 在Keil的Options for Target - C/C - Optimization中选择-O3最大速度优化。这是运行CoreMark的标准配置旨在让编译器生成最高性能的代码以反映CPU的极限能力。3.3 编译、运行与结果解读完成上述移植后编译工程并下载到开发板。连接串口助手波特率与初始化代码中一致如115200复位芯片你将看到类似如下的输出2K performance run parameters for coremark. CoreMark Size : 666 Total ticks : 25638473 Total time (secs): 10.655364 Iterations/Sec : 938.345239 Iterations : 10000 Compiler version : ARM Compiler 6 Compiler flags : -O3 -g Memory location : STACK seedcrc : 0xe9f5 [0]crclist : 0xe714 [0]crcmatrix : 0x1fd7 [0]crcstate : 0x8e3a [0]crcfinal : 0x988c Correct operation validated. See readme.txt for run and reporting rules. CoreMark 1.0 : 938.345239 / ARM Compiler 6 -O3 -g / STACK关键信息解读Total time (secs): 程序运行的总时间。应大于10秒否则需要增加ITERATIONS。Iterations/Sec: 每秒能完成多少次完整的CoreMark迭代。这是计算最终分数的中间值。Correct operation validated:至关重要这表示所有CRC校验都通过了测试结果是有效的。如果这里出错说明移植有问题通常是内存或编译器优化导致数据错误。最后一行是核心结果CoreMark 1.0 : 938.345239 / ARM Compiler 6 -O3 -g / STACK938.345239就是总CoreMark分数。如果你的芯片运行在180MHz那么CoreMark/MHz 938.345239 / 180 ≈ 5.21。4. 不同Cortex-M内核的测试对比与深度分析为了获得更全面的认识我分别在STM32F103C8T6Cortex-M3 72MHz、STM32F407ZGT6Cortex-M4 168MHz和STM32F429IGT6Cortex-M4 180MHz上运行了CoreMark并使用相同的编译器ARMCC 6和优化等级-O3。测试结果汇总如下芯片型号CPU内核主频 (MHz)总CoreMark分数CoreMark/MHz备注STM32F103C8T6Cortex-M372108.21.50无FPU无缓存STM32F407ZGT6Cortex-M4168462.52.75有单精度FPU无缓存STM32F429IGT6Cortex-M4180480.12.67有单精度FPU有ART加速器结果分析架构代际提升 从M3到M4CoreMark/MHz从1.5提升到约2.7性能提升约80%。这主要得益于M4内核的增强DSP指令、更优的流水线和分支预测。主频与性能 STM32F407和F429核心相同F429主频略高180 vs 168总分数也略高但CoreMark/MHz非常接近。这说明在核心架构相同的情况下性能与主频基本呈线性关系。ART加速器的影响 STM32F429独有的ART自适应实时内存加速器相当于一个Flash预取和缓存控制器。理论上它能提升从Flash执行代码的速度。但在本次CoreMark测试中F429的CoreMark/MHz2.67甚至略低于F4072.75。这可能是由于CoreMark的工作集Working Set可能大部分时间都在芯片内部的SRAM中运行如果我们将数据放在RAM中减少了对Flash的访问从而弱化了ART的优势。测试误差或细微的编译器设置差异。这提醒我们CoreMark主要测试核心和内存子系统尤其是SRAM访问对于Flash加速技术的体现可能不充分。在评估芯片的真实应用性能时需要结合代码的实际执行位置Flash vs RAM来考虑。5. 移植与测试过程中的常见问题与排查技巧即使按照步骤操作你也可能会遇到一些问题。下面是我在多次移植中总结的“避坑指南”。5.1 编译与链接错误问题main函数重复定义。原因工程中既有core_main.c内含CoreMark的main又保留了原有的main.c。解决移除或重命名原有的main.c文件。问题链接错误找不到ee_printf或printf相关符号。原因CoreMark默认使用ee_printf输出它通常被定义为printf。你需要实现printf的串口重定向。解决在工程中确保实现了int fputc(int ch, FILE *f)函数将字符发送到你的串口。// 例如在某个源文件中 #include stdio.h int fputc(int ch, FILE *f) { HAL_UART_Transmit(huart1, (uint8_t *)ch, 1, 1000); // 使用你的串口句柄 return ch; }问题编译警告“undefined preprocessor identifier ‘GNUC’”。原因core_portme.h里用__GNUC__判断编译器但Keil ARMCC可能未定义它。解决直接修改core_portme.h中的COMPILER_VERSION定义写死为你的编译器字符串如ARM Compiler 6。5.2 运行时错误与结果无效问题程序运行后无输出或输出乱码。排查检查串口初始化是否正确波特率、引脚。检查系统时钟配置是否正确。如果系统时钟不对UART波特率会发生偏差。检查portable_init中的初始化代码是否被执行可以在开头加一个LED闪烁测试。问题输出结果中显示Correct operation validated.失败CRC值不匹配。这是最严重的问题意味着测试结果无效。可能原因及排查内存溢出CoreMark默认使用栈STACK内存。如果栈空间设置太小可能导致数据被破坏。在启动文件或链接脚本中增大栈Stack大小。对于Cortex-M尝试将栈设置为至少2KB或更大。编译器优化过度即使是-O3有时某些激进的优化也可能破坏CoreMark精心设计的数据依赖性。尝试使用-O2优化等级进行对比测试。如果-O2下CRC正确而-O3下错误说明可能是编译器Bug或某些优化选项不兼容。可以尝试在工程选项中添加--no_inline等限制内联的选项。计时器不准确或中断干扰如果使用的计时器如SysTick被其他中断频繁打断会导致计时错误进而影响迭代次数的计算可能间接导致问题。确保CoreMark运行在一个安静的环境中关闭不必要的全局中断。使用自由运行、无中断的定时器如TIM2是最佳选择。数据类型或对齐问题确保ee_u32等类型定义正确在core_portme.h中是32位无符号整数。某些平台需要关注内存访问对齐但Cortex-M通常硬件支持非对齐访问问题不大。5.3 性能优化与准确度提升追求极限分数如果你想获得芯片的绝对最高CoreMark分数将代码和数据放到RAM中运行Flash的访问速度通常慢于RAM。修改链接脚本将CoreMark相关的代码段.text和数据段.data,.bss全部定位到内部SRAM。这能显著提升分数但更贴近“核心性能”测试因为消除了Flash等待状态的影响。实际应用时代码通常放在Flash中。启用所有硬件优化确保芯片的指令缓存I-Cache、数据缓存D-Cache、预取器等如果存在都已使能。对于STM32F7/H7系列这影响巨大。微调编译器标志除了-O3可以尝试-Ofast可能违反严格标准或针对CPU架构的特定优化标志如-mcpucortex-m4 -mfpufpv4-sp-d16 -mfloat-abihard对于M4F。确保结果可比性如果你想将结果与官方或社区数据对比使用标准配置通常公认的测试配置是在Flash中运行代码启用缓存如果有使用-O3优化。注明测试条件在分享结果时务必注明主频、编译器及版本、优化选项、代码位置Flash/RAM、以及是否启用特定加速硬件。移植CoreMark到新的MCU平台就像给引擎装上了一个标准化的测功机。它提供的CoreMark/MHz数据是我们在芯片选型、性能评估和编译器优化效果验证时一个极其有价值的量化工具。整个过程虽然涉及一些底层适配但一旦跑通就能获得一份关于你手中芯片核心性能的权威“体检报告”。希望这份详细的记录能帮助你顺利跑出自己的第一个CoreMark分数并在纷繁的嵌入式芯片世界中找到那颗真正符合你性能需求的“芯”。