fengkb

那个项目用得上这么豪华的搭配！太夸张了点吧，不过还是可以学习很多东西的，呵呵……

花花1098

我对这个开发板有意思

s409348459

学习了！~~~

shihailin001

搞了一段时间DSP了，正想研究达芬奇呢，先学习一下。

bluehacker

davinci架构到底如何，我很是怀疑，跟业界很多工程师聊过davinci，几乎所有的人都对我说davinci是失败的战略。号称TI走arm+dsp的路线，与业界其他主流厂商一致采用的arm+gpu+vpu的路线比，是死路一条。呵呵，看不懂啊

blacksword

我们不否认，将目光盯在TI提供的DSPLink层面来看，在做除了音视频以外的设计时，通常项目会死掉。

但我不认为这是TI的错。

当你需要巨大的运算量时，GPU能给你做吗，还是VPU能？比如电力系统中，数字调音台，各种物理化学分析仪中，这样的需求太多了。

几乎每一个人在遇到这样的需求时，都会非常自然的想到DSP. 区别仅在于以前是一片ARM加上一片DSP.

现在的情况仅仅是TI将这样的两个内核放到一个器件中来了。但没有本质区别的。

 

DSP依然是占用一段存储器来运行程序，ARM与DSP依然是通过RAM交互数据。

所不同的仅是现在DSP的启动由ARM说了算，交互数据从昂贵的双口RAM变成了共享RAM.

但本质上，对于ARM来讲，仍是一个字符型调备的驱动！

另外TI最近提供了很多简化开发的工具，比如我们后面会讲到的C6Run，让你可以以写一个普通C程序的方式来给DSP编程，在ARM上像访问本地函数一样访问DSP函数。

困了，不多说了

awgn

正在学习omap，这个正好

daicheng

这个活动不错，支持！

ddllxxrr

;P

beyondvv

挺不错的，学习了

lixiaohai8211

好，不断的学习啊

jw072315

持续期待中·······························

sdjntl

强。

2eworld

支持一下

bluehacker

你说的我同意，dsp自然有他的优势。只是现在越来越觉得，davinci架构被挤到比较行业性的定制应用中。arm+gpu+vpu有它的优势，在普通多媒体处理等算法上，感觉davinci没有任何优势，比如什么h.264这些编解码。消费类电子主流的应用，比如手机，pmp,ipad之类，davinci由于dsp的开发量大，跟arm+gpu+vpu比是没优势的。
我的感觉只有在那些非标准算法的应用中，davinci才有优势，说的简单点，就是还没有专用的硬件直接实现的那些算法，用dsp是唯一选择吧。
但如果一个算法得到较广泛应用，厂商推出了asic，那davinci就没优势了。

安_然

ARM+DSP ，学习了。

lixiaohai8211

等待第二讲...

tiankai001

原帖由 blacksword 于 2010-11-16 15:38 发表 曾经，会单片机的工程师牛得一塌糊涂。想十年前一个会单片机的工程师几乎就是嵌入式工程师的代名词。若干年前，ARM开始暂露头角，看到单片机工程师的牛气，ARM工程师笑了。而从包括合众达在内的中国DSP三巨头开始在中 ...

 

 

说的真的比唱的好听，我被深深吸引了，

 

跟着合众达，拓展一下自己的视野，

 

感谢合众达，EEWORLD，这么好的一个机会，我不会错过的

blacksword

名词解释：

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版本

暂时讲到这里，稍候继续

ddllxxrr