我正在开发一款嵌入式实时系统软件（使用 C 语言）。我已经设计了软件架构 - 我们知道所需的各种对象、各种对象之间所需的交互以及任务之间的 IPC 通信。根据这些信息，我需要确定操作系统 (RTOS)、微处理器和内存大小要求。
（我最有可能使用 Quadros，因为客户根据他们在类似项目中的经验建议我使用这个）
但是我很困惑该从哪一个开始，因为选择一个可能会影响其他的选择。
您能否还指导我考虑从软件设计中估计内存需求所需的参数（内存需求的下限和上限）？
（本次评估中可以忽略组件成本）
答案1
内存比你的时间更便宜，至少对于最初生产的几个系统来说是这样。将尽可能多的东西塞进原型系统的电路板上，然后对代码进行调试。你可以购买填充较少的电路板进行生产，但现在你需要大量资源。
- 分配比您认为需要的更大的堆栈，并用一堆重复的文本预先填充它们，例如拥有该堆栈的线程的名称。有多少被覆盖将显示每个线程使用了多少堆栈。对该数字应用一个舒适的安全系数以获得最终分配。
- 分配大量堆。更好的方法是，不要在运行时使用堆，而是在启动时将堆预分配给一个（或多个）固定块大小的内存池。仅在运行时分配和取消分配这些内存池。
- 将内存使用情况记录到一个大的（或循环的）缓冲区中，或者将请求者的 ID 记录到一个与块的实际数据空间不同的前导码中——任何会留下痕迹的东西，您以后都可以找到它，以帮助分析内存需求、内存匮乏或崩溃。
- 将缓冲区置于堆栈之外，这样超支就不会导致一切戛然而止，或者更糟的是，导致控制权的疯狂转移。
- 测试系统。让它经历任何你认为会对堆栈和内存要求造成压力的场景。招募一些典型和非典型用户来做同样的事情。他们中的一些人会尝试做你没有预料到的事情。鼓励他们这样做。
当你完成所有这些之后，你对内存需求的控制就会比现在好得多。
（编辑；我无法发表评论）
詹姆士：
“我们希望对现阶段所涉及的硬件和成本进行粗略估计。你认为这可能吗？”
简短的回答是肯定的，RAM 可能是硬件成本的一小部分，因此继续高估 - 你应该仍然接近。
作为粗略检查，您可以通过编写和编译几个函数来获得粗略的源代码行与内存比率，然后进行推断，从而粗略估计静态内存需求（代码和静态数据）。您需要粗略计算并对您的设计将如何扩展到函数和代码行进行一些有根据的猜测。您能否对您的设计在运行时对动态结构（堆栈和堆或池）的使用做出有根据的猜测？我可能会至少将我的估计值增加一倍或四倍。
您能否在现有计算机上实现该系统，短路在该环境中没有意义的函数（通过使用短返回编译代码而不是#ifdef 将其排除）？
如果您真的需要估算而不需要实施太多措施，我认为您将只能进行推断。
答案2
听起来你已经做出了一些设计选择。
我们知道需要各种对象、各种对象之间所需的交互以及任务之间的IPC通信。
您需要一个多线程操作系统和一个可以运行它的 uC，这通常意味着您需要一个带有 MMU 的处理器。操作系统选项包括 Quadros、QNX、linux、wince 等。
根据您的“对象”（模块是 C 语言的更好术语 :) ）正在执行的操作，您可以确定所需的架构类型。16 位架构是否足够？需要更多内存或处理更大的数字，那么 32 位是正确的答案吗？大量浮点工作？那么您可能需要一个带有 FPU 的处理器。做很多类似 DSP 的工作？也许您需要一个 DSP 或带有类似 DSP 指令或协同处理器的 uC。运行图形显示？需要带有内置 LCD 控制器的 SoC 还是希望在外部执行。做大量 2D 图形？需要具有一些图形加速的 SoC。
列出您需要的功能，并估计您的代码中有多少属于整数运算、循环、浮点运算、图形运算、DSP 运算等类别。
这应该允许您对所需的设备级别进行分类。对于某些架构，您可以使用 GCC 交叉编译一些代码，并在 Linux 上使用 qemu 对其进行模拟。这可能只有在您需要在特定架构上测试关键算法的性能时才值得。这可以帮助您扩展应用程序所需的速度。
第二个考虑因素是功耗和对电源管理的支持。结合所需的性能，您可以选择 DSP、uC、应用处理器等。
正如其他人所说，我不会担心内存使用情况，只需瞄准更大的目标，通常不同的 RAM 大小是引脚兼容的，因此您可以减少 RAM 以进行生产。这里唯一真正需要回答的问题是：
*我需要多大的地址空间？16 位？32 位？等等
*我需要外部 RAM 吗，还是 uC 内部 RAM 就足够了？<--选择架构并开始寻找 SoC 后再回答这个问题。
在大多数情况下，在同一类处理器中进行选择是一场“圣战”，也就是说，在 32 位 risc 市场中，有些人会支持 ARM，有些人会支持 coldfire，有些人甚至可能支持 PIC32。最终，任何处理器都可能有用。您必须根据可用的 SoC 以及所需的外围设备、开发的简易性（工具链有多好）和成本进行选择。
操作系统的选择也一样，对于大多数应用程序来说，Linux、QNX 和 quadros 都是一个难题，通常最好的答案是你最熟悉的那个。即使最终成本略高，开发时间的减少通常可以抵消构建成本。一定要确保操作系统具有所需的功能、共享库、进程间通信、管道以及你需要的一切。
作为一般规则，我会首先选择您的架构。这对您的设备性能的影响比操作系统大得多。此外，该领域的操作系统通常在许多架构上都受支持。此外，更好的操作系统符合 POSIX 标准，如果编写正确，您的大部分代码应该能够在多个操作系统上运行。
如果您必须多次尝试才能做出正确的选择，请不要感到难过。您可能会找到一个完全符合您的代码需求的内核，但经过一番研究后发现它不支持您需要的一些次要功能，或者没有带有您需要的外围设备的 SoC，甚至该产品的订单已经延期了 6 个月。只需确保在做出初步选择后，根据该部分研究设计将如何组合在一起，以便您现在就发现绊脚石，而不是在开发进行到一半时才发现。