一類在線調試技術在嵌入式系統軟件中的應用

黃小波，邵 威

（中國電子科技集團公司第三十八研究所 安徽 合肥 230013）

在嵌入式技術飛速發展的今天，嵌入式產品已出現在社會的各個領域，包括通信、軍事、儀表、航空、航天、工業控制及家庭消費等。從嵌入式系統的外觀上看，嵌入式系統像是一個“可編程”的電子“器件”；從構成上看，嵌入式系統是集軟硬件于一體的、可獨立工作的計算機系統；從功能上看，它是對宿主對象進行控制，使其具有“智能”的控制器。從應用的角度看，嵌入式系統與通用計算機系統相比，有如下一些特點：

1）專用性。由于嵌入式系統通常是面向某個特定應用的，所以嵌入式系統的硬件和軟件，尤其是軟件，都是為特定用戶群來設計的，它通常都具有某種專用性的特點。

2）實時性。目前，嵌入式系統廣泛應用于生產過程控制、數據采集、傳輸通信等場合，主要用來對宿主對象進行控制。例如，對嵌入在武器裝各中的嵌入式系統、在火箭中的嵌入式系統等應用中的實時性要求就極高。實時性是對嵌入式系統的普遍要求，是設計者和用戶重點考慮的一個重要指標。

嵌入式系統軟件的調試技術一直是一項困難而富有挑戰性的技術。嵌入式系統中的軟件調試與桌面軟件的調試有很大的不同[1]。調試嵌入式系統時，調試器和被調試程序往往是物理上分離的。調試器運行在宿主機上，而被調試程序運行在目標機上，宿主機與目標機之間通過某種媒介進行通信。同時，還要在目標機上運行一個稱為調試代理（Debug Agent）的監控程序，由它來負責與運行在宿主機上的調試器進行通信，控制被調試程序的執行，并將被調試程序的執行情況及時反饋給調試器。對一些響應時間要求在毫秒或微妙的系統軟件中，在調試過程中，還要考慮設計的調試程序是否會導致系統延時、是否會破壞系統軟件的高實時性要求。本文針對工程實際應用背景，提出了一種基于數組動態保存、文件記錄和后期數據處理的在線調試技術，在滿足系統軟件高實時性要求的前提下，有效地解決了通訊數據丟包排查、數據誤碼率驗證和運行過程中關鍵變量的可持續跟蹤問題，對解決系統聯調中出現的問題有很強的現實價值。

1 動態調試技術

程序的動態調試就是實際上機調試。根據程序編譯、連接和運行時計算機給出的錯誤信息進行程序調試，這是程序調試中最常用的方法，也是最初步的動態調試。在此基礎上，通過分段隔離、設置斷點、跟蹤打印等對程序進一步調試。目前常用的動態調試方法包括：

1）使用在線仿真器

隨著低成本的在線調試能力的增強，如ARM的ICE[2-3]（在線仿真器），通過指令單步調試變得更容易。這種方式可以查看和修改變量值，顯示寄存器的內容，查看內存塊。

2）使用遠端調試器

通過遠端調試器[4-5]，登錄或接管目標系統操作權限，實現讀/寫內存與寄存器、設置斷點、單步執行和繼續執行功能。

3）在IDE（集成編輯環境）中使用動態調試

很多IDE都帶有動態調試功能[6]，諸如：單步運行、變量監視等，有的甚至給出了寄存器、反匯編、函數調用堆棧。但上述方法通常只有在目標系統停止運行時候才可以實現。然而，很多實時系統是不能停止的，由此引出如下動態調試方法。

4）使用 assert（斷言）

目前一般嵌入式操作系統都支持C或C++語言。C或C++語言有一個很實用的系統函數：assert（）。一旦計算發生錯誤，程序就會立即終止，并提醒程序員有錯誤發生，在哪一行。使用斷言最根本的好處是自動發現許多運行時產生的錯誤，但斷言不能發現所有錯誤。

5）使用 printf（）函數

對于用C或C++語言編寫的嵌入式軟件，可以將printf（）函數來插入到代碼中的關鍵位置來查看或輸出對象的動態行為。但過度使用 printf（）函數將導致程序臃腫，且會造成系統延時。當通過串口傳遞信息時，這個延時會更長。

