1

我正在将 Windows 7 库移植到嵌入式平台。为了做到这一点，我的雇主问我移植系统后需要多少内存（和 CPU，但现在让我们专注于内存）——这样他就可以根据我的需要调整电路板的大小。

我在互联网上看了一下，似乎没有太多关于这个问题的信息，因此我的问题是：

  1. 为了粗略了解闪存中代码的内存占用量（仅代码没有内存用于数据），我在互联网上读到我应该对我使用的所有 dll 的大小求和。似乎所有编译器和平台都为代码足迹提供了不同的大小，但总体而言，代码（不含数据）的大小通常非常接近。你确认吗？

  2. 为了处理仅数据所需的内存（堆+堆栈但没有代码），我查看了任务管理器（和进程资源管理器）。我使用的数据总量似乎在“峰值工作集”中指定。不过我有几个问题：

2.a. “工作集”是否包括堆+堆栈内存还是仅对应于堆？

2.b。“工作集”是否也包括代码的大小？（因为我在 Windows 7 上，代码也存储在 RAM 中，而不是像嵌入式系统那样存储在闪存中），还是只对应于数据？

2.c。似乎“峰值工作集”反映了从程序启动时实际在 RAM 中的最大物理内存量，但它没有反映程序之后可能占用的大小（如果我碰巧在运行时分配内存 -这会很糟糕；） - 峰值会继续增加）。你确认吗？

2.d。因此，您是否还确认如果我不在运行时分配内存，“峰值工作集”应该大致是我的嵌入式系统需要的最大 RAM 大小？由于系统技术的差异，最大的尺寸差异......

谢谢，

安托万。

4

1 回答 1

1

除非您打算在 Windows Embedded 上运行您的应用程序，否则查看 Windows 中的代码和数据使用情况并不能作为任何有用的指标！

1) DLL 是库 - 并非其中的所有代码都会被您的代码使用。大多数嵌入式系统都是静态链接的，链接器只会链接代码中实际引用的模块。因此，获取 DLL 依赖项的总和可能会导致对内存需求的总体高估。

2) Windows 内存管理在内存使用方面非常浪费 - 因为它可以并且这样做通常会提高典型桌面系统的性能。例如，Windows 中的线程堆栈通常为 2Mb 量级 - 您可能很少使用这么多，但 Windows 在任何情况下都会将其提供给您，因为它可以并且这样做会在安全方面犯错。嵌入式系统中的线程堆栈通常从几十字节到几十千字节不等——这取决于您的应用程序。

Windows 任务管理器显示 Windows 分配给您的进程的内容，这可能与您的进程需要的内容无关。此外，您的应用程序正在使用 Windows 服务 - 用于内核和设备服务的所有内存都不会显示为您的进程的一部分，但您的嵌入式系统可能仍然需要这些。

如果您确实使用 Windows 原型代码来评估嵌入式系统要求，那么最好的起点是让链接器生成一个映射文件，该文件将根据静态分配的数据和代码大小详细描述内存使用情况.

代码大小不仅取决于编译器的性能，还取决于指令集的效率。一些架构实现了比其他架构更高的代码密度。Windows 应用程序代码大小从来都不是嵌入式代码大小的一个很好的指标，因为它的执行环境可能会有很大的不同。例如，一个 32 位 ARM 上的抢先式多任务 RTOS 内核可以用不到 10Kb 的代码实现，一个文件系统可能需要另外 10 个，网络堆栈从 10 到 30K，USB 另一个 10。如您所见，这是一个与桌面代码不同的世界。

可能更容易确定数据内存使用情况；但是你通过分析你的应用程序而不是观察 Windows 做了什么来做到这一点。有您的应用程序直接实例化的数据，然后有您可能调用的库和设备驱动程序实例化的数据 - 在 Windows 中，后者可能相对较大并且不受您的控制。用于网络堆栈、USB、文件系统等的典型嵌入式系统库变得更小，并且在性能和大小方面更具确定性。

最好的办法是根据其一般用途、性能要求、实时约束和硬件要求（显示、网络、I/O、大容量存储等）来描述您的应用程序，然后查看可比较的解决方案或实施解决方案所需的库；大多数嵌入式系统都是“裸板”并且没有您在 Windows 中找到的服务，除非您编写它们或使用第三方解决方案 - Windows 很少是嵌入式系统的可比解决方案。

如果它只是一个库而不是应用程序，那么使用 Windows 托管的 GCC 交叉编译器为 likley 目标构建它，看看它最终有多大。你不需要硬件，甚至不需要花钱。

于 2012-07-13T20:54:57.460 回答