量化節約的最簡單方法之一是BML：低成本零件要求公司花費更少的錢來制造產品。在大多數嵌入式設計中，兩個最昂貴的部件通常是屏幕（如果設備有，大多數物聯網設備沒有）和處理器。隨著您向處理器添加更多內存（閃存和 RAM），處理器的成本也會增加。雖然成本增加多少的具體細節因半導體公司而異，但粗略的經驗法則是，每增加一倍內存，處理器單位成本就會增加約一美元。

使這個問題變得更糟的是，嵌入式工程師通常不太擅長在應用程序的設計階段預測內存需求。這些對所需內存量的最佳“猜測”是處理器選擇的關鍵因素。鑒于許多生產運行每年達到數十萬或數百萬臺，在BML中增加不必要的美元會對公司的底線產生有害影響。

結果，無數項目“資源緊張”，這是“我們沒有正確預測內存需求”的代碼。加劇這個問題的是，BML通常在項目開始時就被推薦給高層管理人員。一旦發生這種情況，成本就變得不可侵犯。這使人們爭先恐后地減少內存占用，或者依靠采購來保持BML成本與管理層預期的相同，通過協商其他組件的更好價格。為了減少內存占用，團隊經常求助于編譯器的優化引擎來減小生成的代碼的大小。

提高編譯器優化的標準

一些工程師非常不愿意加快優化，因為他們認為優化會給系統帶來錯誤。這種情況很少發生，根據我的經驗，大約 5% 的優化器問題最終是優化器的問題。

當優化級別提高時，編譯器對 C 和 C++ 語言的語義非常挑剔。優化決策是基于對語言規則的嚴格解釋做出的。通常，工程師并沒有以他們看起來很自然的方式完全了解語言和代碼的所有細微差別。

例如，如果函數調用是這樣編寫的：

myFunc（varA， varB， varC， varD）;

自然的假設是從左到右讀取變量：varA 將從內存中讀取，然后是 varB 等。

但是，C 或 C++ 中沒有任何內容表明必須如此。如果內存是有目的地布置的，或者是偶然的，其中varB位于varD旁邊，那么高級優化可能會使用索引寄存器來讀取連續的內存空間，以節省代碼大小和速度。

在大多數情況下，這不會對代碼產生影響。但是，如果您依賴于從左到右編寫時要訪問的變量，則可能會出現代碼在較低優化下運行良好但在高級別無法正常運行的情況。這就是工具供應商提供的良好支持結構可以幫助發現這些類型的問題并重寫代碼部分以更好地優化和正常工作的地方，而與優化設置無關。

此外，如果您的代碼可以在高優化下工作，那么它編寫正確并且經過更好的測試。如果代碼在更高的優化下不起作用，則很有可能潛在缺陷正在等待“咬你”。

當設置為高尺寸優化時，好的工具可以節省 10-40% 的代碼大小。但是，并非所有優化轉換都是任何代碼段的好選擇 - 某些轉換實際上可能會增加某些類型代碼的代碼大小。這本身就是一篇文章。

目前，有一些資源可以解決“從編譯器中獲得最少的資源”，這意味著最小大小的代碼和最緊湊的執行時間。節省如此多的代碼空間可能是剝離功能以保持在設備尺寸內、由于手動優化代碼而錯過計劃或超出 BML 預算之間的區別。

雖然好的代碼可以在任何優化級別上運行相同的操作，但調試高度優化的代碼在最好的情況下是很棘手的。例如，整個代碼段可以折疊到完全不同的位置的其他代碼段中。這就是為什么必須在低優化或無優化下調試代碼，并在增加優化以運行全部測試之前驗證代碼是否正常運行的原因。

在 BML 中調試成本

使嵌入式調試變得困難的部分原因是，大多數人根本不知道他們武器庫中的所有調試工具。它們傾向于默認使用 printf 語句和代碼斷點。在嘗試隔離硬故障、查找發生堆棧溢出的位置或找出變量不斷被破壞的原因時，這些默認值無濟于事。

好消息是，存在特殊的工具可以幫助發現這些類型的問題。

處理硬故障

