关于这颗芯片： http://www.hisilicon.com/-/media/Hisilicon/pdf/Surveillance_mobilecam/Hi3559AV100.pdf

关于海思芯片的简介真是少之又少，海思似乎没有开放官方的销售渠道，所有的购买都需要经过第三方经销商。这倒也可以理解，因为只有一颗芯片没什么用，必须有它配套的驱动板才行。

在实习期间，我有幸接触了3559a这颗最高端的视频芯片。

这颗芯片的特点是有独立的nnie硬件和ive硬件，并且支持svp平台编码。在这里我先解释一下这些名词。

用户在调用算子创建任务时，系统会为每个任务分配一个handle，用于标识不同的任务。

用户在创建某个任务后，希望及时得到该任务完成的信息，则需要在创建该任务时，将bInstant设置为HI_TRUE。否则，如果用户不关心该任务是否完成，建议将bInstant设置为HI_FALSE，这样可以与后续任务组链执行，减少中断次数，提 升性能。

用户根据系统返回的handle，调用HI_MPI_IVE_Query可以查询对应算子任务是否完成。

IVE 硬件只能从DDR中获取数据。如果用户在调用IVE任务时，访问空间可cache而且CPU曾经访问，为了保证IVE 输入输出数据不被CPU cahce 干扰，此时用户需要调用HI_MPI_SYS_MmzFlushCache 接口刷cache（详细信息请参见《HiMPP Vx.y 媒体处理软件开发参考》），将数据从cache 刷到DDR，以供IVE使用。

与图像或二维数据的width 度量一致的量，如图1-1 所示。IVE_IMAGE_S图像数据跨度，表示图像一行以“像素”计算的单元个数，“像素”位宽可以是8bit，16bit等。IVE_DATA_S 二维数据跨度，表示二维数据一行的字节数，即为图1-1 中n=8的情况。 可以将IVE_DATA_S看成一个“像素”用8bit表示的图像，那么跨度即统一表述为图像或二维数据的一行以“像素”计算的单元个数。

我主要使用的是IVE硬件，这颗强悍的图像处理芯片。我用到了如下一些算子：

在调试算子的时候，一定一定要有耐心。稍不留神就会导致整个程序无法运行。我每次调试的时候都是先用windows平台的模拟器模拟编译环境，在windows上调试完成之后再迁移到板子上，用linux编译成可执行文件，放到板子上看结果。我可以很负责任地说，调试一个算子大约需要一个星期的时间。

首先需要明确，windows上的模拟和实际在板子上运行完全不是一回事。一个最明显的区别就是，在windows上完全不需要考虑物理地址的事儿，只要有虚拟地址，windows会自动调用相应的驱动，自动分配地址、自动运算。而在板子上，所有的操作都需要手动完成，从开辟物理地址、刷新物理内存到query函数是否执行完、物理内存释放等等。更要命的是，在板子上没法调试啊！它没有显示器，所有的可视化调试工具全都没用，想调试那就只能看最终的结果，猜测是哪里出的问题。

我使用的第一个算子就是Erode算子。讲道理，在OpenCV里，Erode就是一行代码的事儿啊！可是放在硬件上就完全不是这回事了。其实海思在windows平台上提供了一套完整的模拟库文件，并且为每个算子提供了模拟代码。（如果有需求可以给我发邮件[email protected]）然而在这套模拟代码里完全没有照顾多平台运行的事儿，所以几乎也只是个参考意义。在真正使用IVE硬件的时候，为了驱动每一个算子都花了很长时间。接下来我分情况介绍一下这些算子和使用心得吧！

由于需要使用硬件，所以内存的开辟是必不可少的。在海思提供的示例中，开辟内存的函数叫做HI_CreateIveImage,但是该函数并没有考虑到硬件的物理地址。所以我就在此基础上进行了一些更改。在图片的存储过程中，需要特别留意存储的格式。在有些情况下，图像的每一行的像素数需要是32的倍数，如果不是，则需要使用一个特殊的标记来说明，这个标记被称为u32Stride。通常，这个标记会补齐剩余的位数，说明还差多少个像素到32的倍数。通常的计算方法是：

