1. 前言

在上一回的“国内首款M52内核：G32R501 EVAL板卡开箱记录”中，我们已经对这款基于Arm v8.1-M架构、内置自研紫电数学指令扩展单元并支持Arm Helium™技术的MCU——Geehy G32R501，有了初步的了解。

当时，我们只是让板子LED闪一闪、串口输出点字符，就觉得“可以了”。可事实上，要真正衡量一颗MCU的运算实力，CoreMark成绩往往是一个比较客观、公认的参考指标。到底这个G32R501跑起CoreMark来能交出怎样的成绩单？今天就让我们一起“探秘”一番，看这款Cortex®-M52 MCU在CoreMark上的表现究竟是“平平无奇”还是“惊艳四座”！

本篇就给大家呈现各版本配置下跑分的情况——不同Flash/RAM运行区域会对CoreMark产生什么样滴影响？

2. CoreMark移植：前置准备

2.1 移植过程

其实，CoreMark移植到G32R501跟常见的APM32之类MCU的思路相差不大。 • 首先，下载官方CoreMark源码； • 然后，根据Geehy的标准库/SDK修改工程环境、时钟配置； • 最后，编写或引用标准的串口输出（printf重定向）让CoreMark测试完成后打印结果即可。

如果你对移植细节感兴趣，可以参考“【技术分享】APM32F411 CoreMark 测试分享 - 极海MCU官方技术支持论坛”，这里就不赘述啦。

2.2 printf重定向

关于G32R501如何做串口打印，可回顾“国内首款M52内核：G32R501 EVAL板卡开箱记录”，其中展示了 GPIO28 / GPIO29 的 UART 通道配置，以及如何重载 fputc 函数。只要能让CoreMark结果顺利“跑”到终端，就万事OK了。

3. 跑分注意事项：G32R501内存访问花样多

在CoreMark跑分时，我们往往会精确追求“运行在哪个存储区域、主频几何、是否有等待周期”等等。G32R501有点特别之处就是Flash访问路径和可配置的内存结构。简单总结如下：

0. Flash访问（FACC vs. CPU Cache） G32R501的CPU0和CPU1皆可通过两条不同路径读Flash：

   • ITCM -> FACC -> Flash：针对ITCM空间访问的加速逻辑；
   • CPU CACHE -> C-Bus -> busmatrix -> Flash：针对C-Bus空间访问，每次访问可由CPU Cache执行加速。

这意味着，在链接脚本中把代码放到不同“段”(ITCM Flash位置或C-Bus Flash位置)，MCU的访问方式有所区别。ITCM段主要依赖FACC加速，而C-Bus段依赖CPU Cache加速。

0. SRAM灵活分区 G32R501总共有128KB的SRAM，可通过CFGSMS模块对其分块配置，比如可以划分一部分SRAM作为ITCM、另一些作为DTCM，或者纯粹当普通SRAM等。这样可满足不同应用场景的速度或灵活性需求。

有了这些可玩要素，自然而然就想看看CoreMark在三种常见场景下的差异：

• 从“C-Bus Flash”运行（即通过CPU Cache加速）；
• 从“ITCM Flash”运行（FACC加速）；
• 从“ITCM RAM”运行（这就更快了，理论上可直接贴近CPU）。

4. 跑分配置：三大场景

为了更好对比，我在工程中配置了不同的tag（运行位置各不同），分别使用Geehy SDK提供的链接脚本，路径：G32R501_SDK_V1.1.0\device_support\g32r501\common\sct

0. g32r501_cbus_flash.sct

   • 对应把代码映射到 C-Bus Flash

1. g32r501_itcm_flash.sct

   • 对应把代码映射到 ITCM Flash

2. g32r501_itcm_ram.sct

   • 对应把代码直接放进 ITCM RAM

需要注意的是，对于ITCM_RAM运行的核心可执行代码，默认情况下板卡的启动还是在Flash里。所以需要按照下面的流程才能让ram里面的代码顺利运行：

0. 先用“g32r501_cbus_flash工程”擦除flash，
1. 再启动“g32r501_itcm_ram工程”调试，进入仿真后让CPU以全速执行，最后退出仿真状态。这样它才能真正从ITCM_RAM去运行CoreMark。

5. 首轮PK：三大场景的表现

先看看在未手动启用CPU Cache的情况下，我们得到的CoreMark/MHz成绩（注：CoreMark量纲还可能和实际主频相关，这里以CoreMark/MHz为横轴做对比）：

0. C-Bus Flash

   • CoreMark/MHz 1.0 : 1.643746
   • 这个数字不算出彩，和普通中端MCU跑分相当。

1. ITCM Flash

   • CoreMark/MHz 1.0 : 3.861335
   • 哇，翻个倍还多。说明走ITCM -> FACC方式确实给力。

2. ITCM RAM

   • CoreMark/MHz 1.0 : 4.166570
   • 再提升了一丢丢，果然直接跑在RAM上通常会速度更快。和理论的M52内核跑分差距不大

可以看出，C-Bus Flash 的1.64左右对比ITCM Flash和ITCM RAM，差距极大。不禁让人好奇：“C-Bus不是也有CPU Cache加速吗？为何比ITCM Flash慢这么多呢？”别急，我们还没手动打开CPU Cache呢，它应该是默认没启动。

6. 再进阶：开启CPU Cache 后的惊喜

既然C-Bus Flash可以配合CPU Cache，那我们就再来一试。只需要在代码里调用以下两行即可：

// Enable Instruction Cache
SCB_EnableICache();

// Enable Data Cache
SCB_EnableDCache();

然后重新测试，得到的新成绩是：

0. C-Bus Flash（已启用Cache）

   • CoreMark/MHz 1.0 : 4.022346
   • 哇，一下子从1.64飙到4.02，翻了两倍多，这才是真正领略到了Cache的力量啊。

1. 其他两个就没什么变化了

   0. ITCM Flash，它本来走的是FACC加速，不依赖CPU Cache。
   1. ITCM RAM，说明这部分也本身就很快了，Cache不 Cache影响也不大。

如此一来，C-Bus Flash 在开启CPU Cache后，甚至可以和 ITCM RAM 跑分平起平坐。看得出，给C-Bus这边加Cache能带来明显效能飞跃，也就合理解释了“为什么 ITCM Flash 在没有启用CPU Cache时就能跑到3.86”的现象——它本身有另一条加速通道 FACC 做后台支持。所以一旦给C-Bus运输线上再加个CPU Cache的“加速捷径”，差距就一下子被抹平甚至反超！

7. G32R501：性能、特色与更多想象

G32R501在不同内存访问配置下，CoreMark/MHz可稳定落在4.0～4.16之间，已非常接近纯官方Cortex®-M52的参考值4.30。

来源https://armkeil.blob.core.windows.net/developer/Files/pdf/product-brief/arm-cortex-m-processor-comparison-table.pdf

精彩的部分在于，G32R501还是双核M52架构，并拥有自研“紫电数学指令扩展”与Arm Helium™(MVE)矢量扩展，三重硬件“Buff”。CoreMark作为纯整数基准，本身并未包含大量DSP或矢量化测试。而在实际应用中，如果启用紫电扩展与Helium™指令调度更多DSP或矢量运算，尤其是像电机矢量控制、滤波、FFT这类场景，性能提升空间会更大。

对于G32R501的CoreMark测试数据你还满意么？欢迎在评论区留言一起讨论吧。

这里是代码 附件：G32R501_SDK_V1.1.0_CoreMark.zip（请复制G32R501_SDK_V1.1.0\中的utilities到解压后的根目录才能正常编译和调试哦）~