DM6467平台移植opencv2.4.3（1）

 转载自

http://blog.sina.com.cn/s/blog_a1fed07c0101bh2i.html

引言：在DM6467平台上实现一个视频采集、处理和回显的需求，其中，视频通路是用DVSDK里的例程video_loopback，处理部分是一个目标识别算法，用opencv的库函数在dm6467的arm侧来实现。本文的主要工作是把目标识别的算法加入到原有的视频采集回显的例程中，从而实现对目标物的判定并框定其区域。

一、背景知识

1.   关于opencv

       Opencv是intel发布的一个专门用于视频和图像处理的开源软件包，它与平台无关，可以在linux，windows下使用，主要的构成为C以及少量C++代码，并完全开源。目前最新的版本是opencv2.4.6，2013年7月才发布的。关于更多opencv的信息，有兴趣的朋友可以参看opencv中文论坛：http://www.opencv.org.cn/，我就不再赘述了.

我们的项目是要实现一个视频采集、处理并回显的目的。处理部分的代码是用opencv2.4.3的函数编起来的，在开发的前期，可以在VC上跑算法，以便验证算法的正确性，关于opencv和vc的开发环境的搭建，这篇博客有用：http://wiki.opencv.org.cn/index.php/VC_2010_Express下安装OpenCV2.4.3，由于vc调试起来方便，可以用它来验证算法的正确性和可行性，好处是上手简单，效率比较高.

  我们的目的是要在嵌入式系统上实现这个算法，VC上调好的算法怎么朝DM6467上移植是个大问题，主要有这么几种方法：

1.       算法的处理工作全部在arm侧进行：需要把opencv经过交叉编译，编出能够在arm上用的库，把这些库文件扔到嵌入式系统的文件系统中，在采集回放的例程中加入算法，调用相应的opencv库。这种方法的好处是简单，不涉及双核的东西，全部的操作都在arm侧来进行，缺点是：arm侧本来就不适合做复杂的计算，这样做会导致算法实时性差，而dsp侧的资源被浪费。

2.       算法的处理工作全部在dsp侧进行：需要把算法和opencv在ccs上调试并编译成可执行文件.x264P，算法的实际执行都在dsp侧，而总体的调度和控制在arm侧完成。这才是双核系统的正常处理架构，dm6467就该这么玩.

3.       Dsp和arm都参与算法的处理工作：更好的方法是：看看两个核的荷载，一般说来arm侧会相对空闲一些，而dsp要满一些，可以把一些简单的opencv处理放在arm侧来做，以平衡两个核的荷载，从而达到资源的有效利用。实时性无疑是评判算法性能的决定性指标（在相同复杂度下）。

 由于项目周期较紧，在一周之内要完成算法的演示工作，而DSP侧又是从零开始，所以选择了第一种方法，将全部的工作交由arm来搞，这样实现起来很简单，主要的工作量是：将opencv交叉编译为目标系统可运行的lib，把这些lib拷入目标板的/usr/lib下，再找到可以访问视频数据的地方，从这里突破，把视频数据抠出来，用opencv函数处理，再放回给显示器即可。

 

2.       关于video_loopback

TI会提供给用户很多例程以供用户开发时做参考，我们选用video_loopback这个历程来作为移植工作的基础。video_loopback就是一个视频直通的例程，没有经过任何处理，很简单，恰好满足我们的要求。视频数据采进来，经过一个乒乓buffer，输出给显示器。有一篇很好的博文对于理解视频采集过程有帮助：http://www.cnblogs.com/tinz/archive/2012/05/18/2507357.html，在这篇文章里，作者详细介绍了DMAI和V4L2的相关知识，还包括视频通道，数据从哪里来到哪里去，对于新手有帮助，建议看看。

 Video_loopback中需要改一点东西才能跑通，把输入视频格式改为component分量输入即可

二、Opencv的移植

1.       版本的选择

建议从低版本移植，不过我们项目上直接搞opencv2.4.3，这其实是一个相当二的决策。软件版本太高很有可能导致硬件平台不支持，从而移植失败，不过幸亏这个opencv2.4.3没有出现大的问题，移植工作还算顺利，阿弥陀佛。我建议还是稳扎稳打，先从低版本着手，循序渐进。建议移植opencv1.0.0，不过移植过程也是相当的艰辛啊，有兴趣的同学可以参考我的另一篇博文，详细的讲述了opencv1.0.0的移植经过。

        有几个问题说一下：我虽然也成功的移植了opencv1.0.0，但是其中的很多函数不可用，如最基本的cvloadImage等，原因是highgui这个组件有问题，而且从编出来的文件来看，没有.so文件，仅有.a文件。而且opencv1.0.0与其他的几个组件的关系也把人搞得晕晕的，如x264  xvidcore   ffmpeg等。所以我说这个移植过程很艰辛。