case IVE_IMAGE_TYPE_S8C1:

case IVE_IMAGE_TYPE_U16C1:

case IVE_IMAGE_TYPE_U8C3_PACKAGE:

case IVE_IMAGE_TYPE_U8C3_PLANAR:

总而言之，就是每次开辟内存的时候都需要注意是否需要使用硬件，如果是在模拟器上运行，则物理地址和虚拟地址为同一个地址就可以了，而如果是在板子上运行，则需要使用海思开辟物cash内存的函数HI_MPI_SYS_MmzAlloc_Cached。在开辟内存之后，还需要根据每种图片储存的格式，把相应的结构指针指向对应的位置。当然，最后的memset不是必须的。海思提供的开辟内存方法接口如下：

注意！开辟内存之后内存不会主动释放，即使程序异常退出，该内存依然会保留！所以一定要手动释放这部分内存，而且要随用随开辟，用完就删除。对于一张图片来说，如果图片尺寸较大，这些内存占用将是非常可观的。释放函数叫做HI_DestroyIveImage

这是一个格式转换的算子。可实现YUV2RGB\YUV2HSV\YUV2LAB\RGB2YUV的色彩空间转换。这个算子是最简单的算子，我认为。需要注意的是，所有内存都需要提前开辟，否则经过CSC算子之后的图像会出现随机的线条，我不知道这是不是我使用的这颗芯片的个例。

在使用这个算子的时候需要使用Query函数判断运算是否完成，如果运算还没完成就去取结果，如果在开辟内存的时候没有memset则会乱码。HI_MPI_SYS_MmzFlushCache也是必要的，这步的目的是把内存变化刷入硬件。

以下例子是利用两次CSC算子把package格式图片转换成planar格式,当然也有其他方法实现转换，只不过在图像尺寸较大的情况下，耗时比这种方法多。

这个算子和opencv的阈值类似。作用是取一个阈值创建二值化的图像。

输入和输出的图像都可以是IVE_IMAGE_TYPE_U8C1格式。我没有尝试过其他格式。

它的控制结构可以这样设定：

形态学的图像处理常规操作之一，没什么好解释的。pu8Mask是膨胀的mask，中间的点必须是255，其他的点可以是任意值，意思是以中心的点为中心，向外膨胀这么多像素。这里的Flush是非常关键的操作，之前运行失败就是这里的问题。

这个算子的作用是实现resize操作，本来opencv就一行代码就能实现的操作，在使用算子的情况下中遇到了前所未有的挑战。主要bug是随机的线条，在图像的上半部分会出现黄色的5个像素宽的随机线条，在图像的下半部分会出现彩色（随机颜色）的1个像素宽的线条。直到现在这个问题还没有从根本解决，只是调整了代码的位置，这个问题就不再出现了。如果有人遇到相似的问题，欢迎探讨！

这个算子的缺点是只能使用planar格式的图片，所以在每次使用的时候还需要注意图片格式。本来使用这个算子的目的是节约时间，然而如果考虑到格式转换，在图片尺寸较小的情况下，节约的时间非常有限。然而如果本来就需要planar格式的图片，这种方法还是非常有效的。纯粹的resize耗时10毫秒以内。 海思提供的Resize接口如下：

这个接口使用起来并不困难，而且例子中有比较完整的代码。我认为该算子的难点在于格式的转换。我花了很多时间测试各种格式转换的方法，力求耗时最小，然而最终的耗时与OpenCV的resize差不多。以下是完整代码：

这里的写法相对复杂，不过整体逻辑与GMM2类似，只不过这里与背景的匹配、更新背景被独立成两个算子。大体逻辑还是先初始化算法，开辟内存，然后分别做匹配和更新。

这个算子是比较常用的算子，几乎上述每个算子都会用到。主要作用是判断在IVE中相应的操作是否完成。

【注意】

在Windows上模拟的时候，Query的结果永远为true。

/*****************************