Linux上位机开发实践（超越MPP去开发产品）

【 声明：版权所有，欢迎转载，请勿用于商业用途。 联系信箱：feixiaoxing @163.com】

        对于芯片厂商来说，肯定希望客户的应用和自己的芯片绑定地越紧密越好。最好就是，他们自己成为客户的独家供应商。但是对于嵌入式开发的厂家来说，通常都会希望自己至少有两家以上的soc供应商可以选择，这样才不会被某一家捆绑住。毕竟，一旦自己的供应商是可以替换和选择的话，那么在后续的议价环节，会占据很大的优势。IPCam Soc竞争非常充分，非常适合用来做嵌入式产品。因此，那么从嵌入式Linux上位机开发的而角度来说，怎么做才能实现自由选择soc的目的呢？

1、提炼通用API接口

        对于IPCam soc来说，一般都会提供MPP开发平台。对于那些不提供MPP平台的soc，也会提供类似的API给客户。所以，对于上层开发的同学来说，一定要构建一个抽象的通用API。比如说，common_vi，common_vo，common_isp，common_venc，common_vdec，common_ai，common_ao，common_aenc，common_adec，common_npu等等。在某一个结构里面，再去进行设计，比如common_vi，

typedef struct _Common_Vi
{
    U8 devName[32];
    U8 devId;
    U8 devType[32];
    U32 width;
    U32 height;
    U32 frameRate;
    U32 dataType;
    U32 isColor;
    U8* pData;
    U32 dataLength;
    VOID* pVoid;
}Common_Vi;

        这里的属性都比较好理解，从上到下依次是设备名称、设备编号、设备类型、宽度、高度、帧率、数据类型、是否为彩色、图像指针、数据长度。最后一个是pVoid，这个变量就比较有意思，它就是所有soc vi属性的基类。我们需要准备这样的一个基类，每个soc来实现基类的接口即可。这样就可以达到抽象接口的目的。通用api尽量是c语言，但是里面的VOID*可以是c++实现。

2、移植FFmpeg

        soc里面的编解码，一般都是针对于h264、h265文件。这些文件又包含在mp4里面。因此，如果需要保存为mp4文件，或者从mp4文件提取h264文件，通常都要移植一下ffmpeg。虽然ffmpeg内部也有h264的编解码功能，但还是赶不上硬解码的性能，所以从实用的角度出发，一般都要替换成硬解码。嵌入式芯片的cpu和pc相比较，如果不替换成硬件加速模块，单靠cpu本身，效果一般都不好。

        有了通用接口之后，ffmpeg做加速的时候，只需要调用通用接口即可。这样就可以实现ffmpeg和具体soc的解耦，后续即使替换了soc，也问题不大。

3、Qt & Boost

        对于嵌入式Linux来说，用Qt做图形界面基本上是标配。不管是工业领域，还是医疗领域，用Qt做界面都很方便。本身Qt开发在windows上就非常方便，所以如果使用Qt+boost库进行功能开发，本身不需要做多大的修改，就可以port到嵌入式芯片上面。

4、使用OpenCV

        在图像领域，OpenCV是标配，很多的算法，并不需要我们进行二次开发。所以，如果是用到一些简单的功能，直接移植OpenCV到嵌入式系统上即可。对于那些有性能要求的api，一般还是需要进行二次优化处理的，比如汇编加速，这样效果会好一点。

5、AI module

        现在很多嵌入式soc都带有npu。如果我们不想依赖于任何一家的soc，那么就需要自己把module翻译成各个soc厂家可以识别的文件形式，再通过API把模型加载到npu上。常见的网络有Resnet、MobileNet、Yolo，它们都可以这么来处理。

6、RTSP等网络协议

        网络协议这部分，都是软件来实现的，很少做成硬件加速。所以不管是哪一个soc，都需要自己移植开源代码来完成。比如利用live555实现rtsp协议等等。其他类似的协议还有RTP、RTMP、ONVIF等等。

7、业务代码

        业务代码部分，就和具体的产品相关。这里面不光有硬件，还有软件。比如说使用到的按钮、对外接口、是否需要屏幕、u盘保存等等。软件部分的话，就涉及到产品所属行业、业务流程、操作人员的习惯、界面的布局、通讯协议等等。这方面不同的产品又不同的需求，具体情况具体分析即可。