嵌入式软件的Mips计算

好吧,你知道这充满了免责声明&警告--CPU速度、内存速度、缓存命中率、MMU页表刷新、总线争用等。。。(如果是重型嵌入式系统)所有因素都会对决策产生重大影响。。。。

.... 我要做的就是这样。买一个实时操作系统(和我在一起),也许像FreeRTOS(免费,真是一个惊喜)或u/C-OS-II(不是免费的商业用途,可能3千美元)。这些内核允许您检测代码以计算空闲CPU周期(空闲任务自旋循环)。

因此,将整个应用程序(或客户的应用程序)作为您同意的板上唯一(非空闲)任务运行(例如MPC860板、ARM7板等)。通过RTOS测量主板上的CPU百分比。(例如,“在以60 MHz运行的Flibber板上,我们的应用程序使用了12%的CPU。”)

如果他们不给你更多,或者反之亦然,这听起来对他们来说是一个相当合理的长度。

祝你好运

您是否有一个模拟器或调试器探测器可以为您提供指令计数?您甚至不需要为正确的目标平台执行此操作,只需粗略计算指令数即可。

如果其他一切都失败了,在您可以访问的任何平台上运行它,用您的MHz/客户的-MHz的商来扩展运行时。这应该给你一个机会 非常 粗略估计客户将体验哪种运行时。

对于带有操作系统的系统,I/S是一个“弱”指标。

实际上,你要做的是

1. 找出最坏情况下的指令路径,并计算执行所需的周期数(这意味着阅读该CPU的程序集,并查看告诉您周期数的CPU手册)。
2. 现在找出你的实时限制。

您需要做的第一件事是为正确的操作提出一些标准。 任何与定量测量不相关的标准都将是困难的,因为它将是主观的。

找到正确操作的标准将允许您找到代码的关键部分。请记住,这些可能出现在角落的情况下,而不是正常操作。

如果代码的关键部分很小,那么计算目标平台的指令将相对简单。如果你有一个模拟器,那可能会更容易。(根据代码的不同,您可能需要进行模拟以确保它得到执行,但如果您有大量代码要分析,这可能仍然比计算指令要容易)

如果您的关键代码很大,那么您可能必须执行类似于JesperE建议的操作。除非您的应用程序针对的是一个对价格极其敏感的行业,否则客户很可能会愿意接受计算中的一点松弛——因此,高估cpu需求比低估cpu需求要好。

与JesperE的建议不同的是,我建议不要将重点放在MHz上,而是放在目标的实际MIPS上。例如,在测试平台上编译和执行代码——如果你有一个分析器,那就更好了。然后为客户的目标编译代码,并对生成的可执行文件中的指令数量进行粗略比较。 然后,您可以将此比率以及测试处理器和目标处理器的相对MIP合并到执行时间的计算中。

大多数现代调试器都提供了查看指令的功能,例如;差饷物业估价署。此外,您还可以使用处理器模拟器来了解所使用的指令,而无需在平台上实际运行(如果您的代码是独立的,如编解码器或加密模块,并且不依赖于板)-请注意,这将为您提供指令,而不是周期。周期将受到电路板详细信息的影响(例如:等待状态、内存访问等)

在我使用的两种处理器架构(MSP430F5X和AVR32)上,处理器内置了一个硬件周期计数寄存器。我通常有一个方案,当处理器不忙时,它会进入低功耗空闲状态,处理器内核停止。然后有两个选项用于计算实际的处理器负载。我可以在周期计时器函数中设置断点并读取执行的处理器周期数,也可以通过在操作开始和结束时读取此寄存器来检测特定进程。处理器空闲时间不会出现在周期计数中,因为CPU暂停了这段时间。

RapiTime 声明可以为目标提供最坏情况下执行时间的概率估计。我没有亲自使用过,但看过他们的演示。。。

如果您的目标与客户的目标非常相似,您可能可以扩展它以估计他们平台上的WCET。然后,他们可以将其与当前系统的“空闲”时间进行比较。