上一篇講了一下有統的應用程式移植，相對來說比較簡單

從今天開始要移植一個沒有系統的應用程式到S32V234上，處理預處理需要用到ISP外，還要使用APEX，還要使用linux系統管理載入檔案，原來的應用程式中的檔案載入管理是自定義的檔案開啟和讀取函式

先分析一下需要做的工作，先擡頭看路，後埋頭拉車

1、讀懂程式：核興演算法實現原理，讀懂應用程式呼叫硬體資源的相互關係

2、再次讀應用工程程式，需要區分那些是需要linux系統代替進行管理硬體資源的部分，那些是現有linux平臺已經提供了硬體資源只需要應用層介面函式呼叫就可以的，一些配置檔案的在lin5ux系統中的載入和執行方式，linux檔案管理等

3、從應用程式的主函式開始，一步步新增到當前的平臺中，在A53上先實現獨立的功能

4、在A53上已經實現的功能函式，將需要使用APEX處理的部分分塊化轉移到APEX處理，需要預處理的部分，轉移到ISP部分進行相關的處理

5、最終功能的配置，一些配置檔案在移植中可能被暫時放置，整個應用程式移植完畢後，可再次配置這些檔案，修改核當前平臺上相關的引數設定（如介面函式的影象大小，攝像頭的內、外參，攝像頭的角度，車寬等引數），確保源程式功能實現完整。

初步移植的思想按照以上的方法來進行，有大神路過的請指教一下！！！

初步的瞭解後，發現這個別人優化3年的程式，確實太多檔案了，所以，決定除了部分配置進行借鑑之外，主要的演算法直接自己寫出來，然後把借鑑的配置演算法新增進去，主要考慮到這個演算法、配置檔案、硬體交叉在一起，而且基本是全部使用了類，和模板，進行了重複疊加的繼承，感覺好累，主程式工程下的標頭檔案有113個，這還不包括與驅動交叉的呼叫的檔案和硬體驅動初始化檔案，所以自己感覺與其移植，還不如自己寫算了，至於大量的配置，蘿蔔白菜各有所愛，可以自己寫出來，這都是小事。

下面說一堆廢話！！！

說到這裡，我根據自己的經驗，總結一下有系統和沒有系統的程式框架有什麼區別（不講硬體結構的影響）

1、有系統：應用程式與底層的驅動沒有直接的關係，硬體資源有linux系統完成，所以應用程式移植非常好做（前提是驅動這部分已經完成，演算法寫好了），所以分出了應用工程師和驅動工程師。驅動偏向於硬體配置（驅動的移植、新增），所以對硬體必須要懂，能看懂硬體的技術手冊，對linux驅動原理要非常熟悉，應用工程師就是要使用linux系統檔案介面把自己的演算法和硬體接起來

有系統，按照傳統的分類，很確定，就是三層（包含硬體）：

最上一層：應用層。放置應用演算法，確定並行處理訊息傳遞，UI等。說白了就是把沒有系統的應用工程去掉硬體、底層相關的部分，全部放到應用層

中間層：linux系統驅動層：連線硬體和軟體之間的層，放置硬體驅動等。

最底層：班級支援包，和硬體密切相關，對硬體的記憶體管理，設定啟動等。

2、沒有系統（在已經有板級支援包的基礎上）：我覺得程式設計部分也可以分為隱形的三層，

第一層就是純介面的匹配和定義的檔案，主要是定義IO口，硬體模組的介面定義，主控晶片的引出角介面定義 

第二層就是應用程式之間通訊，包括演算法之間的訊息傳遞，比如一張影象從上一個處理後傳遞給下一個處理，還有硬體介面的訊息響應，按鍵，紅外接收器，等等，硬體介面的響應響應需要有專門的接收和傳送函式，以確保資料接收的準確性和可靠性，屬於外部與控制系統的通訊。演算法訊息傳遞一般不需要特殊處理，因為程式是順序流執行，比較成熟的演算法工程師會寫檢測函式去確保每一個環節不會出問題，便於測試和檢查程式。

第三層：演算法，一個模組封裝成一個部分，這樣組合起來的演算法的移植性好，模組可以被方便快捷的重用和更改。演算法和資料結構有關演算法的核心是資料結構+數學公式，用定義的資料結構實現一個公式，資料結構是為了方便演算法的處理和適應不同的處理物件，一副影象可以封裝在一個有長、寬、高、深度、儲存的型別等組成的一個類裡面，要對一副影象處理的時候，可以方便的使用這些引數，一個好的程式，定義的資料類不能太多，太多會導致重複。

才疏學淺，上面簡單講一下，歡迎拍磚，共同進步！！！

好了，快1個多月了，今天是11.24，基本的核心演算法，自己已經寫完了，主程式1000多行，感覺比原工程檔案裡面30多個cpp檔案要爽的多，然後就可以輕鬆的放置到開發板上了，回過頭看一下，覺得對於移植走了很多彎路，沒有系統的工程移植到帶系統的上面，如果能力不足，建議走的路線是：

瞭解硬體系統---讀懂核心演算法----分解功能----判斷演算法硬體依賴----按照演算法思路在PC自己寫出演算法（可以將原工程中的演算法部分copy過來）----將演算法放置到arm-Linux的系統上

上面的移植方法對於大的工程檔案比較適合，如果是小的工程，檔案不是很多，可以理清楚演算法的硬體依賴，可以直接移植過去。