6）使用文件實時保存

將變量實時寫入本地文件中，通過對保存的文件進行后續分析，查看系統在整個運行過程中行為的變化情況。由于文件實時讀寫過程中會強制占用系統時間，所以對于一些高實時性運行環境，使用文件實時讀取方式會破壞系統工作環境的完整性。

2 具體設計

基于數組動態保存、文件記錄和后期數據處理的在線調試技術的具體設計流程如圖1所示。

圖1 在線調試技術處理流程圖Fig.1 Flow chart of online debugging technique process

對上述流程圖中的執行條件，可以在程序設計時預先定義好觸發條件，也可以通過外部發送控制命令（如通過網絡、串口或1553B總線等發送命令）來產生觸發事件。為考慮程序通用性，設計如下函數：void WriteDataToBuf（unsiged char*pch，unigned short len）；用于將需保存的單個數據或一串數據寫入到數組buf中。

函數WriteDataToBuf使用如下：

1）存放char或unsiged char類型數據，如：unsiged char m_value=0x11； WriteDataToBuf（&m_value，1）；

2）存放short或unsiged short類型數據，如 unsiged short m_value=0x1111； WriteDataToBuf（&m_value，2）；

3）存放占用4個字節長度的類型數據 （long，float等），如 float m_value=12.345； WriteDataToBuf（&m_value，4）；

4）存放長度為len的數組，如 unsiged char m_value[20]，WriteDataToBuf（m_value，20）；

為便于直觀查看文件pData中數據，一般將文件pData生成后綴名為txt文件，生成的文件pData.txt一般采用16進制保存 （用戶可自行定義存儲方式）。對生成的pData.txt文件，依據實際應用需求，可進行后續加工處理。通常的處理方式包括：

①將變量存儲的類型轉換為10進制數據；

②通過其它數據分析工具進行分析，如origin，excel，matlab等，以查看數據或一串數組的變化情況；

③編寫特制應用軟件進行數據分析處理。

3 工程應用

某SAR（Synthetic Aperture Radar，合成孔徑雷達）系統組成示意圖如圖2所示。

圖2 SAR系統組成示意圖Fig.2 Schematic diagram of the SAR system components

圖中虛線框內為與SAR連接的外部設備。其中測控處理軟件固化在監控分系統板載PC104中，采用QNX操作系統，編寫語言為C++。測控處理軟件接收的控制指令由一體化顯控發送，發送的方式為非周期形式。由于為無線鏈路通訊方式，存在數據指令丟失的可能，為增加指令通訊的可靠性，每一控制指令連續發送3次。設一體化顯控發送的指令包記為A={A1，A2，A3，A4…An}，n=16。 指令包經過機載數據終端重新打包后形成指令包 B，記為 B={A，B1，B2，…Bm}，m=44。 指令包A成為指令包B的子包。測控處理軟件通過異步串口接收機載數據終端發送的指令包B。

為減少人工操作，一體化顯控界面設計了多種一鍵操作模式，點擊一個控制按鈕，會自動發送若干條控制指令，最多會一次發出10條以上控制命令，每條控制指令重復發送3次，兩條指令間隔時間在20 ms內，也即意味測控處理軟件在1秒內會收到近50條控制指令。

在實際聯調過程中，發現測控處理軟件收到的指令包A存在丟包現象。丟包的原因可以通過鏈路組成形成如下猜測（如下猜測之一或其組合）：

①一體化顯控發送出來的指令包A已經丟包；

②指令包A經過無線鏈路傳輸到機載數據終端前已經丟包；

③機載終端接收指令包A，在處理過程及重新對數據打包形成指令包B過程中丟包；

④測控處理軟件通過串口接收到完整指令包，但在處理過程中丟包。

由于虛線部分為外部設備，且已經過聯調（當然沒有和SAR聯調過），如上猜測2）和3）暫時排除在外。而一體化顯控采用VC編程，可方便驗證猜測1）的情況。

為便于測試，一體化顯控發送控制指令時，將某個字節定義為幀編號，每發送出一條指令時，幀編號加1。假設一體化顯控發送出去的控制指令都正確的話，如果測控處理軟件通過串口收到的控制指令丟包，正常的排查措施如下：

