Windows到嵌入式端口：數據和代碼內存大小

Question

我正在將Windows 7庫移植到嵌入式平臺。爲了做到這一點，我的僱主向我詢問了我的系統在移植後需要的內存數量（和CPU，但讓我們集中精力記憶內存） - 這樣他就可以根據我的需要調整板卡的尺寸。

我在互聯網上看看，那裏似乎不存在這個問題多的信息，因此，我的問題：爲了得到閃存代碼的內存佔用的一個粗略的想法

1. 內存（代碼只有沒有數據的內存），我在互聯網上閱讀，我應該總結我使用的所有DLL的大小。看起來，所有編譯器和平臺都爲代碼佔用空間提供了不同的大小，但總體上代碼的大小（沒有數據）通常非常接近。你確認嗎？

2. 爲了處理數據所需的內存（堆+堆棧，但沒有代碼），我看了一下任務管理器（和進程管理器）。看來我使用的數據總量是在「峯值工作集」中指定的。我對此有幾點疑問：

2.a. 「工作集」包含堆+堆棧內存還是僅對應於堆？

2.b. 「工作集」是否也包含代碼的大小？ （因爲我在Windows 7上，代碼也存儲在RAM中，而不是嵌入式系統中的閃存中），還是隻對應於數據？

2.c.看起來'峯值工作集'反映了從程序啓動時實際存儲在RAM中的最大物理內存量，但它並不反映程序之後可能需要的大小（如果我碰巧在運行時分配內存 - 這將是不好的;） - 峯值將繼續增加）。你確認嗎？

2.d.因此，您是否也確認，如果我在運行時不分配內存，「峯值工作集」應該大致是我的嵌入式系統需要的RAM的最大大小？最高位大小差異的原因是系統技術的區別...

感謝，

安託萬。

Answer 1

除非您打算在Windows Embedded上運行您的應用程序，否則查看Windows中的代碼和數據使用情況並不會很有用。

1）動態鏈接庫是庫 - 並不是所有的代碼都會被你的代碼使用。大多數嵌入式系統都是靜態鏈接的，鏈接器僅鏈接您的代碼中實際引用的模塊。因此，考慮到DLL依賴關係的總和，可能導致對內存需求的高估。

2）Windows內存管理隨着內存的使用而揮之不去 - 因爲它可以並且這樣做通常會提高典型桌面系統的性能。例如，Windows中的線程堆棧通常爲2Mb的數量級 - 您可能很少使用那麼多，但Windows在任何情況下都會給它，因爲它可以在安全方面出錯。嵌入式系統中的線程堆棧通常範圍從幾十字節到幾十千字節 - 這取決於您的應用程序。

Windows任務管理器顯示Windows分配給您的進程的內容，這可能與您的進程需要的內容無關。此外，您的應用程序正在使用Windows服務 - 用於內核和設備服務的所有內存都不會顯示爲您的進程的一部分，但是您的嵌入式系統可能仍然需要這些內存。

如果你確實使用你的Windows原型代碼來評估嵌入式系統的需求，那麼你最好的開始的地方是讓鏈接器生成一個映射文件，它將根據靜態分配給出內存使用的詳細描述數據和代碼大小。

代碼大小不僅取決於編譯器的性能，還取決於指令集的效率。一些架構比其他架構實現更高的代碼密度。 Windows應用程序代碼的大小從來不是嵌入代碼大小的好指標，因爲它的執行環境可能差別很大。例如，32位ARM上的先發制人的多任務RTOS內核可以用不到10Kb的代碼實現，文件系統可能還有10個，網絡堆棧從10K到30K不等，另外10個USB。你可以看到這是一個不同的世界到桌面代碼。

可能更容易確定數據存儲器的使用情況;但是你通過分析應用程序來做到這一點，而不是觀察Windows的功能。有應用程序直接實例化的數據，然後有數據實例化您可能會調用的庫和設備驅動程序 - 在Windows中，後者可能相對較大並且不受您的控制。用於諸如網絡堆棧，USB，文件系統等的典型嵌入式系統庫在性能和大小方面都變得更小且更具確定性。

最好的辦法是根據通用性，性能要求，實時約束和硬件要求（顯示，網絡，I/O，大容量存儲等）描述應用程序，然後查看可比較的解決方案或您需要實施解決方案的庫;大多數嵌入式系統都是「裸板」，除非您編寫或使用第三方解決方案，否則您沒有在Windows中找到的服務--Windows很少是嵌入式系統的類似解決方案。

---

如果它僅僅是一個庫，而不是一個應用程序，然後建立它使用Windows一個likley目標託管GCC交叉編譯器，看看它有多大結束。你不需要硬件，甚至花費任何金錢。