G32R501：这个Cortex®-M52 CoreMark 分数是几何？
# 1. 前言在上一回的“[国内首款M52内核：G32R501 EVAL板卡开箱记录](https://bbs.21ic.com/icview-3466854-1-1.html)”中，我们已经对这款基于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官方技术支持论坛](https://bbs.21ic.com/icview-3333812-1-1.html)”，这里就不赘述啦。
## 2.2 printf重定向
关于G32R501如何做串口打印，可回顾“[国内首款M52内核：G32R501 EVAL板卡开箱记录](https://bbs.21ic.com/icview-3466854-1-1.html)”，其中展示了 GPIO28 / GPIO29 的 UART 通道配置，以及如何重载 fputc 函数。只要能让CoreMark结果顺利“跑”到终端，就万事OK了。
---
# 3. 跑分注意事项：G32R501内存访问花样多
在CoreMark跑分时，我们往往会精确追求“运行在哪个存储区域、主频几何、是否有等待周期”等等。G32R501有点特别之处就是Flash访问路径和可配置的内存结构。简单总结如下：
1. **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加速。
2. **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
1. **g32r501\_cbus\_flash.sct**
* 对应把代码映射到 C-Bus Flash
2. **g32r501\_itcm\_flash.sct**
* 对应把代码映射到 ITCM Flash
3. **g32r501\_itcm\_ram.sct**
* 对应把代码直接放进 ITCM RAM
需要注意的是，对于ITCM\_RAM运行的核心可执行代码，默认情况下板卡的启动还是在Flash里。所以需要按照下面的流程才能让ram里面的代码顺利运行：
1. 先用“g32r501\_cbus\_flash工程”擦除flash，
2. 再启动“g32r501\_itcm\_ram工程”调试，进入仿真后让CPU以全速执行，最后退出仿真状态。这样它才能真正从ITCM\_RAM去运行CoreMark。
---
# 5. 首轮PK：三大场景的表现
先看看在未手动启用CPU Cache的情况下，我们得到的CoreMark/MHz成绩（注：CoreMark量纲还可能和实际主频相关，这里以CoreMark/MHz为横轴做对比）：
1. **C-Bus Flash**
* CoreMark/MHz 1.0 : 1.643746
* 这个数字不算出彩，和普通中端MCU跑分相当。
2. **ITCM Flash**
* CoreMark/MHz 1.0 : 3.861335
* 哇，翻个倍还多。说明走ITCM -> FACC方式确实给力。
3. **ITCM RAM**
* CoreMark/MHz 1.0 : 4.166570
* 再提升了一丢丢，果然直接跑在RAM上通常会速度更快。和理论的M52内核跑分差距不大
!(data/attachment/forum/202507/02/190311l2y7799p78kkvkpk.png "image-20250702181029984.png")
可以看出，**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，那我们就再来一试。只需要在代码里调用以下两行即可：
```c
// Enable Instruction Cache
SCB_EnableICache();
// Enable Data Cache
SCB_EnableDCache();
```
然后重新测试，得到的新成绩是：
1. **C-Bus Flash（已启用Cache）**
* CoreMark/MHz 1.0 : 4.022346
* 哇，一下子从1.64飙到4.02，翻了两倍多，这才是真正领略到了Cache的力量啊。
2. **其他两个就没什么变化了**
1. ITCM Flash，它本来走的是FACC加速，不依赖CPU Cache。
2. ITCM RAM，说明这部分也本身就很快了，Cache不 Cache影响也不大。
!(data/attachment/forum/202507/02/190332cttwkmb0s7t0upvp.png "image-20250702181040721.png")
如此一来，**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。
!(data/attachment/forum/202507/02/190416a566rm9bffdd9g7z.png "image-20250702181049798.png")
来源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测试数据你还满意么？欢迎在评论区留言一起讨论吧。
这里是代码[!(/source/plugin/zhanmishu_markdown/template/editor/images/upload.svg) 附件：G32R501_SDK_V1.1.0_CoreMark.zip](forum.php?mod=attachment&aid=2420234 "attachment")（请复制G32R501_SDK_V1.1.0\中的utilities到解压后的根目录才能正常编译和调试哦）~
---
#申请原创# @21小跑堂
非常详细的测试和分析，G32R501在不同配置下的性能表现令人印象深刻。尤其是开启CPU Cache后，C-Bus Flash的性能提升非常明显，几乎可以与ITCM RAM相媲美。这证明了G32R501在内存访问和缓存管理方面的灵活性和高效性。
这个对比很是详细啊！
写程序的时候还是要根据项目任务的优先级，可以灵活一些存储与实现。 这个M52是主打实时性内核？ gouguoccc 发表于 2025-7-7 08:01
这个M52是主打实时性内核？
不是实时性，是“计算”，偏于dsp。 复古留声机 发表于 2025-7-4 13:42
非常详细的测试和分析，G32R501在不同配置下的性能表现令人印象深刻。尤其是开启CPU Cache后，C-Bus Flash ...
是的，嘻嘻ᖰ⌯'▾'⌯ᖳ 话不多说，送上赞先
Gfan 发表于 2025-7-7 16:53
话不多说，送上赞先
感谢官方大大的点赞{:titter:} 非常详细的测试和分析，G32R501在不同配置下的性能表现令人印象深刻。特别是开启CPU Cache后的提升，证明了硬件加速的重要性。
非常详细和深入的分析！G32R501的性能表现确实令人印象深刻，尤其是在开启CPU Cache后，性能提升显著。期待看到更多关于紫电数学指令扩展和Helium™技术的实际应用案例。
页:
[1]