本文是一個小系列的第一篇，MCU部署OpenCV的“先跑篇”，稍后會陸續(xù)有“配置篇”、“實戰(zhàn)篇”、“進階篇”、“優(yōu)化篇”，帶您牽手OpenCV，進入OpenCV的廣闊世界。

說到OpenCV，想必不用小編再多說什么了吧，可謂是計算機視覺處理屆的扛把子選手。

對她仰慕已久

但凡是接觸過/親手把玩過數(shù)字圖像的朋友們，都或多或少的接受過OpenCV的輔佐吧。小到：圖像數(shù)據(jù)的打開/保存、攝像頭數(shù)據(jù)的讀取，大到目標識別，神經(jīng)網(wǎng)絡(luò)等，可以說，OpenCV就像是一個無所不能的存在。想做圖像開發(fā)嗎？come on，OpenCV準能大手一揮，委派手下將領(lǐng)來輔佐我們打下江山。

看到這里，相信大家已經(jīng)從字里行間感受到了，小編這無處安放的、快要溢出紙面的、滿滿的膜拜和敬仰之情了吧。沒錯，小編也正是OpenCV的受益者，當你還在為如何打開一張粉絲發(fā)過來的彩圖而一籌莫展之時，OpenCV就會在遠方呼喚：試試imread？圖片太小，看不清偶像的簽名？試試resize？是的，無所不能的OpenCV就是能隨時滿足我們的任何開發(fā)需求，或者說的稍顯專業(yè)范一點：知道《數(shù)字圖像處理-岡薩雷斯》嗎？相信我，OpenCV里都有。

寫到這兒，小編真想直接一個一鍵三連。

配得上她嗎？

就不再過多的感慨了，讓我們開始下一部分，說說今天的主題。

相信大家也有注意到，即便OpenCV在PC端混的風生水起，可是在我們的嵌入式平臺上，這里特指MCU平臺（同為嵌入式平臺，隔壁MPU仗著DDR+強力A核已經(jīng)成功上船），可以說是障礙重重。

首先第一個遇到的障礙是代碼空間，盡管OpenCV的功能強大，其代碼量也讓人心頭一驚。低頭翻翻芯片手冊，看到那捉襟見肘的存儲容量，基本可以直接放棄跑OpenCV的想法了。

第二個大障礙則是算力，與PC機主頻上GHz的多核處理器相比，MCU的處理能力確實堪憂。

但是，自從出現(xiàn)了i.MX RT系列的MCU，讓人們看到了在嵌入式MCU的應用環(huán)境中，借助OpenCV進行圖像開發(fā)的希望。

i.MX RT具有600MHz以上的主頻，讓運行OpenCV成為可能。而其對外部存儲擴展的支持，正好能夠解決代碼空間的問題。i.MX RT系列為部署OpenCV提供了一個新的突破口。

還有第三大障礙，在MCU平臺上跑OpenCV沒有先例可循，想玩但感覺無從下手。

那么，下面小編就來引領(lǐng)大家開始OpenCV的另一種玩兒法，在MCU平臺上進行部署，所選用的平臺是擁有高達1GHz主頻的，我們的i.MX RT1170系列MCU，她擁有最大2MB的內(nèi)部RAM，和外擴的QSPI Flash用于代碼存儲，以及外擴的SDRAM用于龐大的數(shù)據(jù)存儲。

好好地端詳

開始把玩之前，先來正式介紹一下這次的主角，大名鼎鼎的OpenCV項目。

OpenCV（開源計算機視覺庫：http://OpenCV.org)是一個包含數(shù)百種計算機視覺算法的開源庫。沒錯， OpenCV是開源的，不收費喲，太良心。

OpenCV具有模塊化結(jié)構(gòu)，這意味著其包括多個共享或靜態(tài)庫。例如：核心功能、圖像處理、視頻分析、相機校準和3D重建（calib3d）、2D功能框架（features2D）、對象檢測（objdetect）、高級GUI（highgui）、視頻I/O（Video）?？梢哉f，涵蓋了幾乎所有的數(shù)字圖像處理領(lǐng)域。

牽手前的準備

認識了我們的主角，下面我們來看看移植上可能會遇到的問題，當然上文所述，算力和代碼大小的問題也要考慮到：

編譯方式/最終呈現(xiàn)方式：這個主要是涉及到我們最終如何使用OpenCV代碼，是源碼嵌入還是用靜態(tài)鏈接庫的形式。
小編這里直接選擇編譯成靜態(tài)鏈接庫，這樣就不用每次都集成源碼到工程中，更加方便。
不過，有一個問題要注意，因為OpenCV代碼主體是C++編寫的，受編譯器版本影響，可能會導致編譯出來的靜態(tài)鏈接庫并不兼容當前工程。
因此，要注意，編譯器的版本要保證一致，切記??！

編譯工具鏈：在PC上，一般是選用GCC / visual studio（分別對應linux和windows平臺）進行代碼編譯，到了嵌入式平臺，要注意使用對應的嵌入式開發(fā)工具鏈，小編這里推薦arm-none-eabi-gcc以及ARMCland(Keil)。
可能有朋友要問了啊，IAR呢？別問，問就是小編用Keil比較熟悉，手動捂臉。。。。

頭文件和數(shù)據(jù)類型問題：不同的工具鏈的頭文件組織/構(gòu)成方式不同，換句話說，有些頭文件，GCC有而ARMCLang可能沒有，需要特殊考慮。
而數(shù)據(jù)類型問題主要體現(xiàn)在不同編譯器，對于使用typedef重定義的整數(shù)類型的解釋方式。

代碼大小和算力：這里小編沒有進行特殊的代碼級優(yōu)化，完完全全的放手讓編譯器幫我們?nèi)プ隽?，例如使用GCC的-o3，ARMCLand的-oszie / -ofast等

操作系統(tǒng)支持：因為OpenCV的一些代碼是要依賴于OS的，例如多進程 / 進程通信等，而我們的MCU平臺盡管也支持OS。
但是一般都是多線程OS，不太能滿足OpenCV的要求。當然，除了多進程這一點，我們的MCU平臺還是可以勝任的。
針對這一點，就沒啥可說的了，簡單粗暴一點：直接disable掉這些模塊。

配置工具適配：因為我們這里不使用VS進行代碼管理，而OpenCV可以基于CMake進行工程管理并借助Make進行代碼編譯。
那么針對不同的開發(fā)端OS，Linux / Windows，需要安裝對應版本的CMake + Make工具。

憧憬與遐想

隨著人工智能技術(shù)的普及，人們期待在MCU平臺上能進行更加復雜的圖像處理，成熟的OpenCV自然而然地引起了我們的高度關(guān)注。

但是由于前面提到的那些障礙以及對操作系統(tǒng)的依賴，在MCU上跑OpenCV能夠做到什么程度，還是需要不斷地挖掘和探索。

從我們目前工作的情況看，可以說一些基礎(chǔ)的圖像操作：resize、rotate、邊緣提取以及基本的濾波算法等，完全沒問題。小編也將在后面的系列中為大家一一揭密。

當然，OpenCV+MCU仍然是一個全新的領(lǐng)地，具體能做到什么，還要大家發(fā)揮想象力，讓OpenCV能夠在MCU平臺上開出絢爛的花朵！

限于篇幅，本期小編就和大家聊到這兒，下期將為大家詳細介紹如何進行工具鏈的安裝，以及如何對OpenCV源碼進行配置的具體方法。