2.       移植的过程

好了，决定了移植的版本，就可以开始移植工作了。主要分两步：交叉编译和拷贝库文件到板子里。Opencv2.2.0之后的版本都支持用cmake工具来配置编译选项，这个比以前用configure的方法简单了许多，这里再提供一篇博客，专门讲opencv2.4.3交叉编译的过程：

http://www.cnblogs.com/emouse/archive/2013/04/01/2993842.html

照这个做基本上就能把交叉编译的问题搞定了。编译完成之后，把编出来的.so文件全部拷贝到目标板的/usr/lib目录下，至此，opencv的移植工作就完了。 

三、程序的联调

有三个问题需要考虑下： 1. Opencv库怎么才能成功的调起来？2. 怎么访问图像数据？3. 算法程序要加在哪里？
1.       Opencv库怎么才能成功的调起来

找到要加入算法代码的目录，打开其Makefile，在编译选项中添加-I/，如：

CPP_FLAGS                =-I/usr/local/test/include/opencv

在-l处添加需要使用的库文件：GNU_LD_FLAGS=$(LD_FLAGS) -lpthread -lm -lopencv_core -lopencv_features2d -lopencv_flann-lopencv_highgui -lopencv_imgproc -lopencv_ml -lrt -lopencv_objdetect-lopencv_video

然后，在一个.c文件中加入一次opencv的库函数调用，如：

IplImage *srcImage = cvloadimage(“aa”, rb); 编编试试，如果不报错就证明能够认识调用库函数的动作，就可以把算法加入进去了。

2.       怎么访问图像数据

在video_loopback中，主程序会循环的调用capture_get,  display_get,  capture_put, display_put这几个函数，其入口参数都有cbuf 或dbuf， 这个结构体中，就包含了我们感兴趣的东西——图像数据存放的地址。通过Buffer_getUserPtr函数，就可以获取buffer中数据的指针，图像数据就存放在这里。下面这个语句就是把dbuf里的数据指针拿出来，传给hDisplay的数据成员。而这个v4l2buf就是调用ioctl将数据送显的入口参数。

hDisplay->bufDescs[idx].v4l2buf.m.userptr =(Int)Buffer_getUserPtr(hBuf); 有了数据存放的地址，又知道图像的尺寸和格式，我们就可以试试修改buffer里的东西了，不妨直接用memset设置v4l2buf.m.userptr里的内容，将一块图像区域设置为全0，或者画个框框，这里应该很顺利的。

3.       算法程序加在哪里

有了上面两项的基础，我们就可以着手加入我们的算法了，算法加入的位置应该在display_put函数中，在调用ioctl之前，我加入的位置如下：用cvcreateImage创建一幅图片，再把buffer里的东西拷给它，我们就可以使用了，处理完之后，再把图像拷回原来的buffer中，调ioctl送显。说来简单，但当时调试的时候由于对平台和opencv不熟悉，也颇费了些周折。比如，这个v4l2buffer的地址就不能随便给，我在初期调试时，是把srcImage->imageData的地址直接给ioctl去送显，结果显示器上黑屏，后来想了想，在这种data more的场合，肯定是需要DMA的，而DMA的映射操作是在初始化是就做好的，用户空间里的一片buffer可以直接通到kernel里的DMA的buffer，这个机制就是mmap，所以，在用户空间中，你就只能使用映射好的地址，所以需要把处理完的数据再拷贝回原来的buffer中。另外，opencv中有许多库函数是C++实现的，在vc上能跑通的程序，在嵌入式系统上可能会因为编译器不同而无法编译成功，仅需要改改函数的调用即可，C++会默认的给缺省的参数一些值，而C编译器不会，所以这里需要注意下，不过都是些小问题，仔细看看编译错误和源代码，应该都容易解决。

为了提高调试效率，建议在VC个嵌入式系统上同时来调试，因为VC的界面比较友善，单步走调试也方便，而嵌入式上一些想不通的问题，也可以拿到VC上调调试试，对比验证，可以帮助我们更好的定位问题。

四、结语：由于能力有限，且时间紧迫，算法在arm上来跑，这对于DM6467无疑是一个浪费，后续准备在dsp侧来实现算法，arm侧调度，就是按照上面说的第二种方法来做，另外opencv也可以换成更适合在嵌入式系统上用的EMCV。