得益于功能越來越強大的μP，嵌入式系統變得越來越復雜，嵌入式軟件程序變得越來越大，程序越大，更難以調試。更重要的是，在大型嵌入式程序中捕獲錯誤可能會對公司的工程資源造成負擔。由于嵌入式系統的應用程序很大，程序員缺乏對代碼中各種可執行模塊的深入了解。此區域是軟件分析的用武之地。該術語指的是可以收集有關程序中函數的執行時間，頻率和調用模式的數據的軟件。這種分析可能是優化代碼的第一步。通過讓您知道哪些功能非常耗時，它可以讓您加快這些代碼區域的速度。此外，它還可以讓您知道執行程序是否在應用程序期間至少調用您編寫的所有代碼。

分析工具通常通過將額外的軟件嵌入應用程序源代碼的關鍵點來收集信息。或者，您也可以使用外部電路從系統總線捕獲分析信息。您可以使用無輔助軟件分析或外部硬件輔助軟件分析。

C編譯器通常為您提供分析開關(-p)，對編譯的代碼起作用以生成分析信息。例如，自由軟件基金會(www.gnu.org/fsf/fsf.html)Gnu C編譯器為您提供了“-p”編譯器開關，您可以使用它來準備目標代碼以使用“gprof”收集分析數據“ 效用。當您調用-p開關時，編譯器會在每個編譯過程的開頭添加額外的代碼(清單1)。這個額外的“檢測代碼”可以調用運行時記錄實用程序。該列表顯示了典型過程的初始x86代碼序列(在此示例中為lapinit())。該代碼使用自由軟件基金會的Gnu匯編語法，該語法具有操作代碼，源和目標的一般指令格式。

