Melis4.0系统架构以及V833/V831-IPC开发QuickStart

budbool LV 9

本帖转自CSDN：https://blog.csdn.net/tugouxp/article/details/116980346
作者：papaofdoudou

Melis4.0简介

Melis3.0及之前的版本过于严格的模块化设计，增加了系统不必要的复杂性，有过度设计之嫌，随着新的特性和问题fix补丁的不断引入，系统出现了僵化，顽固，粘滞，重复的问题，使设计难以改变，难以重用，难以做正确的事情，八股文式的模块封装机制，产生了大量重复的代码，不但增加了系统运行时负载，还限制了系统的开放能力和方案容量。有鉴于此，Melis4.0在Melis3.0的基础上，对系统架构进行了重新设计，去除了全系统模块化,混合内核等复杂的内核机制，淡化模块化带来的影响，采用大内核小模块，弱化混合内核机制，增强宏内核特性等措施。增加和完善了对Posix,V4L2, OpenMax,MPP, Debug子系统，USB UVC Class, Linux style的设备管理以及抽象Hardware层的支持，整体开发风格向Linux靠拢，不但使系统更容易使用, 而且在多媒体处理能力上得到了增强。

Sunxi OS 全家福以及Melis的定位：

Melis4.0整体架构如下图所示.

内核仍然是基于熊大的rt-thread进行拓展,作为一款有高度的高性能内核，RT-Thread不但可以适配MCU级的应用方案，还可以支撑Linux级的大型应用方案，这是zephyr, freeRTOS等内核无法比拟的，另外，pthread, shell，以及网络组件等部分也是从熊大社区直接拿来用的，在这里向熊大表示深深的感谢 @熊大.RT-Thread, RTOS, 物联网操作系统 - RT-Thread物联网操作系统

Melis4.0的方案架构如下图所示，其中核心的两大块，Middleware和Framework起到呈上启下，继往开来的作用，呈的是应用端的枝繁叶茂，花团锦簇，启的是内核乃至硬件的各种潜能。

具体的讲，浅色的ffmpeg/gstreamer组件是未来计划引入的部分，之所以引用gstreamer是因为相对于其它的多媒体框架，Gstreamer整体框架调度性能更优秀,而FFMPEG的跨平台性性能和软编性能够好，可以作为核心编解码组件，两者相辅相成，并不冲突。

V4L2,OMX, MPP的引入增强的了系统对多媒体的扩展能力和兼容能力，不但可以降低sensor移植时的难度，还能够有效利用既有Linux上的方案成果，使用户能够快速从Linux向小成本的Melis4.0方案上迁移。

其中，RTOS HAL存在的目的就是为了屏蔽Sunxi F,V,R三系平台的差异,本来计划用CMSIS,结果搞着搞着，渐渐发现CMSIS面向的主要是MCU级的接口定义，针对偏重型一些的SOC并不适用，所以我就自定义了一套HAL API标准，取名 RTOS-HAL。

驱动操作SOP:

环境配置：
配置环境变量：

选择工程，公版工程为：v833-smart-doorbell

如果需要进行自定义配置，可以在lunch基础上执行make menuconfig

如果不需要，PASS掉这一步即可。

编译：
执行make -j4,启动多线程编译：

打包：
执行pack，进行打包：

烧录：

验证：
启动系统：

链接好串口终端，在终端下，输入vin_preview,即可从屏幕端观察到图像输出。

Sensor->CSI->ISP->V4L2->VIPP通路显示:

Melis4.0 RoadMap
Melis系统的强项是多媒体处理，未来Melis系统开发的三个方向：

1.图形图显增强，支持用户界面设计工具.
2.网络：melis虽然移植了各种各样的协议栈，但支持的模组却不多，这方面有待加强。
3.开源.

Melis4.0上的网络
物联网时代，大家都很关连接能力，那么在Melis上，是如何使用网络的呢？

