20xx單片機控制交通燈(編輯修改稿)

　

【文章內容簡介】 用的符號 （ 1）起始框 （ 2）終止框 （ 3）執(zhí)行框 （ 4）判別框 （ 5）進程框 （ 6）數(shù)據框 主要元素： （ 1）方框：表示一個處理步驟 （ 2）菱形框：表示一個邏輯條件 （ 3）箭頭：表示控制流向 軟件設計流程圖如下圖 22 圖 設計流程圖 23 軟件設計流程過程中的技巧 結構測試或白盒測試能有效地發(fā)現(xiàn)代碼中的邏輯、控制流、計算和數(shù)據錯誤。這項測試要求對軟件的內部工作能夠一覽無遺 (因此稱為 白盒 或 玻璃 盒)，以便了解軟件結構的詳細情況。它檢查每個條件表達式、數(shù)學操作、輸入和輸出。由于需要測試的細節(jié)眾多，結構測試每次檢查一個軟件單元，通常為一個函數(shù)或類。 代碼審查也使用與實現(xiàn)缺陷和潛在問題查找同樣復雜的技術。與白盒測試一樣，審查通常針對軟件的各個單元進行，因為一個有效的審查過程要求的是集中而詳盡的檢查。 與審查和白盒測試不同，功能測試或黑盒測試假設對軟件的實現(xiàn)一無所知，它測試由受控輸入所驅動的輸出。功能測試由測試人員或開發(fā)人員所編寫的測試過程組成，它們規(guī)定了一組特定程序輸入對應的預期程 序輸出。測試運行之后，測試人員將實際輸出與預期輸出進行比較，查找問題。黑盒測試可以有效地找出未能實現(xiàn)的需求、接口問題、性能問題和程序最常用功能中的錯誤。 雖然將這些技術結合起來可以找出隱藏在一個特定軟件程序中的大部分錯誤，但它們也有局限。代碼審查和白盒測試每次只針對一小部分代碼，忽視了系統(tǒng)的其它部分。黑盒測試通常將系統(tǒng)作為一個整體來處理，忽視了實現(xiàn)的細節(jié)。一些重要的問題只有在集中考察它們在整個系統(tǒng)內相互作用時的細節(jié)才能被發(fā)現(xiàn)；傳統(tǒng)的方法無法可靠地找出這些問題。必須整體地檢查軟件系統(tǒng)，查找具體問題的 特定原因。由于詳盡徹底地分析程序中的每個細節(jié)和它與代碼中所有其它部分之間的相互作用通常是不大可能的，因此分析應該針對程序中已 經知道可能導致問題的特定方面。本文將探討其中三個潛在的問題 領域： * 堆棧溢出 * 競爭條件 * 死鎖 讀者可在網上閱讀本文的第二部分，它將探討下列問題： * 時序問題 24 * 可重入條件 在采用多任務實時設計技術的系統(tǒng)中，以上所有問題都相當普遍。 處理器使用堆棧來存儲臨時變量、向被調函數(shù)傳遞參數(shù)、保存線程 “ 狀態(tài) ” ，等等。如果系統(tǒng)不使用虛擬內存 (換句話說，它不能將內存頁面轉移到 磁盤上以釋放內存空間供其它用途 )，堆棧將固定為產品出廠時的大小。如果由于某種原因堆棧越出了編程人員所分配的數(shù)量范圍，程序將變得不確定。這種不穩(wěn)定可能導致系統(tǒng)發(fā)生嚴重故障。因此，確保系統(tǒng)在最壞情況下能夠分配到足夠的堆棧至關重要。 確保永不發(fā)生堆棧溢出的唯一途徑就是分析代碼，確定程序在各種可能情況下的最大堆棧用量，然后檢查是否分配了足夠的堆棧。測試不大可能觸發(fā)特定的瞬時輸入組合進而導致系統(tǒng)出現(xiàn)最壞情況。 堆棧深度分析的概念比較簡單： 1. 為每個獨立的線程建立一棵調用樹。 2. 確定調用樹中每個函數(shù)的堆棧用量。 3. 檢查每棵調用樹，確定從樹根到外部 “ 樹葉 ” 的哪條調用路徑需要使用的堆棧最多。 4. 將每個獨立線程調用樹的最大堆棧用量相加。 5. 確定每個中斷優(yōu)先級內各中斷服務程序 (ISR)的最大堆棧用量并計算其總和。但是，如果 ISR 本身沒有堆棧而使用被中斷線程的堆棧，則應將 ISR 使用的最大堆棧數(shù)加到各線程堆棧之上。 6. 對于每個優(yōu)先級，加上中斷發(fā)生時用來保存處理器狀態(tài)的堆棧數(shù)。 RTOS，則加上 RTOS 自身內部 用途需要的最大堆棧數(shù) (與應用代碼引發(fā)的系統(tǒng)調用不同，后者已包含在步驟 2 中 )。 除此之外，還有兩個重要事項需要考慮。首先，僅僅從高級語言源代碼建立的調用樹很可能并不完善。大部分編譯器采用運行時庫 (runtime library)來優(yōu)化常用計算任務，如大值整數(shù)的乘除、浮點運算等，這些調用只在編譯器產生的匯編語言中才可見。運行時庫函數(shù)本身可能使用大量的堆?？臻g，在分析時必須將它們包括進去。如果使用的是 C++語言，則以下所有類型的函數(shù) (方法 )也都必須包含到調用樹內：結構器、析構器、重載運算符、復制結構器和轉換函數(shù)。所 25 有的函數(shù)指針也都必須進行解析，并且將它們調用的函數(shù)包含進分析之中。 第二，編譯器使用一個 C庫來實現(xiàn) memcpy()、 cos()和 atof ()等標準函數(shù)，而這些例程的源代碼可能無法得到。如果能夠得到它們的源代碼，就有可能確定程序用到的每個庫調用在最壞情況下的堆棧使用數(shù)量。如果這些庫只包含在目標文件中，則編譯器廠商必須提供每個庫例程使用的堆棧數(shù)。如果沒有這些信息，就無法通過分析來確定最壞情況下程序使用的最大堆棧數(shù)。幸運的是，許多面向嵌入式系統(tǒng)的編譯器廠商都提供這些信息。 通常，每次一個函數(shù)被調用時，編譯器將使用堆棧來保存返回地址并傳遞函數(shù)參數(shù)。函數(shù)的自動 (局部 )變量通常也在堆棧當中。不過，由于編譯器會盡可能通過將參數(shù)或局部變量放入寄存器來優(yōu)化代碼，因此檢查匯編語言以精確地確定堆棧用量非常重要。編譯器也有可能在代碼中的其它地方選擇使用堆棧，如用堆棧來保存中間計算結果。 有些與編譯器一起打包銷售的開發(fā)環(huán)境包含生成調用樹的工具，還有許多第三方的調用樹生成工具。但是，除非它們能夠對匯編語言進行分析，否則這些工具可能會遺漏運行時庫和 C 庫的調用。不過無論在哪種情況下，開發(fā)分析匯編語言文件并提取函數(shù)名稱以及各函數(shù)內部調用的腳本都比較簡單。分析的結果可寫入一個文件，而這 個文件能夠方便地輸入到表格之中。 確定了各個函數(shù)的堆棧用量之后，必須計算每個線程所需的最大堆棧數(shù)。由于一般程序通常涉及數(shù)百個函數(shù)，調用跨越多層深度，處理這些信息的一種簡便方法就是采用分析表格。如表 1 所示，表格的各行包含了函數(shù)名稱、該函數(shù)使用的最大堆棧數(shù) (包括調用其它函數(shù)所需的堆棧數(shù) )，以及它調用的所有函數(shù)的清單。通過編程控制，這個表格從每個函數(shù)的 根 開始迭代循環(huán)，計算該函數(shù)及其調用的所有函數(shù)需要的堆棧。這些信息存放在堆棧路徑列中，這樣，采用每個線程根函數(shù) (如 main)的堆棧路徑數(shù)據就可以方便地計 算出需要的最大堆棧數(shù)了。這個過程包含了先前介紹的堆棧分析過程中的前四個步驟。 有時候，采用堆棧深度分析過程可能是無法做到，或者是不實際的。如果無法得到運行時庫或 C庫的源代碼，而編譯器廠商又沒有提供任何堆棧使用信息，就不可能進行完整的堆棧分析。在這種情況下，有兩種選擇： 1. 在測試期間，觀察堆棧所能達到的深度，并保證有較大的堆棧空間余量。 26 2. 檢測堆棧溢出，并采取改進措施。 觀察堆棧深度的方法很簡單 : * 向整個內存堆棧區(qū)寫入一個特定的數(shù)據圖案符號，如 55AA。 * 在預期使用最大堆?？臻g的條件下運行系統(tǒng)。 * 使用仿真器或其它工具檢查堆棧存儲區(qū)，看有多少符號圖案由于堆棧的使用而被改寫了。 當然，這些步驟并不能保證在一些不同條件下不會需要更多的堆棧，但確實可以表明所需要的最小堆棧數(shù)。 使用帶內存管理單元 (MMU)的處理器時，有可能檢測出運行時的堆棧溢出現(xiàn)象。 MMU 將內存劃分為多個區(qū)域，用一個受保護的內存段來 “ 警戒 ” 堆棧區(qū)域。發(fā)生堆棧溢出時，處理器將訪問這個受保護段。這個操作將引發(fā)一個異常事件 (如產生 SIGSEGV 信號 )， 可被程序捕獲到。創(chuàng)建線程時，與實時 POSIX 標準兼容的RTOS 提供有這種堆棧警戒功能選項，大大簡化了編程人員的工作。 GNU 工具等其它開發(fā)環(huán)境包含有編譯器開關，可在程序中添加實現(xiàn)堆棧警戒功能所需的代碼，但它們仍然依靠底層操作系統(tǒng)來有效地處理堆棧溢出。但是，按照這種方式檢測溢出還只是問題的一部分。為了使這類設計更為有效，系統(tǒng)必須能夠從堆棧溢出中恢復過來并繼續(xù)正確地工作。 在一個對安全或任務要求嚴格的應用中，系統(tǒng)運行時在測試或檢測堆棧溢出期間監(jiān)視堆棧的深度可能并不是一項足夠的風險控制措施。對于一些應用， 必須確保系統(tǒng)絕對不會越出所分配的堆棧范圍；只有通過完整的堆棧深度分析才能證明這一點。這意味著，如果整個程序在同一內存空間運行，則必須對所有代碼執(zhí)行這項分析。不過，如果使用 MMU，分析常可簡化。在設計系統(tǒng)時，可將所有關鍵代碼置于一個或多個獨立線程內，而這些線程分別在各自的保護內存段中運行。這樣，只要對這些關鍵線程進行堆棧使用分析就可以了。當然，這項簡化設計假定當非關鍵線程溢出其堆棧并失效時，關鍵線程仍可正確執(zhí)行。 由于分析工作所需的堆棧使用數(shù)據來自匯編語言清單，因此修改代碼時，相應模塊的堆棧使用信息 必須予以更新。如果使用不同的編譯器版本，或者改變了優(yōu)化設置，也必須復核整個分析過程。在理想情況下，編譯器將提供每個函數(shù) (如果不是每個線程的話 )的堆棧使用數(shù)量，因為它擁有計算需要的所有信息。例如， 27 瑞薩公司提供有 Call Walker，這是該公司高性能的 Embedded Workshop 開發(fā)環(huán)境的一部分。這個工具可以圖形化地顯示每個函數(shù)使用的調用樹和堆棧，包括運行時庫和 C庫的函數(shù)。 Call Walker 也能找出使用堆棧數(shù)量最大的路徑。使用這樣的工具可以實現(xiàn)步驟 1到步驟 3的自動化。 競爭條件 當兩個或更多獨立線程同時訪問同一資源時，就出現(xiàn)了競爭條件。競爭條件的影響多種多樣，取決于具體的情況。清單 1解釋了一個潛在的競爭條件。函數(shù)Update_Sensor()通過調用 get_raw()來讀取傳感器的原始數(shù)據。在處理過程中，該數(shù)據被乘上一個定標因子，并加上一個偏移量。處理是在該數(shù)據的一個臨時副本上進行的，然后，該臨時副本被寫入共享變量。 如果在數(shù)據寫入之前，使用 shared_sensor的另一個線程或 ISR先 (preempt)了這個線程，它將得到原來的傳感器讀數(shù)。使用臨時副本可以防止先占線程 讀取只經過部分處理的數(shù)據。不過，如果這些代碼在一個數(shù)據總線不足 32 位的處理器上運行，就會存在競爭條件。 在一個 8 位或 16位的處理器上，向 shared_sensor 的寫入操作并不是一次性完成的。在 8位處理器上，寫入 32 位浮點值可能需要四條指令，在 16位處理器上可能需要兩條指令。如果在對 shared_sensor 進行連續(xù)寫入中途Update_Sensor()被先占，則先占線程將從由一部分老數(shù)據和一部分新數(shù)據組成的 shared_sensor 讀取一個數(shù)值。根據應用的具體情況，這有可能造成嚴重的后果。解決的 辦法是鎖定調度程序，或在更新共享變量期間禁止中斷。 消除競爭條件通常很簡單，但找出隱藏在代碼中的競爭條件則需要仔細的分析。 對于由一個循環(huán)程序和不同 ISR 組成的簡單系統(tǒng)，分析競爭條件很簡單，只需檢查每個 ISR 并識別它引用的所有共享變量。共享變量通常是這些系統(tǒng)中的全局數(shù)據，一旦這些共享變量被找出來之后，就可以檢查它們在代碼中的各次使用情況。每次訪問都必須按需要進行保護，以避免潛在的沖突。在簡單設計中，一般通過在關鍵代碼段周圍禁止中斷來實現(xiàn)保護。遵守下列規(guī)則可幫助避免競爭問題： * 如果一個 ISR 對共享數(shù)據進行寫入，則該 ISR 之外的每次可中斷的讀操作 28 都必須予以保護。 * 如果一個 ISR 對共享數(shù)據進行寫入，則該 ISR 之外的任何讀－修－寫操作都必須予以保護。 * 如果一個 ISR 讀取共享數(shù)據，則對該數(shù)據的可中斷寫操作必須予以保護。 * 如果一個 ISR 和其它代碼都要檢查一個硬件狀態(tài)標志，以便在使用某資源之前確定其可用性，如： if (!resource_busy) { // Use resource } 則從檢查標志之時開始，到硬件設置標志表示資源不可用為止，必須采取保護措施。 對于使用了優(yōu)先級不同的多個線程的更為復雜的系統(tǒng)，其分析也非常相似。上述規(guī)則仍然適用于 ISR 使用的所有數(shù)據。此外，還必須識別出每個線程使用的共享數(shù)據。首先從系統(tǒng)中優(yōu)先級最高的線程開始，找出它與任何優(yōu)先級較低的線程共享的所有數(shù)據，然后按照上述四條規(guī)則進行保護。對于軟件使用的其它每個優(yōu)先級，再重復這一過程。 注意，如果系統(tǒng)采用了一種循環(huán)調度算法，則特定優(yōu)先級內的所有線程可在任意時刻相互先占。這意味著前述四條分析 規(guī)則在考慮較低優(yōu)先級的線程之外，還必須考慮同一優(yōu)先級的所有線程。 多線程系統(tǒng)通常使用某種類型的操作系統(tǒng)，它能夠提供多種保護選擇。可以使用互斥或信號量，或者鎖定調度器。有時也可使用其它進程間通信 (IPC)基本技術：通過向消息隊列發(fā)送消息 (而非修改共享變量 )來表示數(shù)據已經改變。在許多情況下，最好由單一線程來管理共享資源，它負責處