C 嵌入式软件的Mips计算

客户最近（并且反复）问我运行我们的软件需要什么。通常，我们可以通过向客户解释这实际上取决于cpu/os/hw（我们的软件是高度可移植的）和/或用例（即我们的软件是如何使用的）来解决这个问题

但我还有最后一个问题，不仅非常顽固，而且还为顽固提供了很好的理由他想要估算，因为他不确定自己是否有足够的能力运行我们的软件，所以在估算之前购买软件是不合理的。（我们无法提供演示/评估，因为它需要大量工作才能在此特定平台上运行。）

现在的问题是：有没有人在任何硬件和软件上有过这样的工作经验？任何现实生活中的例子都会非常有用。我可以选择在许多操作系统和硬件上运行我们的软件。所以，如果你知道在任何硬件上进行这种评估的任何工具，我都有可能使用它，或者至少有一个想法。我只知道如何测量计算机上的CPU负载

编辑：

---

使用probe实际上是一个好主意，假设我可以创建一个控制环境，其中只有我的软件运行所有我可以计算的指令，我想probe有一个接口来完成这项工作。事实上，我有一些不同的硬件调试器，如果有人有经验如何做这将是非常好的，不管怎样，我明天将阅读一些文档，希望能在这方面找到一些东西

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

如果其他一切都失败了，在您可以访问的任何平台上运行它，用您的MHz/客户的-MHz的商来扩展运行时。这将为您提供一个非常粗略的估计，客户将体验哪种类型的运行时。

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

实际上，你要做的是

找出最坏情况下的指令路径，并计算执行所需的周期数（这意味着阅读该CPU的程序集，并查看告诉您周期数的CPU手册）

现在找出你的实时限制

然后使用#1表示最坏情况循环。向上/向下调整CPU，直到其符合实时约束

添加一个捏造因素

---

您需要做的第一件事是为正确的操作提出一些标准。 这在很大程度上取决于应用程序的性质——您的标准可能包括“必须在3ms内执行代码x”，或者“必须具有低于100ms的延迟”。 任何与定量测量不相关的标准都将是困难的，因为它将是主观的

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

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

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

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

---

然后，您可以将此比率以及测试和目标处理器的相对MIP合并到执行时间的计算中。

您说您的软件是高度可移植的，因此我的建议是在处理器体系结构中最接近的平台上运行软件，处理器指令集和存储器/外围总线类型。测量必须实时运行的最长例程，然后估计它将在其体系结构上运行多长时间。

好的，您知道这充满了免责声明和警告—CPU速度、内存速度、缓存命中、MMU页表刷新、总线争用等。。。（如果是重型嵌入式系统）所有因素都会对决策产生重大影响

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

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

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

好的方面是，一旦你完成了这项工作，你就可以将这些工作重新用于其他目标和/或电路板，也许这些数字将帮助你提高销售额和/或调整/优化你的软件

祝你好运

最现代的da