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

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

對她仰慕已久

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

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

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

配得上她嗎？

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

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

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

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

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

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

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

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

好好地端詳

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

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

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

牽手前的準(zhǔn)備

認(rèn)識(shí)了我們的主角，下面我們來看看移植上可能會(huì)遇到的問題，當(dāng)然上文所述，算力和代碼大小的問題也要考慮到：

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

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

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

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

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

配置工具適配：因?yàn)槲覀冞@里不使用VS進(jìn)行代碼管理，而OpenCV可以基于CMake進(jìn)行工程管理并借助Make進(jìn)行代碼編譯。
那么針對不同的開發(fā)端OS，Linux / Windows，需要安裝對應(yīng)版本的CMake + Make工具。

憧憬與遐想

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

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

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

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

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