完整的S32K144的學習彙總如下：
https://github.com/GreyZhang/g_s32k144
以前的學習筆記寫起來，都有一種整理測試記錄或者調試記錄的感覺。我覺得其實這樣雖然簡明扼要，但是總是少了一種生活的味道。或許，以後把我的學習筆記寫得更加生活化一點會更有意思。至於學習中的幾個要點，只要是筆記的內容夠短總能快速提取出來。
今天的學習筆記說起來有一點點故事性，這得從我對printf的好感建立說起。工作了大概三四年後，我依然麼有對printf有什麼好感。或許，這個跟我從事的行業有關。我做的汽車電子嵌入式，更多時候是依賴調試器。我對於printf的好感其實還是來自於我業餘的自我能力提升，尤其是當我在一篇文章中看到了ken老爺子的軟件調試方式之後。Ken老爺子不喜歡週期超過一個月的項目，在進行軟件設計的時候先把接口全都寫完，軟件還完成就直接先啓動聯調測試。而整個開發調試過程中，ken老爺子需要的只是一個文本編輯器和printf。突然間，我似乎靈光一點，瞬間有所頓悟。其實，只要有一個方便的監控方式，很多調試其實都很容易。自此，我喜歡上了printf。
然而，回到我自己從事的行業，這個實現卻有一點點費勁了。在汽車電子領域，主控單元中基本上沒有串口，而我們見到的大多數的printf要麼通過串口要麼通過調試器所謂的半主機模式。這個，在我接觸的項目中都絕少存在。相比之下，我們用的更多的是調試器以及CAN，基於CAN會派生出大量的監控手段。一定程度上來說，我們的問題得到了解決。但是，CAN派生出來的大量的軟硬件工具都價值不菲，尤其不適合個人學習使用。即便是公司，很多時候也沒有實力大批量採購。這時候，其實還有一個簡單的方案：基於CAN做一個printf打印工具。如果有了這麼一個想法，實現起來還是很容易的。尤其是如果我們基於CAN卡做過上位機開發的時候，我們只需要定義簡單的規則，實現一個上位機的解析即可。不過，對於大多數的嵌入式工程師來說，學習成本略高。
那麼，還有沒有其他的解決方案呢？其實，解決方案還是有的，哪怕是一種純粹的嵌入式的解決方案。既然，通過串口能夠輕鬆實現printf，那麼，我們實現一個CAN到串口的轉換，一切不就很簡單了嗎？這個功能，其實我已經在Arduino的平臺上實現了，通過Arduino + MCP2515就可以輕鬆實現。相比之下，S32K144是否可以做到呢？當然可以，而且有更大的優勢。因爲，CAN以及串口在這個板子上都是已經集成好了的，我們不需要額外擴展硬件模塊。至於printf的實現，方式很多種，我自己採用的方式是放棄標準庫接口修改，採用一個獨立的代碼實現。有很多開源的代碼可以參考，我們只需要實現一個簡單的putc函數就可以完成整個功能。
由於串口以及CAN的速度，我們的printf函數實現有時候會覺得性能稍弱，尤其是粗暴的實現不做任何優化的情況下。其實，我自己到覺得這完全不是問題，printf的目的不是爲了性能而存在的更多時候我們需要的是滿足我們眼睛觀察的需要。其實，我個人覺得每秒能夠按順序輸出100個字節的速度完全足夠我們調試90%以上的軟件。
這樣，我們就可以在ECU中，putc完全定製爲一個CAN的字節發送就完成了ECU的printf功能。S32K144 EVB的作用在哪裏呢？它的作用自然是提供CAN printf打印內容的一個解析。大致的數據流如下：
ECU à CAN printf à CAN bus à S32K144 CAN receive à S32K144 UART transmit à 電腦顯示。
看上去費勁，但是一次定製之後這個就可以固化爲一個常用的工具存在。我做一個簡單的實現如下：
當接收到的CAN報文ID是我的ECU printf CAN ID，那麼，我把數據場的信息打印出來。接下來，我使用上位機做一個ECU打印的模擬。
打印的輸入內容是ASCII碼的字符，因此，我的串口應該可以打印出一個預期的字符串。
調試的時候，成功打印出來了“helloCAN”的字符串。機制的測試基本成功，在實際的使用中，尤其是ECU還是有一定的細節處理。這部分實現其實相對容易，在這裏就不做介紹了。
“世界上並不缺少美，只是缺少發現美的眼睛”。世界上也沒有調試不了的BUG，大多數時候是我們沒有看到足夠多的信息。我希望這個簡單的printf能夠爲看到我學習自己的你，提供一雙更加犀利的眼睛！
完整的S32K144的學習彙總如下：