你們自動生成的代碼都支持哪些MCU？

這是這幾年最經常被問到的幾個問題之一了，我向來的回答是：

代碼生成工具生成的是標準C代碼，支持所有的MCU或者DSP。

既然答案如此明確，干嘛還要來寫這篇文章？

回答問題前，我們先看看為什么會有這么多人提及這個問題。

M曾經的Target Support Package

我敢說很多人提到這個問題是因為MATLAB曾經有一個的工具箱，叫做Target Support Package，簡稱TSP，這個產品從MATLAB R2011a開始不再單獨銷售。不過，對于習慣了汽車行業這種嵌入式軟件開發的工程師，這些支持包，可能只能用作過家家了，因為汽車行業的軟件是下面這個樣子的：

即便是我們不使用AUTOSAR架構，差別也主要在于是否有RTE上，其他的部分該有的都會有的。

我們再來看一下TSP這個工具包有什么功能，下面這幅圖是MATLAB R2012b里面TI C2000的TSP模塊庫：

這個模塊庫里有AD、有數字IO，有PWM輸出，有比較寄存器，還有各類通信端口的收發模塊等等，我們可以假想有這樣一個模型：

模型中，AD模塊有了，在生成的代碼中，有讀取AD轉換數據的C接口函數，AD轉換得到的數據經過Algorithm部分的運算，獲得期望的PWM輸出信號的占空比，后面的PWM模塊會根據這個占空比的數值產生PWM信號。

看起來好像非常不錯的樣子，不過我們想，就AD轉換或者PWM輸出這類底層驅動軟件，對于一個做單片機的工程師來講，這點工作量并不大，并且，對于同一款單片機，最底層的驅動軟件通常非常穩定，不會像應用層軟件那樣需要頻繁變更。

也就是說，TSP給我們節省的時間非常有限。

時間上不能節省太多倒還不是最大的問題。最大的問題是，這部分軟件在Simulink環境下沒法仿真，如果架構設計不好，這會直接導致整個模型的可驗證性變差。

如果為了節省那么一點微不足道的時間，而導致整個模型的可驗證性變差，得不償失。

另外，還有不少客戶試圖自己開發TSP，這往往連節省微不足道的時間的好處都沒了，因為開發TSP也算得上對Simulink做深度定制了，通常需要用戶熟悉TLC編程，熟悉S-Function，并且，無論是TLC還是S-Function都沒有便利的調試環境，這對于開發以及后期維護TSP都帶來了非常大的困難。

所以，我對Simulink模型設計的建議是：

能在Simulink環境下仿真的部分，可以通過Simulink實現，對于單片機底層這類沒法在Simulink下仿真的軟件，不應該打包到Simulink環境下。

MTSP是否一無是處？

前面我們說過，這個工具從2011年開始已經不再單獨銷售，但并未壽終正寢。最新版的MATLAB的標準產品中已經看不到這個產品，不過，如果你一定要找，還是可以通過添加硬件支持包的方式找到各式各樣的硬件支持包，并且相對以前的TSP，硬件支持包不僅提供了很多MCU的驅動模塊，而且還提供了很多熱門硬件的支持，比如Arduino，Raspberry Pi等，如下圖示：

對于完全沒有嵌入式軟件開發經驗的大、中學生或者工程師，如果想做嵌入式系統上實現某些算法，而又沒有精力去學習嵌入式系統，的確可以借助TSP，通過Simulink實現算法，并最快的做目標處理器上驗證這些算法，這也是不錯的選擇。

但是對于產品開發，TSP在很多行業是行不通的。

M不該有的誤解

或許因為TSP的存在，讓很多人產生如下誤解：

MATLAB沒提供TSP的單片機就等于MATLAB代碼生成不支持這款單片機

基于模型的嵌入式軟件設計一定要有TSP作為支持，沒有TSP支持，就沒法進行基于模型的嵌入式軟件設計

這兩種誤解是沒有道理的，我們應該參照AUTOSAR架構，做應用層軟件開發或者策略實現部分的模型開發中使用模型。

如果我們仔細觀察一下AUTOSAR的軟件架構，我們發現，基礎軟件部分，除了MCAL層之外，還有ECU 抽象層、協議棧、操作系統等基礎軟件，并且這部分軟件遠比MCAL復雜，如果使用TSP，基礎軟件中除了MCAL之外的軟件怎么實現？這是一個問題，不需要答案，只為更加明確TSP做汽車電子產品軟件開發中沒有價值。