曾经，会单片机的工程师牛得一塌糊涂。想十年前一个会单片机的工程师几乎就是嵌入式工程师的代名词。 若干年前，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的通信。
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的平台还是比较容易使用的，关键是你得让合适的人干合适的事情。后面我们会分析这个架构，并讲述基本的开发流程。 下面我们看一下OMAP-L处理器家族都有哪些成员及旁系。 OMAPL处理器家族成员：
型 号 主频(MHz) PWM DMA CPU RAM L1 L2 封装 McASP McBSP MMC/SD Timer(64bit) uPP PRU 其它 OMAPL137 375, 456 3 32ch EDMA ARM9, 674x SDRAM 64K 256K 256BGA 3   1 1GP, 1GP/WD     UART, USB, LCD, I2C, HPI, eCAP, EMAC, SATA OMAPL138 375, 456 2 2 32ch EDMA ARM9, 674x SDRAM, DDR/2 64K 256K 361 NFBGA 1 2 2 3GP, 1GP/WD 1 2 UART, USB, LCD, I2C, HPI, eCAP, EMAC, SATA

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 SCR Switch Central Resource介绍 关于ARM的核心，由于我们不再介绍，它不会因为披上了TI的外衣就不是ARM 关于DSP的核心本身，我们也不再介绍，毕竟，这里我们不是要讲如何做算法的优化。因此流水线与指令集，都不在考虑之内。 就一个应用而言，最主要的就是各种外设的使用。 而对外设的使用而言，最重要的就是这堆玩意儿是怎么连接到CPU上的。 如我们在《OMAP-L处理器介绍 1》中所讲，在OMAP-L处理器上，外设与CPU们是通过SCR连接在一起的。 好，废话少说。上图先！ 图1 OMAP-L138 Switched Central Resource 看到这个图，肯定很多人与我最开始的感觉一样，什么乱七八糟的呀。 里面的SCR还好说，肯定是Switch Central Resource 但BR是什么呢？TI没有给出缩略语说明，但在SPRUGM7D那篇名为《OMAP-L138 Application Processor System Referrence Guide》第4.1节，也就是上面这个图的上面一段文字里列到"The switch fabric is composed of multiple switched central resources (SCRs) and multiple bridges"。 显然这里的 BR就是BRidge的意思。 这样这个图的作用，就显然了，就是说数据可以从哪里到哪里。 而在这个算是器里面有能力决定哪个使用哪个SCR或BR的核心为ARM, DSP, EDMA以及PRU. 讲到这可能已经有很多朋友在骂我罗嗦了。 “那么到底该怎么决定哪个SCR甚至哪一个BR被使用才能访问到一个外设, 比如说串口？你要不说清楚，今天别想走！”（腹黑中） “我们TI，把所有的这些挂在SCR上的外设，统一进行了编址？每个设备都对应在特定的地址上，比如说串口0, 0x01c4 2000 ——0x01c4 2034分别对应着串口寄存器RDR－MDR。客户只需要大CPU上访问0x01c4 2000就可以访问相应串口寄存器，对应的SCR及BR会自动选上” （想知道我们TI是怎么设计器件，嘿嘿嘿！） 被忽悠了半天看这个图，比较不爽！（权当消遣了，学习一下芯片的实现原理） 对于我们要用好器件上的外设而言，比较实惠的还是memoryMap。 下图为OMAPL138器件的MemoryMap（摘自OmapL138的datasheet）. 图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的详细介绍，我们在下一讲介绍。 敬请期待。

3 以SEED-DIM138/1808-Kit上的LED灯D1为例讲述如何进行相关开发（一） 本文档的使用许可证： 本文档遵循GPLv2发布，因此任何人引用或修改本文档均需要在发起引用的文章的显要位置（开头或结束处）原样引入本段文字（互联网及电子文档为斜体蓝 {MOD}，）及所引用版本的下一段的文档编辑人员的列表及工作内容。 适用器件：操作适用于基于TI OMAP-Lx8 C6748 AM18xx处理器的SEED-DIM138/1808-kit，方法适用于TI Sitara、DaVinci、