ARM+DSP双核处理器应用程序攻略
摘要：曾经，会单片机的工程师牛的一塌糊涂。如今，ARM开始崭露头角，看到单片机工程师的牛气，ARM工程师笑了。本文，就是希望以实例的形式，讲述开发ARM+DSP双核处理应用过程中，遇到的问题，期待为大家答疑解惑。
关键字：DaVinci  ARM  DSP  GPU  ARM+674x
TI OMAPL处理器介绍 0
曾经，会单片机的工程师牛得一塌糊涂。想十年前一个会单片机的工程师几乎就是嵌入式工程师的代名词。
若干年前，ARM开始暂露头角，看到单片机工程师的牛气，ARM工程师笑了。
而从包括合众达在内的中国DSP三巨头开始在中国推广DSP时，所有开始使用DSP的工程师笑了。他们有理由笑，他们有资格笑。因为在那时，DSP就代表着高高在上，收入高、职位高、声誉高，典型的三高。
而经过若干年的推广，DSP已经脱下了神的外衣，走下了神坛。会DSP的人越来越多。
但随着DSP开发者的日渐增多，DSP的娘嫁人(TI)发现，纯DSP血统的姑娘们越来越难嫁了。时代的青年对于姑娘的要求已经不再在能做一手漂亮而高效的女红(计算)。人们希望娶到家的姑娘是出得厅堂，进得厨房，能歌而善舞。大户人家的公子希望媳妇儿如DSP般贤良淑德，又像ARM般千妖百媚。
2005年TI推出了DaVinci技术，这一血统的姑娘既贤良淑德又千娇百媚。ARM926 + 64x+
在世界各地的选美比赛中，DaVinci小姐一路过关斩将，一届又一届地当选为世界小姐。
但后来人们发现，所有的评委都是对AV比较感兴趣的。一时间，AV门事件波及全球。
在人民大众强大的呼声里，OMAPL小姐，姗姗来迟。  ARM+674x（定浮点DSP)。
她是如此的大方美丽，如此的平易近人，她是无冕的后冠。
接下来的几天，我会继续介续OMAPL处理器家族。在我做完基本介绍之后，我的同事even会讲述如何实现ARM+DSP的通信。
我们不否认，将目光盯在TI提供的DSPLink层面来看，在做除了音视频以外的设计时，通常项目会死掉。
但我不认为这是TI的错。
当你需要巨大的运算量时，GPU能给你做吗，还是VPU能？比如电力系统中，数字调音台，各种物理化学分析仪中，这样的需求太多了。
几乎每一个人在遇到这样的需求时，都会非常自然的想到DSP. 区别仅在于以前是一片ARM加上一片DSP.
现在的情况仅仅是TI将这样的两个内核放到一个器件中来了。但没有本质区别的。
DSP依然是占用一段存储器来运行程序，ARM与DSP依然是通过RAM交互数据。
所不同的仅是现在DSP的启动由ARM说了算，交互数据从昂贵的双口RAM变成了共享RAM.
但本质上，对于ARM来讲，仍是一个字符型调备的驱动！
另外TI最近提供了很多简化开发的工具，比如我们后面会讲到的C6Run，让你可以以写一个普通C程序的方式来给DSP编程，在ARM上像访问本地函数一样访问DSP函数。
MAP-L处理器介绍 1 器件功能组成
名词解释：
OMAPL = Oh My Application Processor Low-power edition. (Blacksword独家解释）
OMAPL处理器内部构成：
介绍OMAPL内部构成之前，我们先来回顾一下TI的DSP功能结构。
下图是TMS320C6748的blockdiagram


从图上可以看出DSP器件其实本质上就是一个DSP运算核心，通过Switch Fabric/EDMA连接了一堆片上外设而已。至于核心那部分，我们大部分只是DSP器件的使用者，而不是设计者，不需要花过多的精力去深究。

我们以前讲DSP的开发：就硬件而言即将需要用到的片内外设引出来而已，把片外的外设连接到总线上而已；而做硬件，我个人认为都无所谓是否DSP工程师，因为DSP也好、ARM也好、X86也好，考验工程师的都是指定的板子硬件线路连接正确性，能不能在指定面积上布完，电路会否出现局部过热，电磁兼容性好否，高速接口线长线宽是否合理等，而这一切不会因是否DSP而有任何的不同。

个人认就DSP而言，软件的开发，才是真正的DSP开发。而就软件而言，即设置好SwitchFabric以便能够选中指定的外设，然后读取指定外设上的数据，将这此处理好的数据再写到其它指定的外设上而已。从这一点上讲，开发DSP本身并非高高在上的神话。大部分所谓的DSP高手，其实严格来讲应该说是数学高手，逻辑高手，他们小小的一点手段，就可以让算法效率提高很多。真正的高手，只有实在在算法没什么可以抠的，才会使用汇编。
那我们不管高手不高手的，总之其实要会写一个简单的DSP程序，做基本的处理，大家都觉得比较容易的。
在第0讲中，我们提到TI从2005年推出了DaVinci系列平台。但很多人用了后，心里有着说不出的委屈，尤其是少部分因为DaVinci而被减员下来的。这部分人看到了OMAP-L，觉得OMAP-L这个平台非常“亲切”，“亲切”得让他们牙痒痒。怎么看怎么像DaVinci。且放下“亲切”的问题不谈，我们先来看看DaVinci的表妹OMAP-L到底长得什么样。盖头掀开，OMAP-L的脸蛋身材如下图（图为OMAP-L138）：

与表姐DaVinci相好过的人，一定能看出来。表姐表妹的区别仅在于一个胸大（在VICP)，一个秀气（DSP为定浮点）
但我更希望大家将目光从胸部移开，这样才有助于我们从整体上认识DaVinci与OMAP-L这对姐妹花。
请大家看看OMAP-L138与TMS320C6748（代表了传统DSP）之间的联系与区别。

