這篇文章是咬牙堅持寫的，目標是讓你能看懂，寫完發現的確是很難懂，全是我的錯，其實錄個視頻講一講可能就明白了(后面一定補上，我保證。。。)，關于軟件追蹤，可能是我們在研發階段中最重要的收尾環節，希望這篇文章像一粒種子一樣，種在你的小腦袋瓜里，不求看懂，大體知道還有這么一個玩意兒，等你真正想要應用它到你的項目當中時，我強烈建議你點個收藏，memeda,下面開啟復雜難懂的正文。

      軟件追蹤其實最重要的并不是如何移植，這個相對來講比較簡單，最重要的是如何在目標板你需要的追蹤內容，并根據輸出的最終記錄分析你的系統動態運行的軌跡，看看是否符合你的狀態機圖設計，確保程序的健壯性。建議先往后拉，文章的末尾有這個軟件demo的狀態圖，設計的原圖，有點本末倒置，見諒，大體有個數，然后再繼續我們的講解。

      這里如何通過軟件追蹤記錄來分析軟件的執行流程，正常來講其實應該先講一下，這個軟件大概的一個功能，有了大體的理解以后再去講追蹤記錄，這里我想嘗試一下在不了解這個軟件功能的情況下，對比源代碼來看一下軟件執行流程。進一步了解狀態機的狀態遷移及執行流程。

      1.初始化記錄，bsp.c文件中相關的記錄與源代碼對應：

   2.初始化記錄，Philo.c文件中相關記錄與源代碼對應：

===RTC===> St-Init  (完成了狀態機的init初始化，RTC的意思是，運行到完成，可理解為連續執行，后面的->Philo_thinking為狀態轉換，也是就是執行Q_TRAN的目標狀態)，狀態機在進行狀態轉換的時候，到目標狀態，要執行目標狀態的進入處理。

    3. 初始化記錄，Philo.c文件中相關記錄與源代碼對應：

      下面進行關鍵部分的分析，就是這個軟件是怎么跑起來的，這是事件驅動型的系統，所以有輸入的部分，才會激活這個系統，例如系統定時發送一個事件給目標對象：

      目標對象接收事件追蹤記錄：

      接下來我們根據記錄，找到源代碼，看看這個狀態處理函數，如何處理這個事件，然后按照我們的執行流程去對比追蹤記錄的反饋，看看是否一致？狀態處理函數如下：

到這里程序運轉的流程基本上從源代碼的方向分析完了，接下來對比一下QSPY的追蹤記錄是否吻合，先貼出這塊的追蹤記錄，再逐條分析一下，看看狀態到底是不是這樣轉換的。

整個系統執行反饋的記錄完美的與我們程序設計的轉換執行路線相同，確定軟件是我們設計的運行軌跡進行狀態轉換的。到這里整篇軟件追蹤就結束了，有興趣的同學可以研究研究原文，在對照我做的分析做下參考。最后送上我們的QM生成的狀態圖，其實我們的代碼都是這個QM狀態圖自動生成的，只是部分內容我們自己填寫，如下：