當您輸入每個過程時，檢測代碼會調用mcount()支持例程。然后，檢測代碼傳遞mcount()變量的地址，以支持記錄執行程序的調用歷史記錄的數據結構。在程序執行結束時，檢測代碼調用(exit()并自動生成mon.out配置文件.mon.out文件包含呼叫發生信息和統計采樣信息。操作系統收集統計數據。通過檢查應用程序的程序計數器，計時器滴答(例如每10到20毫秒)。

操作系統的prof實用程序使用mon.out文件中的配置文件數據生成應用程序的執行配置文件。應用程序可執行文件的圖像中的符號信息。對于圖像文件中的每個過程符號，操作系統確定該符號與下一個符號之間的執行時間百分比。

分析信息很有用，因為它使您能夠識別在程序中執行時間過長的過程。這些過程非常適合進一步優化。使用這種“源代碼檢測”，mcount()需要 很長時間。此外，此技術要求您重新編譯應用程序軟件以插入檢測代碼。

分析工具具有不同程度的復雜性 - 從命令行分析工具到基于圖形用戶界面的工具。例如，Cygnus的$ 2000/座(嵌入式)GNU-Pro C編譯器和$ 299(用于Linux)CodeFusion IDE附帶gprof和gcov命令行分析工具。

一些分析工具，例如Applied Microsystem Corp(AMC)的CodeTEST-Hardware-In-Ckt，提供了一個由硬件探測輔助的嵌入式測試平臺(圖1)。該工具使您可以在軟件開發的最后階段專注于嵌入式軟件測試和分析。 CodeTEST-Hardware-In-Ckt比其他分析工具需要更少侵入性的儀器。此外，該工具進行非抽樣測量。

您必須“檢測”應用程序，并且此檢測非常類似于prof實用程序所需的檢測。但是，在這種情況下，檢測是“輕量級的”(清單2)。這種方法不需要昂貴的調用mcount() - 類似的過程。相反，它只需要將識別值寫入內存位置;該標識值出現在處理器的內存總線上。外部捕獲硬件響應將數據放入示例__TAG_PORT地址的寫入。當發生這些寫入時，捕獲硬件會將寫入的標識值和時間戳記錄到記錄緩沖區中。

您還必須以與過程條目類似的方式檢測過程的退出代碼即結尾。唯一標識值“標簽”與代碼中的每個檢測點相關聯。寫入的地址值(稱為標記端口)解決了您選擇此問題的方式。根據目標μP探頭，只要目標系統或CPU終止總線周期，您就可以在目標存儲器映射中的任何位置找到標簽端口。您通常可以將標記端口放在目標RAM中，RAM設備本身會同步終止所有寫周期，包括標記寫入。

AMC規定您必須確保任何處理器的片上數據存儲器不會將寫入緩存到tagport或捕獲地址。如果內存確實緩存了這些寫入，那么直寫而不是回寫必須處理寫入。此技術可確保在執行寫入指令后，標簽值很快出現在處理器總線上。不幸的是，寫緩沖技術仍然會延遲標簽信息的出現。

出于這個原因，硬件輔助分析比具有時間關鍵實時嵌入式系統的純軟件方法更受歡迎。您通常通過在編譯之前處理源代碼來插入檢測。或者，工具提供程序不是使用編譯器來檢測代碼，而是提供后處理工具，它可以檢測已編譯的模塊。 AMC的LiveCODE工具是可執行代碼檢測的一個示例，它允許您在應用程序在目標系統中運行時執行交互式跟蹤(圖2)。 LiveCODE通過將特定于處理器的本機分支指令發送到內存中要在目標中進行所需檢測的點來自動檢測可執行文件。然后程序分支到內存中的另一個位置，該位置工具執行用戶插入的語句。然后，LiveCODE將控制返回到分支點，并且編譯的應用程序繼續執行。

LiveCODE自動準備圖像，以便程序將這些段的執行歷史顯示為已編譯的子系統，模塊和函數樹視圖格式的應用程序。交互式序列圖顯示了執行期間函數入口和出口的圖形表示(圖2)。您可以在執行跟蹤中前進和后退。 LiveCODE可以節省寶貴的開發時間，因為您可以在程序執行時與程序進行交互，選擇要跟蹤的代碼部分，插入調試代碼語句，或者在不停止執行或不必重新編譯應用程序的情況下修改變量。 LiveCODE支持PowerPC處理器體系結構，可用于Windows和Solaris主機系統。價格從4000美元起。 AMC計劃在下一季度升級LiveCODE以處理其他處理器架構。

CodeTEST提供源代碼執行的高級和實時可見性。例如，在跟蹤執行功能期間，該工具會對嵌入式軟件執行跟蹤，而不是硬件。軟件“instrumenter”實用程序準備用戶的程序以進行在線驗證。該實用程序讀取程序源文件并將測試點指令插入代碼中。指導者處理C和C ++源代碼程序。

CodeTEST系列包括CodeTEST-Performance，可同時測量多達32,000個函數，從而監控大多數程序中每個例程的每次執行。因為它進行非抽樣測量，所以該工具顯示真實的最差和最佳情況時間，在任務，功能或分支級別顯示結果。使用該工具的性能特征列表，您可以優化代碼的選擇部分。

CodeTEST還包括CodeTEST-Memory，它跟蹤嵌入式程序中的動態內存分配。由于該工具為跟蹤的每一行添加了時間戳，因此您可以確定函數中的循環執行所需的時間。使用CodeTEST/Statement Coverage工具，您可以識別在給定測試場景中將執行的代碼部分。交互式XY圖顯示了工具在測試時間內實現的覆蓋范圍。

CodeTEST組的另一個元素包括CodeTEST-Decision Coverage工具，該工具顯示指示執行期間執行的真/假狀態的數據。程序流程。 CodeTEST-MCDC工具(修改后的條件決策覆蓋范圍)提供了對程序代碼中每個決策點的每個條件的詳細分析，以及強制更改代碼以研究其行為的過程。此功能可幫助您生成滿足美國聯邦航空管理局規定的代碼。

CodeTEST可在CodeTEST-HW-Ckt，CodeTEST-Software-In-Ckt和CodeTEST-Native版本中使用。當嵌入式硬件不可用時，CodeTEST-Native為桌面環境提供純軟件方法。硬件準備就緒后，CodeTEST-Software-In-Ckt工具使用本機階段的工具，并將運行時精度引入嵌入式軟件測試。最后，硬件輔助的CodeTEST-Hardware-In-Ckt工具提供了一個目標探測器，用于系統操作的真實實時目標測試。

CodeTEST-Software-In-Ckt和CodeTEST-Native都與設備無關。 CodeTEST-Software-In-Ckt的價格從跟蹤，內存或報表覆蓋模塊的4000美元開始;決策覆蓋模塊7000美元;和MCDC模塊的20,000美元。對于Trace，Memory或Statement Coverage模塊，CodeTEST-Native的起價為2500美元。 CodeTEST在Windows和Unix工作站下運行。 CodeTEST支持英特爾(www.intel.com)8096CX，JX和HX; IBM(www.ibm.com)和摩托羅拉(www.motorola.com)PowerPC 603,740,750,823,821和850μs; MIPS(www.mips.com)4600,4700,4650,4300和3000μPs;英特爾/AMD的386和486;和競爭對手的68020,30,40,60,68332和68302。

競爭產品，Diab Data的純軟件RTA套件，結合了圖形運行時分析工具，提供關鍵洞察力，最大限度地提高計劃性能，提高嵌入式應用的可靠性和內存使用率。該工具套件依賴于Diab Data的D-CC和D-C ++編譯器套件生成的信息，包括Visual Interactive Profiler(VIP)，運行時錯誤檢查器和Visual Link Map Analyzer工具(圖3)。

VIP測量并分析程序的運行時行為。它首先在編譯時檢測程序。當檢測程序執行時，它在目標上構建一個配置文件數據庫，并從用戶設置的中斷標記中獲得定時信息。測試完成后，它會將配置文件數據上傳到主機，供VIP分析和顯示。

雖然平面分析技術(如mcount()實用程序)只顯示程序花費的執行時間。一個函數，分層分析還可以進一步顯示程序在每個子進程中花費多少時間在一個函數上。因此，層次分析揭示了平面分析技術會遺漏的熱點。 VIP在交互式圖形顯示中顯示配置文件數據，使您能夠快速發現嵌套的時序信息，以便集中有效的優化工作。

RTA Suite的運行時錯誤檢查工具檢測到很難識別的軟件錯誤，因為它們在程序執行之前不會顯示出來。使用運行時錯誤檢查程序，您可以快速可靠地查找錯誤。這些錯誤包括內存泄漏，數組訪問和邊界外的其他數據結構，訪問空閑或無效內存，多次釋放內存，通過空指針訪問以及堆棧溢出。

RTA Suite的Visual Link Map Analyzer允許您以交互方式輕松創建，可視化，編輯和優化內存映射設置。它還在高端μP中提供多種尋址技術。根據Integrated Systems Inc的pSOSystem產品軟件開發總監N Rajan的說法，您不需要使用三條指令來訪問數據區中的變量(x)：

LoadHX，R3;加載高16位的地址;

LoadLX，Rs;加載低16位的地址;和

加載0(R3)，R4;現在加載X的值為“0”偏移。

相反，您可以通過一條指令訪問變量：

加載X(R3)，R4，

其中偏移值可以是±32。

通過這種方式，RTA Suite允許您在鏈接模塊時定義一個小數據區域，并在此部分中放置用戶變量或數據。唯一的限制是數據區不能大于64千字節。此限制適合大多數應用。通過將R3寄存器指向此小數據區域部分的中間，您可以使用一條指令訪問此部分中的任何變量，從而生成緊湊的代碼，從而加快執行速度。

RTA Suite支持PowerPC，68K/CPU32，ColdFire和MCORE系列。 RTA Suite適用于D-CC和D-C ++編譯器支持并適用于所有主要Windows和Unix主機的所有目標。

在選擇軟件分析產品時，請記住，盡管硬件測試工具，例如作為邏輯分析儀和在線仿真器(ICE)，它們很適合調試硬件問題，它們無法深入了解軟件代碼的執行情況。

“使用傳統的ICE是不可能的，因為處理器正在成為AMD的工程師David Mann表示，太快，采用復雜的封裝技術，并且調試時系統總線活動較少。因此，他說，“微處理器供應商正朝著JTAG類型的控制方向發展，理想情況下，這種控制方式可以產生程序跟蹤。”將來，軟件配置將獲得更強大的硬件輔助功能。 AMC經理Jay Gould表示，您可能會看到更多特定于處理器的分析工具。

片上硬件輔助軟件分析

在線仿真器(ICE)廣泛用于嵌入式軟件開發。雖然ICE是低端到中端CPU的有效工具，但是模擬32位設備是令人生畏的。由于處理器的復雜架構，高時鐘速度，片上高速緩存和封裝，觀察處理器總線很困難。這種情況促使處理器廠商加入片上調試電路，以簡化ICE構建并推廣替代硬件輔助軟件開發方法。

兩種這樣的方法，摩托羅拉(www.motorola。 com)背景調試模式(BDM)和AMD的AMDebug端口值得注意。 BDM的在線仿真通過串行鏈路上的專用調試命令使處理器保持在后臺模式。例如，摩托羅拉的ColdFire系列μP(MCF5202/3/4/6)支持JTAG IEEE 1149.1，并提供一組功能強大的調試工具。對于實時跟蹤，ColdFire提供了一個并行輸出端口，該端口分區為4位處理器狀態[PST]和調試數據[DDATA]總線。 PST [3：0]允許μP發送處理器執行狀態，DDATA [3：0]顯示操作數數據。結合PST和DDATA可幫助您跟蹤μP的動態路徑執行情況，以實時調試硬件。

然而，BDM無助于軟件分析程序執行，因為它要求您停止CPU和使用特殊調試寄存器負責程序控制。這些寄存器允許您設置程序計數器斷點，地址斷點，配置存儲器和寄存器，然后使用Go命令重新啟動CPU。因此，如果沒有專門的硬件，就無法使用BDM來分析基于RTOS的應用程序。

“使用配備片上跟蹤功能的處理器可滿足許多嵌入式項目的主要工具要求，” David Mann，AMD工程師。 “鑒于跟蹤數據可以由目標處理器本身訪問或提供給控制目標的遠程主機，因此可以很靈活地使用數據。”

AMDebug端口基于增強的JTAG接口，可在AMD的x86處理器上使用，并集成了片上跟蹤緩存，您可以主要用于跟蹤程序的指令流。但是，您也可以使用跟蹤緩存來收集性能分析信息。跟蹤緩存存儲20位跟蹤條目，包括4位跟蹤代碼和16位跟蹤值。跟蹤程序的執行時，壓縮的跟蹤條目會在執行過程中自動進入跟蹤緩存。收集配置文件數據時，跟蹤控制寄存器(很像斷點控制寄存器)會啟動新的跟蹤條目的生成。

片上斷點控制寄存器在程序停止程序執行時到達程序地址。跟蹤控制寄存器選擇執行跟蹤應該開始和停止的程序地址。為了啟用性能分析，這些跟蹤控制寄存器還可以啟動和停止計數器，該計數器測量已執行的執行時間。但是，要分析配置文件數據，您需要后處理軟件工具。通過這種方式，AMDebug提供基本的性能分析。