調試與設計一樣是嵌入式系統(tǒng)不可或缺的一部分。兩者都可以正確地稱為同一枚硬幣的兩個面。考慮到物聯網領域嵌入式系統(tǒng)的最新發(fā)展，工程師在調試和設計方面同樣出色是一個優(yōu)勢。如今，嵌入式系統(tǒng)變得非常復雜，軟件和硬件的界限正在融合。因此，當系統(tǒng)級別出現問題時，很難找出根本原因。作為從事嵌入式系統(tǒng)工作的工程師，我們必須快速了解問題并找到根本原因。

下面提到的一些技巧可以幫助開發(fā)一種邏輯方法和分析思維來解決嵌入式系統(tǒng)問題。本文不涉及用于調試的工具，而是向讀者展示了一種經過驗證的方法來解決問題。

嵌入式系統(tǒng)由硬件、固件和應用軟件組成。有時，當報告問題時，不清楚系統(tǒng)中存在問題的位置。這可能是由于硬件、固件代碼或應用軟件造成的。下面是一個通用圖，顯示了嵌入式系統(tǒng)的基礎知識以及從一個系統(tǒng)到另一個系統(tǒng)的數據流方向。

下面列出了有關如何繼續(xù)調試問題的分步方法。為了說明該方法，我們考慮了在嵌入式系統(tǒng)上看到的視頻顯示問題的示例。

第 1 步 – 了解設置并正確重現問題

需要做的第一件事就是正確地重現問題。有時問題是在本地看到的，工程師能夠輕松地重現問題。而有時問題出現在遠程位置或客戶站點，然后工程師必須完全依賴可用的日志來了解設置并重現問題。在第二種情況下，工程師正確理解設置非常重要，因為這將有助于成功重現問題。如果工程師沒有這樣做，那么問題可能會在未來在遠程位置或客戶站點再次發(fā)生。這主要是因為工程師可能沒有正確理解問題，因此沒有開發(fā)出正確的解決方案。因此，它將導致修復問題的多次迭代。

對于我們的示例，讓我們考慮僅在某些監(jiān)視器上看到噪聲的視頻顯示器。由于設備安裝在遠程位置，因此只有視頻日志可用于調試。從日志中很難找出噪音的根本原因。最初我們嘗試播放不同的剪輯，但最終無法重現該問題。我們不確定為什么該問題無法重現。我們無法清楚地判斷這是由于使用的視頻文件還是由于設置。最后，我們能夠通過獲得與客戶使用的完全相同的剪輯和其中一臺顯示器來重現該問題。

第 2 步 – 將問題分解為更小的問題

一旦問題被正確重現，下一步就是將整個問題分解為更小的問題。這非常重要，可以通過了解整個數據流來完成。第一步是在應用層與固件層以及固件層與硬件層的接口處中斷數據流。這樣，每一層都可以針對任何問題進行獨立審查和測試。此外，我們不必止步于此，可以根據邏輯理解將整個數據流路徑分解為更多的子層次。

對于我們的示例，我們將視頻幀數據從應用程序到硬件層的整個路徑進行了劃分。我們了解了如何接收編碼的視頻數據然后解碼的整個路徑，然后將其傳遞到固件層。在這里，我們了解了如何為每個視頻幀分配指針，以及固件如何給出它們以通過硬件層發(fā)送每個幀。在硬件層，我們了解了視頻幀如何在物理線路上發(fā)送出去的協議。一旦我們了解了整個路徑，我們就將其劃分為邏輯塊。一個塊用于應用層，其中編碼的視頻數據被解碼為原始視頻并存儲在視頻緩沖區(qū)中。然后另一個塊是固件層，我們檢查視頻緩沖區(qū)是如何分配給硬件的。

第 3 步 - 修復每個較小的問題

一旦我們將整個數據路徑分解為每一層的邏輯塊，我們需要單獨測試每個塊并以各自的方式對其進行驗證。這將有助于找到問題的根本原因所在。有時系統(tǒng)問題可以通過僅更改一層來解決，而有時則需要更改不止一層。通過在邏輯上打破整條路徑，我們可以正確地找出需要所有更改的地方，然后相應地修復它們。

對于我們的示例，在應用層，我們使用讀取和寫入文件來驗證數據路徑流。將解碼后生成的視頻數據緩沖區(qū)與預期值進行比較。在固件級別，使用固定模式作為數據輸入，而不是來自應用層的數據。在這里，我們觀察到視頻數據以場而非幀的形式提供給固件層，但場信息（頂部或底部）未正確地從應用層提供給固件層。所以我們必須相應地修改代碼，以便緩沖區(qū)包含正確的字段信息。

在硬件級別，這些固定模式和接口的相應控制信號使用邏輯分析儀按照規(guī)范進行了驗證。對于我們的示例，我們使用的協議是 BT.1120，我們看到協議時序不符合規(guī)范。所以我們意識到這就是為什么有些顯示器可以正常工作而其他顯示器不能正常工作的原因。一旦我們按照規(guī)范制定了協議，我們就會看到所有監(jiān)視器都正常工作。我們還意識到，整個噪聲問題實際上是錯誤的字段信息和錯誤的協議時序的組合。這就是為什么一些顯示器能夠工作而其他顯示器不能工作的原因。

第 4 步 - 負面測試

測試當然是解決問題的一個非常重要的方面，重要的是測試問題是否已正確修復并且不應該再次出現。因此，重要的是我們在解決問題后進行負面測試以及通常的測試。負面測試基本上意味著確保問題被強制進入系統(tǒng)，然后根據設計的解決方案驗證系統(tǒng)的響應。這基本上意味著，如果我們通過提供正確的輸入從系統(tǒng)中得到錯誤的輸出并且我們想出了一個解決方案，那么我們應該能夠生成錯誤的輸入并饋送到系統(tǒng)，以便它生成正確的輸出. 如果發(fā)生這種情況，則意味著正確識別了根本原因并驗證了修復。

對于我們的示例，我們測試了以下方式。對于協議時序，我們看到在按照規(guī)范制作之后，所有的監(jiān)視器都出現了噪音問題。即使對規(guī)范稍作修改，也會導致監(jiān)視器的行為發(fā)生變化。這證實了硬件層錯誤的協議時序是監(jiān)視器行為不同的根本原因。接下來，對于我們看到問題的監(jiān)視器，我們有意交換了應用層的頂部和底部字段。然后我們看到問題沒有發(fā)生。這證實了不正確的頂部和底部字段指針是噪聲問題的根本原因。通過這種方式，我們測試了該解決方案實際上解決了根本原因，并且它在應用程序和硬件層都包含了一個修復程序。

通過使用上述步驟，可以以更好的方式解決任何問題。
?