下面提到的一些技巧可以幫助開發一種解決嵌入式系統問題的邏輯方法和分析思維。

嵌入式系統由硬件、固件和應用軟件組成。有時，當報告問題時，并不清楚問題出現在系統中的什么位置。這可能是由于硬件、固件代碼或應用軟件。

步驟1-了解設置并正確重現問題

首先，我們需要做的是正確再現問題。有時問題是在本地看到的，工程師能夠很容易地重現問題。然而，有時問題是在遠程位置或客戶現場發現的，工程師不得不完全依靠可用的日志來了解設置和重現問題。在第二種情況下，工程師正確理解設置非常重要，因為這將有助于成功重現問題。如果工程師未能做到這一點，那么將來該問題可能會在遠程位置或客戶現場再次出現。這主要是因為工程師可能沒有正確理解問題，因此沒有制定正確的解決方案。因此，這將導致修復問題的多次迭代。

對于我們的例子，讓我們考慮一個視頻顯示器，其中噪聲只出現在某些監視器上。因為設備安裝在遠程位置，所以只有視頻日志可用于調試。從日志中很難找出噪音的根本原因。最初，我們嘗試使用不同的剪輯，但無法在我們這邊重現問題。在嵌入式開發中，我們不確定為什么問題無法重現。我們不清楚這是由于使用的視頻文件還是由于設置。最后，我們通過使用與客戶使用的完全相同的夾子和一臺顯示器重現了問題。

第2步-將問題分成更小的問題

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

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

步驟3–解決每個較小的問題

一旦我們將整個數據路徑分成每一層的邏輯塊，我們需要單獨測試每個塊，并以各自的方式進行驗證。在嵌入式開發中，這將有助于找到問題的根源所在。有時一個系統問題可以通過只改變一層來解決，而有時需要改變不止一層。通過在邏輯上斷開整個路徑，我們可以正確地找到所有需要更改的地方，然后相應地修復它們。

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

在硬件層面，使用邏輯分析儀按照規范驗證這些固定模式和接口的相應控制信號。在我們的例子中，我們使用的協議是BT.1120，我們發現協議計時不符合規范。所以我們意識到這就是為什么有些顯示器工作正常而有些不正常的原因。一旦我們按照規范制定了協議，我們看到所有的監視器都工作正常。我們還意識到，噪聲的整個問題實際上是錯誤的字段信息和錯誤的協議計時的組合。這就是為什么一些顯示器能夠工作而另一些不能工作的原因。

第4步-消極測試

測試當然是解決問題的一個非常重要的方面，重要的是測試問題是否得到了正確的解決并且不會再出現。因此，在修復問題后，我們在進行常規測試的同時進行負面測試是非常重要的。消極測試基本上意味著確保問題被強加到系統中，然后按照設計的解決方案驗證系統的響應。在嵌入式開發中，這基本上意味著，如果我們通過給出正確的輸入從系統得到錯誤的輸出，并且我們想出了一個解決方案，那么我們應該能夠產生一個錯誤的輸入并饋送給系統，以便它將產生正確的輸出。如果發生這種情況，這意味著根本原因已被正確識別，修復已得到驗證。

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

通過使用上述步驟，在嵌入式開發中，任何問題都可以以更好的方式解決。