最近新開一個海思的項目，本週主要海思熟悉海思的一些開發文檔，文檔之多，內容之全，文檔之好，確實值得很多廠商去好好學習，同時也得到很多的感悟和困惑。
對於技術更新如此之快的IC產業，對於現在平臺的百花齊放，技術更新日新月異，單獨如現在的ARM的技術，就已經從armv7架構已經發展到armv8架構，還有現在基於低功耗的M系列，基於實時處理的R系列，每個系列裏面有越來越多的平臺在每日更新，每個廠商對於各個平臺的處理方式又不相同。例如現在主流的對於移動終端採用的是Android的架構，以現在主流的廠商來說，高通、MTK、展訊、全志其開發模式都是基於kernel+Android，但是其每家對於像我們這樣做底層的人來說，又有很多的不一樣。
- MTK：採用的是Cost down和Turnkey模式，提供完整的配套服務，turn-key模式. 這一點目前在業內無人能及，以前在山寨流行的時代，只需要拿到官方提供的Demo板、原理圖和軟件源碼，硬件工程師根據這個製版，軟件工程師編譯源碼（替換UI），就可以發佈新產品了。所有的外設基本都是它們推薦的，Modem測的代碼也是不允許有任何修改，發佈的代碼直接就是一個bin文件。總體來說，MTK的開發難度更小一點，產品化更好一點。那麼對於我們底層工程師能做些什麼呢？給我的感覺就是調參和開關宏，調參，就是對手機的各個外設配合廠商來調式一組最合適的參數。開關宏，MTK對於各個feature提供了各式各樣的宏來控制，並且提供了完整的手冊來指導你各個宏的意義。最終，我們底層工程師就就會調參和開關宏中慢慢的沉迷。
- Qualcomm：偏向於性能模式和QRD模式，提供相對完整的配套服務，也就是QRD模式。Qualcomm的代碼發佈基本接近開源的Android和Kernel，對於軟件包做也很好，但是開發性會比MTK平臺更好，也是跟他產品的定位有關係，因爲實力擺在哪裏，其模式也是一些小公司玩不起的。高通的QRD模式也基本和MTK平臺一樣，調參和開關宏，也是很多feature，很多情況你只要開關feature可以實現大部分功能。但是Qualcomm的feature很多你都不知道，文檔沒有MTK詳細，同時自帶的feature很多都編譯不過，需要你自己去修改。總之得出的結論是Qualcomm的開發性做的更好，穩定性不夠好，問題更多，但是我們能看到很多功能是如何實現的。
- 展訊：模式跟MTK差不多，但是由於技術沉澱等原因，問題更多，涉及的點大多都達到系統層面或者芯片設計層面的問題，如果要去解決這類問題，對於技術的要求很高，大多廠商都會全程支持解決，對於做底層的最多也是調優工作。
在對於開發模式，都是由產品的市場定位來決定的，產品競爭力不行，那麼服務就需要做的更好，減小客戶的開發週期，減小客戶對於高質量軟件工程師的要求。去大的平臺就能接觸到更新的技術，分工更細，也就對技術的理解就更加深入，那麼小的平臺，就需要我們耐得住寂寞，對工作就需要考慮的更多，更深入，也就是我們提到的do more、do better，那麼我們就需要花更多的時間和精力將這些do more、do better吸收。大公司，最終發展可能好則成爲這個領域的技術專家，而小公司，更多的會向系統層面發展。
在接觸海思的資料後，我發現一種新的模式可能越來越向我們靠近，一方面由於現在每家廠商都在強調自己的核心競爭力，以後對於人工智能的算法等越來越成爲一個公司的核心競爭力的時候，另外一方面系統越來越複雜，平臺越來越多，廠商爲了縮減版本，平臺的兼容性等要求，就會出現對於平臺的抽象層。對於我們來說，以下的開發模式會成爲一種常態，如下圖所示對於我們來說，以下的開發模式會成爲一種常態，如下圖所示
- 硬件層：由芯片加上必要的外圍器件構成，外圍器件包括Flash、DDR、視頻sernsor、音頻等。
- 操作系統層：基於現有的開源操作系統
- 操作系統適配層：提供操作系統調用基礎函數，屏蔽操作系統差異，支持平臺運行在不同的操作系統上，主要是對於的平臺抽象層。
- 軟件處理平臺：基於操作系統適配層，控制芯片完成相應的處理功能。對應用層屏蔽了硬件細節，併爲應用層提供API接口。
- 應用層：根據軟件處理平臺提供的，由用戶開發應用程序，並且廠商會提供相對應的應用示例作爲參考。
對於這種開發模式，這裏面做了些什麼呢？我們又能做什麼事情呢？
- 硬件層：提供基本的手冊說明，基本各個硬件寄存器說明，估計你也用不到，但是出問題後，這個是救命稻草
- 操作系統層：對於開源，以Patch的方式提供，理解各個平臺對於怎麼提供抽象、怎麼去實現抽象、驅動實現方式等
- 操作系統適配層：主要是以第三方庫的方式提供給我們，做了些什麼？鬼知道，出問題怎麼辦，鬼知道怎麼辦？這一層，我們能做的實在太少了，從深層次的方向，我們可以去理解是怎麼跟操作系統層結合的，機制是什麼？
- 軟件處理平臺：主要以SDK包的形式提供給我們，其中包括部分的源碼和庫，還有最重要的，最重要的，最重要的，一大堆include，也就是API的接口，並且提供了直接運行就能驗證這個功能的示例代碼。
- 應用層：基於軟件處理平臺裏面的API做業務的開發，怎麼做呢？基於示例代碼，自己寫應用開發，測試驗證，測試驗證，測試驗證。
那我出問題怎麼辦呢？看手冊，看手冊，看手冊，重要的事情說三遍，手冊上沒有怎麼辦呢？那我們就要理解這些事情的原理，例如莫名的庫裏的東西運行了，表現的結果不一樣，那麼就需要歸結到最底層，硬件的表象是什麼，寄存器，我們可以通過寄存器來查看，在迴歸流程。
現在對於底層開發的工作，不論去哪家公司，基本都是基於芯片廠商提供的東東做二次開發，也許大部分的工作都是一些最基本調優、調參工作。那我們如何能做的更好，不至於成爲一個業務工程師，我們都會面對團隊太忙，沒有培訓，工作時間太忙，沒有時間學習困惑，阿里技術人生給出了好多的建議，總之歸結到態度，要做到do more、do better、do exercise，對於我們技術上，我們需要歸於基礎，只有打好基礎，才能在這種更新中做到臨危不亂。