ARMDSP双核处理器应用指南

ARM+DSP双核处理器应用指南

 

简介: 曾几何时,懂得如何使用微控制器的工程师们都陷入了困境。 如今,ARM开始脱颖而出。 看到单片机工程师的傲气,ARM工程师笑了。 本文希望通过实例来描述ARM+DSP双核处理应用开发中遇到的问题。 我们期待回答您的问题。

关键词:达芬奇ARMDSPGPUARM+674x

TI OMAPL 处理器介绍 0

曾几何时,了解微控制器的工程师都非常擅长。 我想十年前,懂微控制器的工程师几乎就是嵌入式工程师的代名词。

几年前,ARM开始崭露头角。 看到单片机工程师的傲气,ARM工程师笑了。

当包括Hezonda在内的中国三大DSP巨头开始在中国推广DSP时,所有开始使用DSP的工程师都笑了。 他们有理由笑,他们有权利笑。 因为当时DSP代表着优越性、高收入、高地位、高声誉,典型的三高。

经过几年的晋升,DSP已经脱下了神的外衣,走下了神坛。 了解DSP的人越来越多。

然而,随着DSP开发者的数量日益增多,DSP TI们发现纯DSP血统的女孩越来越难嫁人。 这个时代的年轻人不再要求女孩是漂亮、高效的女明星(计算)。 人们希望娶的姑娘能出堂入厨房,能歌善舞。 富家公子希望自己的儿媳妇像DSP一样贤惠,像ARM一样迷人。

2005年,TI推出达芬奇技术。 这个血统的女孩子,都是贤惠又迷人的。 ARM926+64x+

在世界各地的选美比赛中,达芬奇小姐一路过关斩将,相继当选世界小姐。

但后来人们发现,所有的评委都对AV更感兴趣。 一时间,AV丑闻传遍全球。

在人们的强烈呼声中,OMAPL小姐早已姗姗来迟。 ARM+674x(固定浮点DSP)。

她是那么的大方美丽,那么的平易近人,她就是无冕之王。

接下来的几天,我将继续介绍OMAPL处理器家族。 等我基本介绍完之后,我的同事还会讲如何实现ARM+DSP通信。

我们不否认,如果专注于TI提供的DSPLink层面,在做音视频以外的设计时,项目通常会死掉。

但我不认为这是TI的错。

当你需要大量计算时,GPU可以帮你做,还是VPU可以帮你做? 比如电力系统、数字调音台、各种理化分析仪等,这样的需求太多了。

几乎每个人遇到这样的需求时,都会很自然地想到DSP。 唯一的区别是以前是ARM加DSP。

目前的情况只是TI将这两个核心放入一个设备中。 但没有本质区别。

DSP仍然占用一段内存来运行程序,ARM和DSP仍然通过RAM交换数据。

唯一的区别是ARM现在拥有启动DSP的最终决定权,交互数据也从昂贵的双口RAM变成了共享RAM。

但本质上,对于ARM来说,它仍然是一个字符类型的设备驱动程序!

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

MAP-L处理器简介 1 设备功能组成

词汇表:

OMAPL = Oh My 应用处理器低功耗版本。 (黑剑独家解释)

OMAPL处理器的内部组成:

在介绍OMAPL的内部结构之前,我们先回顾一下TI的DSP功能结构。

下图是TMS320C6748的框图

dsp嵌入式软件_嵌入式软件开发培训_嵌入式软件工程师/

从图中可以看出,DSP设备本质上是一个DSP计算核心,通过Switch Fabric/EDMA与一堆片内外设相连。 至于核心部分,我们大多数人只是DSP器件的使用者,而不是设计者,所以我们不需要花费太多的精力去深究。

之前我们讲过DSP的发展:在硬件方面,我们只是将需要使用的片内和片内外设引出来,将片外外设连接到总线上; 说到硬件,我个人认为你是不是DSP工程师并不重要,因为DSP是ARM还是长线宽是否合理等等,而这一切都不会有任何区别,具体取决于是否是DSP。