关于Melis系统对外挂模组集成的支持这一块，现在基本所有模组都需要下载一个firmware,这个firmware是三方原厂提供，质量保证,驱动这边需要负责对其装载到模组端，运行以及控制进行管理。

我们则提供了完整的，经过验证过的lwip协议栈，WPA_supplicant实现和稳定的SDIO接口支持，其它的工作包括：

1.解决一些模组驱动的编译问题,firmware的装在还是驱动自己做的.

2.sdio驱动适配, 调试。

3.配置供电，引脚等。

4.主控主要和wpa_supplicant对接，做指令下发，数据接收。

5.按照传统的TCP/IP理解的话，主控协议栈都在网络层及以上，驱动层主要处理的都在mac层,驱动层我们不需要太多关心,但是也不全是库，具体看驱动厂商愿意开源多少了。

另外,不同的模组MAC层的实现不同,分为softmac和fullmac,支持工作量也不一样,softmac需要在SOC端跑mac协议,工作量会大一些,但总体还好.

Norflash方案一例：
典型方案的flash layout

产品优势
Melis4.0的一大优势是快启动，体验快起的丝滑:

快速出图内核配置

-# CONFIG_BOOTUP_TURBO is not set
-# CONFIG_DISABLE_ALL_DEBUGLOG is not set
+CONFIG_BOOTUP_TURBO=y
+CONFIG_DISABLE_ALL_DEBUGLOG=y
+CONFIG_SDK_THUMB_MODE=y

同时为了加快启动速度，减少不必要的打印，要把sys_config.fex中的debug_mode配置为0

boot0阶段会根据debug_mode来决定是否初始化串口，没有打印，系统会更快的进入应用。

debug_mode设置为0会带来一个小小的技术性问题，就是由于卡量产固件中也会使用这个配置，没有打印，卡量产、卡升级的进度无法显示出来，用户会误以为卡升级功能卡死，问题误报，实际上只是一个打印，功能仍然是正常的.

298ms出图效果：

关于性能：
固件SIZE大小优化，Melis系统支持全系统Thumb编译，所以最终生成的固件是16位/32位指令混合的形式。可以减少1/3的固件SIZE。

性能优化，NEON优化在复制内存块时提供了1.5倍的加速。在melis上，针对支持SIMD的ARM处理器,Melis支持全系统NEON编译，典型的，通过它连接使用的C库就可以看得出来：

关于智能应用：
基于V833平台，运行目标检测网络的用例：

USB UVC Camera设备支持：

UVC Camera设备功配置单：

重新编译，打包，烧录，启动后，确认是否存在/dev/uvcout设备节点，此节点是用于输出视频流到PC端的节点：

用例已经编译到系统中，首先将USB线连接 Mircro USB Port(端侧)和USB-Type A port(PC侧),执行用例命令uvcout:

此时，PC侧已有响应：

用guvcview工具查看：

作为MSC设备挂载：
有些产品形态在使用过程中，由于外壳的层层保护，内置的TF卡不宜拆装，比如打猎机这种形态，由于常年安装在野外，TF是由产品外壳保护的，这个时候，就需要一种机制将设备里面的数据读出来,Melis4.0支持MSC功能，可以将设备的存储器挂载到PC上直接读取。

最终配置如下：

编译，烧录固件，执行mscd命令：

执行mscd命令后显示如下，红色的部分是打印的调试信息，可忽略。

此时，盘符已经在PC上出现了，截图如下：

ADB调试：
首先在端侧开启ADBD服务:

重新编译，打包，烧录，启动后，在PC端控制台执行adb shell连接端侧ADBD服务。

注意：MSC 和 ADBD属于两个configuration,不能同时使用。

总结：
之前和熊大交流过melis新架构和rtt smart架构的变化的对比，熊大意味深长的讲“RTT 拥抱多进程，你们放弃多进程”。熊大说的不假，但是放弃模块化和多进程不一定意味着远离Linux的开发风格，Melis系统可以认为是单进程多线程的应用方案，整个系统就是一个进程，在一个进程中当然可以做到与Linux的风格很像的。