RTCSD2017-3

應屆畢業生須要掌握的能力

如下僅爲我的觀點，歡迎討論

1. 必要能力

1.1. 編程能力

做爲一個程序猿，怎麼能不會寫代碼呢。徹底掌握一門語言是關鍵。
並且不只要會寫，還要寫得好，好比代碼規範，debug。

1.2. 學習能力

現在的技術一天一個樣，若是沒有必定的學習能力，很快就會被時代所淘汰。
只有活到老，學到老才能跟上時代的步伐。

1.3. 自行解決問題的能力

不要遇到問題就處處問人，不如先問問神奇海螺百度。百度不知道，再問問google。
另外，一些官方的文檔，源碼也是尋找答案的好地方。

1.4. 與人溝通的能力

團隊協做總要與人溝通，遇到真的解決不了的問題也要與人溝通。說話方式我就不說了，我也不是很懂。
有一點很關鍵：
必定不要在聊天時直接粘貼代碼。
必定不要在聊天時直接粘貼代碼。
必定不要在聊天時直接粘貼代碼。
這樣真的很影響閱讀！（通常狀況下公司代碼是不容許外傳的）
若是須要傳遞代碼，要麼截圖，要麼上傳到Ubuntu Paste
（我就知道這個，其餘能夠貼代碼的網站還有不少）

2. 可選能力

2.1. 熟悉某種或多種MCU

主流的MCU，如ARM，AVR，MSP（我就知道這麼幾個，歡迎打臉）多少要了解。
雖然如今ARM框架盛行，尤爲是STM32系列。感受到了M4以上，基本都知足要求。
是否是我見識太淺了。

2.2. 熟悉周圍電路和經常使用芯片

寫硬件必需要與周圍電路和經常使用芯片打交道，能看懂是第一階段。
若是能照搬着用是第二階段，若是能自主設計或者改良就是第三階段了。

2.3. 熟悉某種或多種RTOS

因爲任務愈來愈複雜，各個任務之間數據同步，愈來愈複雜，MCU的結構也愈來愈複雜。
就須要RTOS來幫忙進行任務調度，不管是輕量級的FreeRTOS等等，重量級的實時Linux。都是不錯的選擇。

3. 加分能力

3.1. 熟悉經常使用的數據結構

因爲任務愈來愈複雜，單單用數組，指針已經不能知足咱們的要求，須要一些數據結構來支撐整個任務。
若是會用一些經常使用的數據結構，好比棧，隊列，哈希表等等。會大大縮短任務的執行時間（下降時間複雜度）。
並且，也能對RTOS內部的一些實現有更深入的理解。

3.2. 熟悉經常使用算法

算法經常和數據結構放在一塊兒談論，可是在這裏，更多的是一些控制算法，如PID，模糊控制。

3.3. 熟悉數電模電

這些就不只僅只是設計周圍電路或者經常使用芯片，而是設計一些更加複雜由多個芯片組成的模塊。

3.4. 熟悉FPGA

做爲硬件設計的最終手段（額，，我我的是這麼認爲的），FPGA能夠完成許多MCU沒法完成的任務。
每每FPGA是和MCU協同工做的。

4. 總結

必要能力中，除了編程能力之外，另外三個，說是能力，不如說是一種習慣。
這種習慣須要培養，前期可能比較不習慣，可是滾起雪球來就很明顯了。
編程能力也是的，當你學會一種編程語言以後，再學其餘的就沒那麼難了，由於他們的格式，語法都差很少。
你也沒見過哪一個高級語言裏，if-else結構中，條件不成立的在條件成立的部分以前。（彙編語言裏爲了優化，彷佛有這樣的操做）
可選能力的話就須要根據要去的公司和項目來決定，固然提早會一些也是不錯的。
至於加分能力，顧名思義就是加分嘛。若是不會這些，應該不會影響平常的工做。可是瞭解一些的話，對平常的工做會有很大的幫助。
如何提高可選能力和加分能力，天然是在項目中學習，在實戰中學習。有了上面的必要能力，學起來不是問題。
固然可選能力也能夠經過閱讀文檔來學習，（我我的不提倡）雖然較慢，效率不高。但對於現階段無法完成項目，或者急於面試的同窗們還是一種方法。

基於模型的設計流程的優缺點

我我的以爲，基於模型的設計流程不該該和其餘傳統的設計流程相比較。
在Managing Model-Based Design中，Chapter 4，小標題使用的都是Model-Based Design Within xxxx。
而且摘錄到如下內容：

This chapter provides an overview of common development methodologies and
explains how Model-Based Design core concepts support these methodologies.
It then explains how Model-Based Design can help you adapt any methodology
to the needs of your project.

綜上基於模型的設計流程更多的應該是和傳統的設計流程相結合在一塊兒，做爲輔助。

優勢：

我我的還有一點小觀點，傳統的設計流程，無非是把各個流程拆分，組合，順序調轉，以達到更好的效果。
可是萬變不離其宗，因此如下的分析就以最經典的瀑布模型爲例：

需求分析

基於模型的設計能夠很快的把總體效果呈現出來，給客戶或者團隊成員展現。
這樣相對文字和圖片的描述更加直觀，每一個人也能夠單獨查看本身感興趣的部分。

設計

在設計時，基於模型的設計能夠很快的切換另外一個設計並進行仿真，查看是否知足要求。
一個好的組件庫甚至不須要作一些接口轉換就能夠完成。

編碼

目前一些支持基於模型的設計的軟件，如Matlab，均可以自動生成代碼。
再加上一些BSP的庫，就像在麪包板上接線同樣，接口對應就行。

驗證

將同一組數據同時交給程序和模型，而後將程序所得結果和模型所得結果進行比較，可知其正確性。
還有用模型模擬被控制對象，並接入程序，模擬真實運行環境，甚至極限環境。可知其魯棒性。

維護

維護的一大關鍵是查錯，若是能夠獲得出錯時的數據，將數據導入模型就能夠模擬出當時的環境，
以便找到解決辦法。

缺點

模型庫對於任何一家公司都是須要很大的成本，不管是金錢上的成本仍是開發上的成本。
除了成本以外，驅動模型庫須要大量的數據，數據的收集也是一大問題。
另外，若是不是對各個方面的知識都有所瞭解的話，用起來就會有點無從下手。因此不建議純新手使用。

舉例

以前有作過一個兩輪小車，其中涉及電機控制，PID閉環，慣性導航。
當時只是有嘗試過仿真電機，可是由於電機參數都不知道，因此以失敗了結。
另外，在學習慣性導航的時候，也用到了建模和仿真，有很明顯的效果。
最後的感覺就是，本身用起來很麻煩，若是有現成的就很好用。
其緣由，大概仍是本身學識淺薄吧。
若是完整的使用基於模型的開發流程的話，總體的設計會很是快，畢竟模型就是拖動幾個控件。
可行性的驗證也會很是準確，不至於幾個月都沒辦法肯定慣性導航的可行性。
因爲編碼較爲簡單，加上初學STM32，因此更可能是強調本身學習，不能依賴自動編程。
以後的驗證和維護可能比較麻煩，由於是咱們本身設計的小車，可能沒有足夠的傳感器來獲取想要的數據。
也就是說，沒有辦法拿到數據和模型中的數據相對比。
綜上，基於模型的開發流程仍是減小了工做量，大大的推動了項目進展。利大於弊。

以上爲我的觀點，歡迎討論