① 在測控處理軟件中使用printf函數將接收到的數據通過屏幕輸出的方式實時打印出來。帶來的問題是，屏幕刷新速度太快，無法確認數據實際接收情況；同時頻繁使用printf函數會造成系統延時，影響串口接收中斷，破壞了系統實際工作環境。

②累計1 s統計接收到的正確數據包，然后通過printf（）函數輸出到屏幕上。帶來的問題是，無法確認是哪組指令出現丟包，每組指令丟包多少；

③在測控處理軟件中將從串口接收到的原始數據實時保存到文件中。帶來的問題是，采用實時文件讀寫方式會造成系統延時，影響串口接收中斷，破壞了系統實際工作環境。

④在機載數據終端送出數據時采用串口調試工具。帶來的問題是，由于現場條件約束，無法使用串口調試工具。

針對上述調試手段的不足，現采用基于數組動態保存、文件記錄和后期數據處理的在線調試技術來查看數據丟包率及數據丟包可能的源頭。具體解決過程如下：

① 申請一個較大空間的數組，如可存字節長度為100 000個；

② 通過調試工具（一般可用網絡調試工具）向測控處理軟件發送數據存數組指令；

③一段時間后發送數據存文件指令，生成pData.txt文件；

④將生成的pData.txt文件用ftp工具下載到本地計算機；

⑤ 使用VC編寫一個自動分析數據的軟件，將文件pData.txt中的數據按照數據包B的長度進行抽取，以查看數據包B中數據是否存在數據錯位；

⑥在抽取出數據包B的基礎上，通過軟件再抽取出數據包A。并可以根據實際情況，自動分析數據中校驗和錯誤率、有效控制命令數、相鄰數據幀編號之差等。

通過上述方法，就可以分析出數據的丟包數、丟包率、數據傳輸錯位情況，同時可判斷是由于機載數據終端送出時已丟包還是由于測控處理軟件在處理過程中產生了數據丟包。最終將問題定位在猜測2）上。

4 結束語

相比較一般常用調試方法，基于數組動態保存、文件記錄和后期數據處理的在線調試技術具有如下優點：1）不中斷當前程序執行過程；2）對程序動態實時性能影響較小，特別是對高實時性要求的系統軟件，此優點尤其突出；3）可根據實際需求保存任意時間段、任意變量的數據值，便于后續分析；4）可查看變量在毫秒或微秒級內的動態變化過程。

[1]陳云川，羅克露.嵌入式軟件調試技術[M].北京，電子工業出版社，2009.

[2]張春燕.嵌入式系統調試技術初探[J].電腦知識與技術，2010，6（30）：8627-8629.

ZHANG Chun-yan.Research of debugging technique to embedded system[J].Journal of Computer Knowledge and Technology，2010，6（30）：8627-8629.

[3]張楷，湯志忠.一種新的高速嵌入式系統軟件調試技術[J].計算機工程與應用，2003（29）：59-62.

ZHANG Kai，TANG Zhi-zhong.A new high speed embedded system software debug technology[J].Journal of Computer Engineering and Applictiaon，2003（29）：59-62.

[4]李紅衛.嵌入式遠程調試工具的研究與實現[J].微計算機信息，2009，25（2）：87-89.

LI Wei-hong.Study and realization of embedded remote debugging tool[J].Journal of Control&Automation，2009，25（2）：87-89.

[5]黃光紅，李鋼，張仁斌.通用嵌入式系統遠程調試器的研究與設計[J].計算機測量與控制，2008，16（6）：853-855.

HUANG Guang-hong，LI Gang，ZHANG Ren-bin.Research and design of universal embedded system remote debugger[J].Journal of Comouter Measurement&Control，2008，16（6）：853-855.

[6]魯愛國，萬曦.基于vxWorks的嵌入式軟件遠程調試[J].艦船電子工程，2007，27（6）：151-154.

LU Ai-guo，WAN Xi.Deep discourse about remote debugging of embeded software based on vxWorks[J].Journal of Ship Electronic Engineering，2007，27（6）：151-154.