Melis4.0简介
Melis3.0及之前的版本过于严格的模块化设计，增加了系统不必要的复杂性，有过度设计之嫌，随着新的特性和问题fix补丁的不断引入，系统出现了僵化，顽固，粘滞，重复的问题， 使设计难以改变，难以重用，难以做正确的事情，八股文式的模块封装机制，产生了大量重复的代码，不但增加了系统运行时负载，还限制了系统的开放能力和方案容量。有鉴于此，Melis4.0是在Melis3.0的基础上，对系统架构进行了重新设计，去除了全系统模块化,混合内核等复杂的内核机制，淡化模块化，采用大内核小模块，弱化混合内核，增强宏内核特性等措施。增加了对Posix,V4L2, OpenMax,MPP, Debug子系统，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的方案架构如下图:
其中浅色的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库就可以看得出来：
总结：
之前和熊大交流过melis新架构和rtt smart架构的变化的对比，熊大意味深长的讲“RTT 拥抱多进程，你们放弃多进程”。熊大说的不假，但是放弃模块化和多进程不一定意味着远离Linux的开发风格，Melis系统可以认为是单进程多线程的应用方案，整个系统就是一个进程，在一个进程中当然可以做到与Linux的风格很像的。
作者简介：
曹子龙：全志Melis3.0/4.0系统作者，架构师, 精通领域包括处理器ISA(ARM,MIPS,X86, RISCV,Xtensa DSP), 操作系统内核(RTOS,LINUX)，多核异构计算, ffmpeg,gstreamer等多媒体框架,文件系统，数字电视方案设计等等。
微信: papaofdoudou，喜欢阅读，历史，技术, 一起学习，交流进步 :)