讓我們從硬故障開始。許多現代MCU都具有實時指令跟蹤功能，可讓您跟蹤指令流。在基于 Arm 的設備上，用于實現此目的的技術是嵌入式跟蹤宏單元 （ETM）。參考手冊將指示設備是否支持 ETM。如果是這樣，請將跟蹤引腳拉到調試標頭，并使用啟用跟蹤的調試器（如 IAR I-jet 跟蹤），該調試器可以捕獲該實時指令流并將其顯示在調試器窗口中。

要查找導致硬故障的原因，只需滾動跟蹤窗口并找到在轉到錯誤處理程序之前執行的指令。瞧！這個指示是罪魁禍首。如果可以可靠地重現錯誤，請在錯誤處理程序處設置斷點并消除跟蹤窗口中的所有滾動 - 罪魁禍首是跟蹤窗口中的倒數第二條指令。

現在原因已知，因此可以在罪魁禍首上設置斷點，并再次運行測試用例，以查看導致異常的代碼出了什么問題。

但是，如果您沒有 ETM 怎么辦？大多數基于 Arm 的設備都具有串行線輸出 （SWO），允許采樣、低速跟蹤。雖然您沒有收到每一條指令，但這可以提供足夠的跟蹤信息來縮小范圍并定位問題。此外，嘗試降低MCU時鐘和/或調整SWO設置，以便從調試器中獲取更精細的跟蹤信息粒度，以查明問題發生的位置。

其他設備架構具有與 ETM 或 SWO 類似的功能。因此，使用高質量的工具可以利用這些信息并快速隔離和消除問題。此外，可用的支持資源有助于提高 SWO 的性能，以保護更多的跟蹤數據。

停止堆棧溢出

堆棧溢出或找出變量神秘丟失其內容的原因怎么樣？使用相同的技術來診斷這兩種情況。

在 Arm 領域，大多數處理器在其調試接口中都有一個數據觀察點和跟蹤 （DWT） 塊，可用于快速隔離這些類型的問題。在這種情況下，請使用數據觀察點來找出壞事發生的地方。每當接觸一段數據時，此觀察點本質上就是一個斷點。

將選項配置為僅在讀取和/或寫入數據時中斷執行。此外，甚至可以將其限制為僅在數據是具有特定位掩碼的特定值時才中斷。在避免每次訪問數據時都停止時，這非常方便。

在堆棧溢出的情況下，我們希望在堆棧頂部設置一個數據觀察點。讀取或寫入該值并不重要，因為堆棧在代碼中的那個點已經吹響了。處理器將在堆棧頂部停止執行，提供一個完全保留的調用堆棧，允許查看哪一段代碼正在吹堆棧以及您如何到達該點。這是確定如何修復錯誤的關鍵。

清理整理數據

對于被破壞的數據，我們使用基本相同的技術，只是在該變量經歷寫入時設置數據觀察點。如果始終使用相同的值進行破壞，則進一步縮小斷點的范圍，僅在將該值寫入變量時跳閘。然后，再次運行我們的測試用例，找出導致問題的代碼。

同樣，許多其他架構（如瑞薩電子RL78、RX和許多其他芯片供應商的器件）具有類似的功能，可用于實現相同的結果。使用高質量的工具，查找這些類型的問題變得更加容易，并增加了滿足緊迫的時間表和截止日期的幾率。

讓采購知道您的關心

事半功倍似乎是一個矛盾，但通過使用正確的工具可以輕松實現。通過使用編譯器優化，您可以將代碼硬塞到盡可能小的空間中，以便為您的應用程序使用最便宜的設備。

優化還可以幫助桌面檢查您的代碼，以查看它在高優化下是否運行相同，以便在您將代碼簽入構建之前找到潛在的代碼缺陷（從而使每個缺陷都計入您的發布指標）。它還通過使用完整的工具箱更快地查找錯誤來幫助您更有效地進行調試，從而縮短測試和修復周期并更快地啟動項目。

如果您知道工具箱中有哪些工具（以及如何正確使用它們），您就可以讓每一分錢都為您的組織發揮作用。

審核編輯：郭婷