本文系本站原创,欢迎转载!
转载请注明出处:http://sjj0412.cublog.cn
-------------------------------------------
一个多月以前看过davinci软件开发架构，有了一些了解，由于没有开发版，且有些东西不齐，加上教研室项目告急，就放下了，这次项目完成后，正好一个朋友要用omap3530开发一个系统，于是有了板子，于是开始潜心研究davinci软件开发架构的底层实现机制，经过一周左右的源码研究，终于算是搞清楚了。
那么davinci究竟是怎样一个架构，为什么要这样一个架构呢，它的架构构成是什么？
下面我将以omap3530这款芯片为例，只是从我的角度来说下上面的问题，当然可能并不准确。
davinci:Ti有个很牛逼的芯片系列，那就是omap系列，他的omap系列往往非常高端，是多核心的，一般一个arm,一个dsp,有些还有多个dsp核心，既然是多核的，那么多核间通信就比较复杂了，从而使得开发复杂的度大幅提高，尤其是调试和后期维护，当出现故障后，必须得要dsp,arm端程序员共同解决，且当一方修改后，另一方可能需要很大的修改，同时由于要通信，他们互相依赖，这样arm程序和dsp程序有很大关联系，不能做到独立开发，从而影响整体项目开发进程。
上面的这些问题估计就是催生出davinci的很大原因吧。
Davinci主要解决的就是多核通信，及程序开发独立性。
Davinci架构的程序由3部分构成：
Codes:
codecs算法： 就是处理各种数据信号的算法程序。 Server:可以运行在dsp端的完整程序（就是算法的dsp端的执行体包括dsp/bios）。 App:运行在arm端的应用程序，也就是使用算法的应用。 其他然后底层还有dsplink(dsp,arm多核通信模块),VISA(算法调用接口模块)，CMEM模块（连续块内存分配模块），LPM（电源管理模块）。
架构图如下：
运行机制
下面讲下omap3530芯片，其davinci架构开发的软件的大致运行机制
当程序编译完成后，应该要有两个程序，一个是在arm端运行的程序比如app_remote.xv5t,dsp端运行程序all.x64p.
然后还要有各种驱动dsplinkk.ko(多核通信驱动)，CMEM.ko（连续内存分配驱动，因为dsp要和arm共享一段内存来通信，而arm端一般跑linux，是虚拟内存，必须要一个机制分配连续的一致性内存），LPM.ko(电源管理模块)。
当我们在linux执行./app_remote.xv5t时，linux加载这个程序并运行，这个应用程序会调用engine_create创建一个算法引擎，这个函数的实际效果是将all.x64p下载到内存指定地址，然后给dsp发相关命令，从指定地址启动，从而dsp程序运行起来，当arm应用程序要和arm端通信时就直接操作dsplink驱动文件，即可达到通信的目的，不过一般程序员只需使用标准的VISA Api来操作，这些api会帮你和dsp端通信，这个通信究竟是如何进行的，其原理是什么，将在下面的一些文章中讲解。