个人认为,就DSP而言,软件开发才是真正的DSP开发。 就软件而言,只需设置SwitchFabric,以便选择指定的外设,然后读取指定外设上的数据,然后将处理后的数据写入其他指定外设即可。 从这个角度来看,开发DSP本身并不是一个崇高的神话。 大多数所谓的DSP大师,其实严格来说应该说是数学大师和逻辑大师。 通过一些小技巧,他们可以大大提高算法的效率。 真正的高手只有在实在没有什么可深究算法的时候才会使用汇编。

好吧,不管我们是否是专家,总之,我们需要能够编写简单的DSP程序并进行基本的处理。 大家都觉得比较容易。

在第0讲中,我们提到TI在2005年推出了达芬奇系列平台。但很多人在使用后都感到难以言表的委屈,尤其是少部分人因为达芬奇而被解雇。 这些人看到OMAP-L,感觉OMAP-L平台非常“友好”,“友好”得让人牙痒痒。 他怎么像达芬奇? 抛开“善良”的问题,我们先来看看达芬奇的表弟OMAP-L长什么样。 掀起头巾后,OMAP-L的脸部和身材如下(图为OMAP-L138):

dsp嵌入式软件_嵌入式软件开发培训_嵌入式软件工程师/

任何一个和他表弟达芬奇关系好的人都一定能看出来。 表兄弟唯一的区别就是,一个胸大(VICP),一个娇嫩(DSP是固定浮点)

但希望大家把目光从胸部上移开。 这将有助于我们从整体上了解达芬奇姐妹和 OMAP-L。

请看一下OMAP-L138和TMS320C6748(代表传统DSP)之间的联系和区别。

你会很容易发现:

共同点是处理器核心通过Switch与各种片上外设连接。

最大的区别在于OMAP-L芯片中有两个处理器核心,一个ARM和一个DSP。

如果你问经验丰富的DSP开发工程师,开发DSP是否困难,你会得到什么答案?

同样,你可以询问经验丰富的ARM开发工程师,开发ARM是否困难,你会得到什么答案?

许多公司在许多项目中同时使用了ARM和DSP。 那么为什么很多人觉得DaVinci/OMAP-L这种ARM和DSP的混合体很难用呢?

其实这个问题确实是TI造成的,但是和我们自己的使用也有很大关系。 认为没啥用和不美观很正常。 不相信:

请问有经验的DSP工程师ARM开发容易吗?

早期开发达芬奇的很多公司没有像样的ARM工程师,然后就抱怨TI提供的东西不完整,达芬奇的架构不好。 直到今天,他们仍然说 OMAP-L 架构不好。 看看它。 OMAP-L 看起来像达芬奇。

我们承认 TI 提供的软件可能不适合您的应用。 但这就是达芬奇的魅力。 毕竟,达芬奇不提供山寨产品,而是为每个人提供实现无限创造力的能力。

所以在基础组件方面,TI将致力于为大家提供符合Linux标准的各种驱动程序和软件中间件。 有了标准的保证,你会发现对于GUI或者RTP/RTSP等更高级别的软件组件,你根本不缺软件,因为大量的开源项目都是你的项目。

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

但在另一家厂商所谓的完整平台上,证实对于某些特定应用有完整的解决方案,代码几乎可以直接用于量产。 但当客户需要 Flash 时,他们找到了我。 我遇到的第一个问题是平台提供的C语言库不完整,所以我不得不重新移植C语言库和编译器给客户。 我们都知道Framebuffer通常用于嵌入式产品上的显示。 我的第二个问题是 Gnash 使用 SDL。 SDL 最轻的后端是帧缓冲区。 但我痛苦地发现这个平台上的framebuffer驱动程序不是标准的……

经过无数次的修改,我终于让Gnash在客户的平台上运行起来。 新的问题是平台提供的完整解决方案无法在新的C库上运行,然后更改“解决方案”就变得非常痛苦,完成程序的过程总共浪费了几个月的时间。

因此,我们认为TI的平台是比较容易使用的。 关键是你必须让正确的人做正确的事。 后面我们会分析这个架构,描述基本的开发流程。