ARM7与CORTEX M3内核高速度下的真实性能分析
编写的好坏对 ARM7 内核的运行效率影响是多么的巨大!
从一些厂家使用了 ARM7 MCU 为主控制器的产品来分析,许多需要高速运行和需要明确指令周期的代码段被重新加载到 MCU 中的 SRAM 中来运行,SRAM 存储器可以达到单周期访问,即完全配合了 ARM7 内核的高速度来全速运行。而在更高级的 ARM 内核中,采用了 Cache 存储器,尽可能地避免上述的低效的、却又很无奈的行为。
所以,采用了 ARM7 为内核的 MCU ,参数表上常常标明 SRAM 的访问速度为全速,等待周期为 0,而 FLASH 却没有明确说明速度是多少,只是告诉你 CPU 内核在跑到什么频率段的时候,FLASH 存储器的等待周期应该设置为几个周期,这就是原因了。
由此看来,仅仅看 ARM7 的内核运行速度来判断你的代码能跑多快是不正确的。你需要分析很多综合性的情况才能大概地了解自己写的代码可以大概跑到什么速度。想要再提高,呵呵!努力吧,好好整理自己的软件架构,来配合以 ARM7 为内核的 MCU,这样也许可以达到你的期望值哦!
----------------------------------------------------------------------------------------------------------------------------------------
本文是在我仔细研究了STM32 (CORTEX M3) - 32-bit Microcontrollers后有感而发的。看了厂家的宣传是很让人兴奋,但是,仔细想想后就发现上述的问题。虽然它的指令集号称执行效率提升到了1.25 DMIPS/MHz ,但这是仅仅纯粹的内核比较。集成到 MCU 中,就遇到了 FLASH 存储器的速度问题,而它的 FLASH 存储器数据宽度是 64bit,每次就是读取 4 条连续的指令数据。
ARM7 可以将代码加载到 SRAM 中来全速执行,但是 CORTEX M3却使用了一个不同的架构,即代码和数据分离架构,类似8051。虽然极大地降低了成本,却带来了不能逾越的鸿沟:代码无法加载到 SRAM 中全速运行。而单片机中常用的软件架构:子程序入口表,划分了很多细小的功能实现代码段,又要查表来获取入口地址常数、又要跳转执行,在 STM32 系列单片机的 FLASH 中会严重拖慢内核的执行效率。所以,这个标称的高速是要打很多折扣的。浮点运算如果也是利用查表法在 FLASH 中搜索的话,运行效率就可想而知了。除非哪天 STM32 在指令段也加入全速的 SRAM ,呵呵!这还有可能全速跑代码。
因此,同频率的 ARM7 内核的 MCU 和 STM32 (CORTEX M3) - 32-bit Microcontrollers 进行执行速度比赛的话,ARM7 内核的MCU 远远胜出。而不是那种:广告上猛眼一看,似乎 STM32 (CORTEX M3) - 32-bit Microcontrollers 更加优胜的结果。但是从性价比来说,ARM7 就不行了。STM32 (CORTEX M3) - 32-bit Microcontrollers简单的架构很合适低成本的产品,代替 8051 是迟早的事情。
本人是看不惯厂家的广告中,有浑水摸鱼的感觉,特在此撰文一述,欢迎大家指正。
我之前还没看过 LM3S6965 的资料。刚才去看了一下,它的确是将 SRAM 和 FLASH 分配在统一空间中的,SRAM 内既能作为数据区使用,也可以跑代码。这是比较自由的安排,它的这种架构可以让代码全速运行。
CORTEX M3 架构提供了更加灵活的选择来帮助 MCU 厂家来节省成本,既可以为成本适当降低性能,也可以追求速度而适当增加成本,应该是更先进的
ARM7CORTEXM3内核高速 相关文章:
- Windows CE 进程、线程和内存管理(11-09)
- RedHatLinux新手入门教程(5)(11-12)
- uClinux介绍(11-09)
- openwebmailV1.60安装教学(11-12)
- Linux嵌入式系统开发平台选型探讨(11-09)
- Windows CE 进程、线程和内存管理(二)(11-09)