你一定会很容易就发现：

共同点就是同样是处理器核心通过Switch连接到各种不同的片上外设。
而最大的不同点就是OMAP-L片内有两个处理器核心，一个ARM 一个DSP。
你要是问一下有经验的DSP开发工程师，开发DSP难不难，你会得到什么答案？
同样你可以问一下有经验的ARM开发工程，开发ARM难不难，你会得到什么答案？
很多公司在很多项目中已经同时使用ARM和DSP，那怎么将ARM和DSP混搭出来的DaVinci/OMAP-L怎么就有很多人觉得不好用呢？
其实这个问题诚然有TI的原因，但与我们本身的用法也有很大的关系。觉得他不好用、不美是很正常的。不信：

你去问一下有经验的DSP工程师，ARM开发容易否？
很多早期开发DaVinci的公司，一个像样的ARM工程师都拿不出来，然后就在那里叫嚷TI提供的东西不全，DaVinci的架构不好，到今天他们也还在说OMAP-L架构不好，就是看着OMAP-L看着像DaVinci。

我们承认对于你的应用TI提供的软件可能相当不全。但这正在DaVinci的魅力所在，毕竟DaVinci提供的不是山寨货，而是提供给大家实现无限创意的能力。

那么在基本组件方面，TI会致力于提供给大家符合Linux标准的各种驱动及软件中间件。有了标准的保证，你会发现如GUI或是RTP/RTSP等更上一个层次的软件组件上，你根本就不缺软件，因为大量的开源项目都是你的项目。

我曾经有一个移植Gnash(Linux下的Flash播放器)的惨痛教训，在TI DaVinci平台仅花了几天时间，所有软件就移植成功。D1以下的基本上能达到15FPS。

但在另一个厂商所谓完善的平台，确认有对于某几个特定应用的完整方案，几乎可以直接将代码用于量产。但当客户需要Flash时，找到了我。我遇到的第一个问题是该平台提供的C语言库是不完整的，不得已我给客户重新移植了C语言库以及编译器。我们都知道在嵌入式产品上要显示就通常会用到Framebuffer。我的第二个问题，就是Gnash要用到SDL，SDL最轻量的backend就是framebuffer。但我无比痛苦的发现，该平台上的framebuffer的驱动并不标准......

做了无数的修改之后，终于将Gnash在客户的平台上运行起来，新的问题是该平台提供的那些完整解决方案，不能运行在新的C库上，然后是非常痛苦的改“解决方案”中程序的过程，总共浪费了好几个月。
因此，我们认为TI的平台还是比较容易使用的，关键是你得让合适的人干合适的事情。后面我们会分析这个架构，并讲述基本的开发流程。