|
先来张全家福展示本次测试设备)
左上角是STM32MP135F-DK 主控芯片是STM32MP135FAE7 单核A7 主频最高1Ghz 4-Gbit DDR3L, 16 bits, 533 MHz 右上角是STM32MP257F-DK 主控芯片STM32MP257FAK3 Arm^®^ 双核Cortex^®^ -A35(运行频率1.5 GHz) 4-Gbit DDR3L, 16 bits, 533 MHz 下面是STM32MP157开发板 STM32MP157A 双核A7 650Mhz 1Gddr3 STM32MP135F-DKMP135F是单核A7测试程序比较简单 首先获取Coremark的源码
编译前需要先source一下工具链
由于我们是交叉编译 所以只需要编译即可 然后手动传输到开发板上运行即可 这里我们使用make compile命令编译我们想要的文件 // (编译图片放的是MP257的 mp135的忘记截图了 其实都差不多 主要取决于是source的哪个编译链 A35是64bit A7是32bit) 这写输出信息中我们要关注下-O3这个优化等级 因为不同优化等级对跑分影响是很大的
在输出目录下将编译文件使用scp命令传输到开发板中,先使用sync命令刷新下 可以看到文件已经传输到板子上
更新之前先确认下MCU是不是处于最佳性能模式(后面抽空会讲MPU的几种性能模式),
直接./coremark.exe执行即可 稍等片刻即可输出成绩
Iterations/Sec : 3051.222396 即为跑分性能 数值越大性能越强 STM32MP157/MP257为什么会把MP157和MP257放在一起,因为这两个都是双核MCU 在跑Coremark的时候要考虑多线程优化 不然测试出来的结果会偏低很多 因为只有1个MCU在干活 MP157因为MP157和MP135都是A7架构 用的一套工具链 我们把程序上传到MP157的板子中运行 并查看CPU负载
很奇怪 明明已经读到2个CPU核心了 为什么只有一个U在干活
查阅下Coremark源码 其中有着完成的多线程实现
所以关键就是在于这个宏定义
我们将源码中这个宏定义改为1 启用多线程 并且查看makefile文件
在CFLAGS中添加多线程编译宏定义
再次进行编译
可以看到多线程宏作为编译参数已经传递进去 总结两点:
至此 再通过scp命令将文件传输进去 运行并查看CPU负载
两个核心都全部干活 没有偷懒
查看成绩 4895分 接近5000分 MP257先前已经处理了MP157部分的源码 所以在MP257上只需要重新source A35的编译链并且重新make compile即可 保险起见还是看下CPU负载
全核心负载达到100% 代码正常运行
输出成绩 7903分 接近8000 总结下方数据仅代表本次测试所使用的MPU 结果仅供参考
后续尝试多次优化 增加编译器优化标志 跑分均没有很大提高 |
OpenSTLinux 6.1发布:M33-TD加持+安全升级,STM32MPU开发效率翻倍!
直播回顾+QA | STM32MP135在工业组态HMI和工业网关中的应用实践
有奖直播 | STM32MP135在工业组态HMI和工业网关中的应用实践
STM32--STM32 微控制器详解
为什么学了几天STM32一脸茫然?
实战经验 | 1小时在STM32MPU上运行YOLOv8——训练篇
STM32 不同时钟频率有什么不同的影响
STM32入门指南:从零开始,如何为你的首个项目选择最合适的MCU?
STM32MP157D-DK1-编译并运行第一个程序hello world
STM32MP157D-DK1-SDK包安装
微信公众号
手机版
总结的很到位啊