本帖最后由 wolfgang2015 于 2018-4-20 09:58 编辑
拿到一款MCU评估板，第一件事就是要验证其MCU最大性能，能让诸位心中对MCU的处理能力有个了解，这次《低功耗MCU运行FreeRTOS》培训的STM32L49拿到后我也做了一次不完全Coremark跑分测试一、测试的方法
1、设定最大时钟
2、设定串口，修改功能引脚与PCB板上的一致，并设定串口时钟
设置对应波特率设置为115200（图略）
虽然之前就知道Coremark根据编译器不一样结果会不一样，但没有亲侧一边，心有不甘。
这里从筹备到得到最后测试结果，花费了较多的时间。
这里用CubeMX设置好后，依次生成了4种工程（EWARM、MDK-ARM、SW4STM32、TrueSTUDIO），然后用四种不同的开发环境对工程进行逐一编译，下载到Nucleo STM32L496 开发板上，检测不同编译器对Coremark跑分的影响。
二、不完全跑分结果：
1、EWARM 工程，用IAR 8.20编译后下载，得到跑分结果入下图：
跑分结果：CoreMark 1.0 : 264.970853 / IAR ANSI C -Ohs-no_size_constraints / STACK
2、MDK-ARM 工程，用KEIL 5.18编译后下载，得到跑分结果入下图： 跑分结果：CoreMark 1.0 : 209.561597 / MDK ANSI C -O3-Optimize for Time / STACK
3、SW4STM32 工程，用AC6 V2.0 编译后下载，得到跑分结果入下图： 跑分结果：210.222415 / GCC6.3.1 20170620 (release)[ARM/embedded-6-branch revision 249437] -O3 / STACK
4、TrueSTUDIO 工程，用TrueSTUDIO 9.0.0 编译后下载，得到跑分结果入下图：
跑分结果：209.608451/ GCC6.3.1 20170215 (release) [ARM/embedded-6-branch revision 245512] -Ofast /STACKrevision 249437] -Ofast / STACK
5、Coremark跑分对比表
三、跑分差异不完全分析
另外我看见论坛里有朋友跑出了165左右的Coremark值，最初我也在IAR编译的代码中跑出这样的分数，觉得背离官方给的参考值甚远，就觉得那里没对，多方对比之后发现这个问题源于CubeMX生成的代码，这里把问题指出来，望各位在自己的工程代码使用中多加注意，看似跑分结果，实际上代码的问题会让MCU性能大打折扣。望诸位多加注意！
问题跑分：
官方参考值：
官方给出的STM32L496的理论 Coremark跑分在273.55左右，可能是时钟是用较为稳定SHE缘故，同IAR的分之相差不到10分，算接近了。
问题跑分（分值：165）与官方跑分偏差交大的重要原因，经分析是CubeMX生成的SystemClock_Config()函数代码造成，函数代码中缺少以下代码的显示定义，跑分偏低的朋友，请检查诸位的代码中是否确实红色部分的定义:
........
RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSI;
RCC_OscInitStruct.PLL.PLLM = 1;
RCC_OscInitStruct.PLL.PLLN = 10;
RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2;
........
对应的系统时钟图的位置为：
这里使用的MCU是STM32L系列的单片机，片内具备SHI、MSI两种内部时钟，经测试在相同80MHz的主频下，二者跑分相差小于1，几乎相等，性能接近。至于为什么缺失丢PLLM设置就会让MCU跑慢,经查询用户手册《DM00083560_ENV4.pdf》，也没有能解答出来。
手册中默认是0x0,既是1分频，但初始化的时候并不是1分频，这部分PLLM设置时，需要代码作显示定义。
这里或许可能是HAL代码的一个BUG还是寄存器初始化的BUG，就不得而知了，望大家使用时多加注意。
| 
微信公众号
手机版
发表于 2018-4-19 21:47:13
楼主
发表于 2018-4-20 12:22:11
