无意间收集到这篇有关OMAP技术介绍文章，感觉出作者的行文幽默，和深厚的技术功底，特分享给大家。
曾经，会单片机的工程师牛得一塌糊涂。想十年前一个会单片机的工程师几乎就是嵌入式工程师的代名词。
若干年前，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的通信。
名词解释：OMAPL = Oh My Application Processor Low-power edition.(Blacksword独家解释）
OMAPL处理器内部构成：介绍OMAPL内部构成之前，我们先来回顾一下TI的DSP功能结构。下图是TMS320C6748的blockdiagram
从图上可以看出DSP器件其实本质上就是一个DSP运算核心，通过SwitchFabric/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的平台还是比较容易使用的，关键是你得让合适的人干合适的事情。后面我们会分析这个架构，并讲述基本的开发流程。下面我们看一下OMAP-L处理器家族都有哪些成员及旁系。OMAPL处理器家族成员：
OMAPL旁系之ARM成员：
AM1808 OMAPL138的无DSP版本
AM1806 AM1808的无EMAC及SATA版本
AM1707 OMAPL137的无DSP版本
OMAPL旁系之DSP成员：
TMS320C6748 OMAPL138的不带ARM版本
TMS320C6746 TMS320C6748阉EMAC及SATA后的版本
TMS320C6742 阉得就更多了
TMS320C6747 OMAPL138的阉DSP版本
暂时讲到这里，稍候继续
图2 OMAPL138 MemoryMap
从数据表我们可以看出如果要从DSP访问DSPL2RAM，只要在DSP代码里访问0x0080,0000到0x0083,ffff
有的人可能要问题，要是我候通过ARM访问呢，那我们往下翻MemoryMap这个表（如下图）
图3 OMAPL138 MemoryMap Continued
只需要在ARM里访问物理地址0x1180,0000—0x1183,ffff (当然是指物理地址，而不是操作系统内核地址或是用户空间地址）。
前面说了各个处理器怎么看外设，尽管图一中也能看出ARM与DSP关系的一点端倪，但估计还有很多人在疑惑ARM与DSP这小两口怎么是什么关系。（废话，你都说是小两口了）。
我们总结一下图1及图2，3所涉及到的MemoryMap表的的内容，我们就不难看现，其实ARM与DSP之间的关系就是如图4这样
图4 站在民政局的角度打量ARM与DSP的关系。
今天我们知道了ARM及DSP怎么通过SCR访问的外设，也知ARM与DSP是怎么XXOO的。
关于ARM与DSP XXOO的详细介绍，我们在下一讲介绍。
敬请期待。
原文地址：http://blog.csdn.net/dyzok88/article/details/45743029
