關(guān)于利用Simulink模型自動生成C代碼的相關(guān)研究和分析

Simulink 模型的自動代碼生成？

簡單來說，在我們的 “大” 項目中，需要實現(xiàn)很多算法，其中比如 myfilter。

現(xiàn)在不手寫C了，而是搭建Simulink框圖。對那些算法比C語法熟悉的人來說，這是個福音。

算法實現(xiàn)方便，測試方便

Simulink 模型的測試驗證非常重要，然而這里不討論。

總之，算法沒問題之后，通過自定代碼生成工具Coder“翻譯”成C代碼，跟手寫的一樣.c.h，還可以控制函數(shù)原型、數(shù)據(jù)定義、文件結(jié)構(gòu)、甚至注釋......

把自動生成的源文件集成到原來的項目文件中。

由各種編譯器，把它們編譯成不同的可執(zhí)行文件，最后運行在不同的環(huán)境。

比如這里就是通過 VS 編譯成 exe，很簡單吧。

所以

對于代碼生成的任務來說

重點在如何生成自己想要的C代碼

但經(jīng)常會有人問，Coder支持哪些板子？

看下面這張嵌入式軟件的偽代碼的簡單示意圖。

Simulink 算法模型通過 Coder 生成的是藍色部分，標準C；跟硬件打交道的底層驅(qū)動黑色部分，是手寫代碼。

既然叫Coder，所以本質(zhì)上，它的本職工作就是Simulink模型到C代碼這個步驟，就結(jié)束了。至于C要通過什么編譯器跑到什么硬件上，跟Coder沒多大關(guān)系。

那么

為什么會有人問這個問題呢？

Build Process

Coder除了把模型翻譯成代碼的本職工作以外，還額外張羅了一些Build的任務，把C代碼變成可執(zhí)行文件。

為什么說張羅，而不說完成呢，因為Coder本身并沒有編譯的功能，它會后臺調(diào)用你安裝了的編譯器來實現(xiàn) ，看下圖。

比如默認下，Coder會調(diào)用VC，使用它內(nèi)置的相應的main文件模板，然后編譯。這就是為什么每次生成代碼，在當前目錄下就會 “莫名其妙” 的生成一個exe程序。如果你不喜歡，那也可以 “Generate code only”。

如果是上面沒列的編譯器，自己也可以把它集成進來，比如構(gòu)造個Template makefile，描述怎么編譯鏈接變成可執(zhí)行文件。

好像還是沒解釋所謂硬件支持的問題？

I/O Drive blocks

剛才說的是后臺可以調(diào)用編譯器，構(gòu)造main文件，生成了可執(zhí)行文件，下載到硬件。

在很久很久以前，代碼生成工具為一些板卡提供了I/O驅(qū)動模塊庫，TIC2000/5000/6000，等等。

然后可以做什么？

看下面這張圖，兩端的In/Out就換成圖中的硬件驅(qū)動模塊。舉例的板卡的驅(qū)動庫我沒裝，暫時拿Arduino的庫示意一下，提供了很多下圖中紅框類似的模塊。

那么，中間用Simulink/Stateflow搭好算法，兩頭的輸入輸出端口連接上這些硬件驅(qū)動模塊，后臺又做好了編譯工具鏈的支持，就可以實現(xiàn)傳說中的支持某款硬件：一鍵下載到硬件上運行了。

如果使用這種方式來開發(fā)產(chǎn)品，這樣看上去感覺真的很美好~

但是，目測，要做的額外的工作也非常多，所有的要用到的驅(qū)動都需要包裹成Simulink Block的形式，要自動生成所需要的main文件，等等，這也是不小的工作量。

做產(chǎn)品開發(fā)，使用哪種 “集成” 方式，仁者見仁。

現(xiàn)在就Coder工具來說，這部分 “對硬件的支持” 從Coder里剝離了，變成了免費的Hardware Support Package下載。用來做做算法的原型測試也不錯。

另一個經(jīng)常會問的問題：

代碼生成工具的效率怎么樣？

雖然Coder習慣叫代碼生成工具，但它實際上是個代碼翻譯工具，把Simulink模型“翻譯”成C代碼。

其實就跟金山詞霸，谷歌翻譯一樣，基于你寫的中文翻譯成英文。

“今日天朗氣清，看似極好的日子，私心想若能約上三五好友，結(jié)伴出游，陶冶性情，便是再好不過了。”

再厲害的谷歌翻譯，也翻譯不出這句人話：“今天不想上班。”

所以對于Coder來說，也是一樣，它的目標是C代碼如實的反映出你搭建的Simulink模型結(jié)構(gòu)所表達的信息。在考慮生成的C代碼效率如何時，也不能忽略Simulink模型搭建的效率如何？

Simulink Coder生成的C代碼主要用于加速桌面仿真、快速原型、以及HIL測試(被控對象模型也要生成C代碼)。Embedded Coder提供了更多的自定義的途徑，生成高效率的嵌入式C代碼。

但其實，對于我們用戶來說，這些Coder都是 “看不見” 的，沒有所謂打開Embedded Coder工具箱的說法。

我們只需要關(guān)心選擇哪一個系統(tǒng)目標文件(System tareget file)。罷了，下圖?！盁o責任瞎猜一句”，為什么這些后綴名是.tlc呢？因為Coder里面干翻譯這個活的叫TargetLanguageCompiler。

紅框外的.tlc只是針對各自不同的目標稍作了些修改，完成一些額外的事。比如ert_shrlib.tlc，多做了一個工作，把生成的.c.h變成.dll。

這一個小節(jié)說人話就是：選擇ert.tlc。

如果對于一些小算法你有什么高效率的實現(xiàn)，也可以添加進來。比如說查表，比說說針對某個特殊器件的四則運算，到時候Coder就會替換你的實現(xiàn)方式。

當然，一些通用的提高代碼效率的方法，還是可以試試。讓 Coder 基于它的 “經(jīng)驗”，給你一些通用的建議：

所以，對于代碼生成的任務來說，除了選擇ert.tlc，點個按鈕之外，再考慮下數(shù)據(jù)管理、代碼結(jié)構(gòu)、文件結(jié)構(gòu)......