MP3 Player on Dual-Processor

目录
序论……………………………………………………………6
1- 1 研究动机…………………………………………………………..7
1- 2 专题目标…………………………………………………………..8
1- 3 工作流程…………………………………………………………..9
1- 4 开发环境与设备…………………………………………………10
德州仪器OMAP 开发套件…………………………………10
2- 1 OMAP介绍………………………………………………………10
2-1.1 OMAP是什0 …….………………………………….…10
2-1.2 DSP的优点……………………………………………....11
2- 2 OMAP Architecture介绍………………………………………...12
2-2-1 OMAP1510 硬体架构………………………………….…12
2-2.2 OMAP1510软体架构……………………………………...12
2-2.3 DSP / BIOS Bridge简述…………………………………...13
2- 3 TI Innovator套件 -- OMAP1510 ……………………………..14
2-2.1 General Purpose processor -- ARM925T………………...14
2-2.2 DSP processor -- TMS320C55x …………………………15
2-2.3 IDE Tool 0 CCS …………………………………………15
2-2.4 Peripheral ………………………………………………..16
在OMAP1510上建构Embedded Linux System…………….17
3- 1 嵌入式工具………………………………………………………17
3-1.1 嵌入式程式开发与一般程式开发之不同………….….17
3-1.2 Cross Compiling的GNU工具程式……………………18
3-1.3 建立ARM-Linux Cross-Compiling 工具程式………...19
3-1.4 Serial Communication Program………………………...20
3- 2 Porting kernel………………………………………………….…21
3-2.1 Setup CCS ………………………………………….…..21
3-2.2 编译及上传Loader…………………………………..…23
3-2.3 编译及上传Kernel…………………………………..…24
3- 3 建构Root File System………………………………………..…..26
3-3.1 Flash ROM……………………………………………...26
3-3.2 NFS mounting…………………………………………..27
3-3.3 支援NFS Mounting 的kernel…………………………..27
3-3.4 提供NFS Mounting Service……………………………29
3-3.5 DHCP Server……………………………………………31
3-3.6 Linux root 档案系统……………………………….…..32
3- 4 启动及测试Innovator音效装置…………………………..…….33
3- 5 建构支援DSP processor的环境…………………………...……34
3-5.1 Solution -- DSP Gateway简介……………………..…34
3-5.2 DSP Gateway运作架构…………………………..…..35
3- 6 架设DSP Gateway………………………………………….…36
3-6.1 重编kernel……………………………………………...36
3-6.2 DEVFS driver…………………………………….……..36
3-6.3 编译DSP tool和API……………………………..…….37
3-6.4 测试……………………………………………….…….37
MP3 Player……………………………………………….…..38
4- 1 MP3 介绍………………………………………………….…….38
4- 2 MP3 压缩原理……………………………………………….….39
4- 3 Linux MP3 player 0 splay………………………………….…….41
4.3-1 splay介绍…………………………………………….…..41
4.3-2 splay 编译………………………………………….…….41
4.3-3 splay 的使用说明………………………………….……41
程式改写………………………………………………...…...42
5-1 程式评估与改写………………………………………………...…42
5-1.1 Inter-Processor Communication Scheme…………….....42
5-1.2 ARM part programming……………………………..…42
5-1.3 DSP part programming………………………………....42
5-2 程式码………………………………………………………..……43
5-3 双处理器程式开发注意事项…………………………………...…47
第六章 效能评估与讨论……………………………………………48
6-1 速度……………………………………………………………...48
6-2 CPU负载………………………………………………………..49
6-3 讨论……………………………………………………………...49
6-3.1分工处理的经济效益………………………………...49
6-3.2音质v.s 浮点与定点运算………………………..…..49
6-3.3 DSP Gateway架构的限制………………………….…50
6-3.4减少IO沟通……………….………………………….50
6-3.5网路挂载File System的Delay…………………..……51
第七章 结论心得………………………….………………………….52
参考资料………………………………………………………………..53
序论
1- 1研究动机
近年来PDA,手机等无线装置上发展的趋势,对复杂的多媒体应用发展越来越多,最新的2.5G和3G手机就是一个很好的例子,它们整合了MP3音讯和MPEG4视讯等多媒体功能.也因此在2001年,德州仪器公司推出开放式多媒体应用平台(Open Multimedia Application Platform;简称OMAP)之设计.OMAP 是一套先进的架构 ;它最大的特色是整合了一颗 ARM RISC 处理器 , 一颗低功率消耗的高效能TMS320C55x 数位信号处理器 ( DSP ).把运算工作平均分配给 RISC 以 及 DSP处理器,使系统发挥最大的运算能 , 而不会浪费电池的电力.无疑的,这个新架构OMAP的推出,在多媒体功能等传统处理器不易实现的应用开发上,有很大的潜力且值得尝试.
我们可以发现到,目前网路上有很多可以跑在RISC处理器的应用程式可下载,但是却没有RISC与DSP整合的程式---我们在此先称之DSP enhanced applications.毕竟,OMAP这个架构算近两年才推出,发展的时间不算长,有很多值得尝试的地方,因此我们才会想在德州仪器的OMAP1510 硬体平台上发展嵌入式系统应用,并尝试开发DSP enhanced applications.
1-2 专题目标
我们手边有的硬体是:德州仪器的OMAP1510硬体平台,它最大的特色是「双处理器」,它整合一颗General purpose 处理器ARM与一颗DSP处理器.我们的专题就是针对这硬体平台,来建构嵌入式系统环境,并期望能尝试开发运用到两颗处理器的应用程式.
我们这次专题的目标为:
移植(Porting) Linux到新的硬体平台OMAP1510
建构完整的嵌入式Linux环境
使ARM与DSP两个处理器能够顺利沟通.
撰写双处理器间沟通的程式.尝试将application―Linux MP3 Player,改写成 DSP-enhanced application,使两个处理器分工运算执行.
1-3 工作流程



1-4 开发环境与设备
硬体:(1) TI OMAP1510 Innovator
(2) ACE USB emulator
(3) 2台PC
软体:(1) Linux与Windows2000
(2) CCS 2.0(Code Composer Studio),在Windows端
(3) 嵌入式系统工具组(如:cross compiler等),在Linux端
第二章 德州仪器OMAP开发套件
2-1 OMAP介绍
为何OMAP能够因应时代的需求,以下我们将简单说明OMAP的优势,与传统的单核心的差异.
2-1.1 OMAP是什0
OMAP是一套先进的架构,为无线市场提供了一套系统解决方案,OMAP可以在一颗晶片上,将许多软硬体组件完美整合在一起,包括:一套软体基础架构,一颗ARM RISC处理器,一颗低功率消耗的高效能TMS320C55x数位信号处理器(DSP)以及一套分享式的记忆体架构.透过一组标准的应用程式界面,OMAP 软体架构也可支援先进的作业系统和应用软体;此外,TI还发展出一套独特的DSP/BIOS Bridge架构(2.2.3会介绍),让设计人员利用最好的方式,把运算工作平均分配给RISC以及DSP处理器,使系统发挥最大的运算效能,而不会浪费电池的电力.
OMAP是一种开放式的架构,并提供了一套标准界面,因此可帮助协力厂商发展新的应用软体或是增加新的功能.OMAP架构可移植到任何一种无线装置作业系统,而它的应用软体也相容於绝大多数的作业系统.
OMAP架构拥有一种独特能力,可以在无线网路家电上,同时提供极高的工作效能以及非常省电的特性,因此,OMAP架构已逐渐成为产业的实质标准.
2-1.2 DSP的优点
为了支援多媒体内容和广告,视讯会议,语音辨识以及其它的应用,许多无线家电已开始提供全动画视讯的播放功能,使DSP技术更显得重要.
DSP确实可提供更好的电力消耗/运算效能特性,因为在基本上,视讯与音讯的播放都是一种信号处理工作,而DSP的主要设计目标,就是为了支援信号处理运算.相较於RISC处理器,DSP元件在每个时脉周期内只会消耗更少的电力.而且DSP元件只要用更少的指令,就可完成一个重复大量数学运算的演算法,并可以在一个时脉周期内执行更多的指令.
只凭一颗RISC处理器,那0第二个应用(例如视讯)的执行就会受到影响,由於受限於RISC CPU本身信号处理能力的限制,RISC处理器必须中断目前的工作,以便处理智慧型电话的要求.相较之下,OMAP架构却能让DSP与RISC处理器并行工作,让OEM在使用DSP功能的同时,让RISC执行擅长的命令与控制功能.

2- 2 OMAP1510 Architecture介绍
我们所使用的OMAP型号为OMAP1510,它包含是一个双处理器的架构,其中一颗是常用在当行动装置上的RISC Processor -- TI925T ARM9TDMI Core,另一颗是用来做讯号处理的DSP-- TMS320C55x DSP Core.
2-2-1 OMAP1510 硬体架构
OMAP1510平台由一个微处理器子系统(ARM),一个DSP子系统,一个记忆体介面流量控制器,一些专用的多媒体应用周边设备(MWA)和一个多工介面构成.
流量控制器(TC)用於控制对外部记忆体的存取,其最高工作频率为75MHz,OMAP内还有192K的内部记忆体,由ARM和DSP共享.但只有ARM才能配置DSP中的MMU(记忆体映射单元),因而决定DSP应以怎样的方式存取这些资源.
2-2.2 OMAP1510软体架构
基於ARM的用户并不需要知道元件中还有DSP.他们可能希望开发环境仍与单核心处理器时的开发环境相同.换句话说,他们希望将DSP完全抽离出来.於是,为了使元件中DSP的存在变得透明,TI导入了DSP桥和多媒体引擎(多媒体网路闸道)的概念.DSP桥为ARM和DSP设立连接,可将其看作同时存在於两个核心中的软体层,DSP桥主要用来向ARM上执行的多媒体引擎导出一组API,以便其存取DSP资源.而多媒体引擎则向应用软体导出一组标准API,这些API正是应用软体开发商所熟悉的.
以下为OMAP1510架构图:
DSP/BIOS Bridge
2-2.3 DSP / BIOS Bridge简述
OMAP架构拥有强大的功能以及易於使用的特性,其中关键就在於DSP/BIOS Bridge,它提供了一个整合完美,易於使用的DSP界面给应用软体发展人员,让厂商在发展RISC应用程式的时候,可透过一组标准的应用程式界面来使用与控制DSP的执行环境.
使用了OMAP平台之後RISC,作业系统核心仍会负担相同的职责,就像系统只包含了一颗RISC处理器,但只要透过DSP/BIOS Bridge的协助,软体发展人员就可以把需要大量运算的功能交给DSP元件,让DSP以非同步的方式来执行这些功能,并且不会占用RISC处理器核心的排程资源.
2-3 TI Innovator套件 -- OMAP1510
TI Innovator 套件提供我们能够轻松的发展应用程式,套件包含OMAP1510开发平台以及CCS(Code Composer Studio),CCS能够使我们能够更容易,更迅速的去发展DSP程式.OMAP中每个核心的最高执行速度都可达到150MHz,并且都可以随作业频率的降低而作出相应变动以节约功耗.
2-3.1 General Purpose processor -- ARM925
ARM既支援32位元也支援16位元(Thumb模式)指令集,ARM925用於执行作业系统(OS).以下为ARM925的介绍:
Up to 175 MHz (maximum frequency)
Voltage: 1.5v nominal
16KB I-cache; 8KB D-cache
192-KB of shared internal SRAM - frame buffer
Support for 32-bit and 16-bit (Thumb mode) instruction sets
Data and program MMUs
Two 64-entry translation look-aside buffers (TLBs) for MMUs
2-3.2 DSP processor -- TMS320C55x
C55x DSP内有5组数据汇流排,在一个周期内允许三次读取作业和两次写入作业.C55x最独特的一点就是它具备双MAC结构,并且其内部具有一个硬体图形加速器.综上所述,C55x DSP是一款高度复杂但功能强大的,专为基於多媒体的即时应用而设计低功耗元件.DSP用於处理所有多媒体应用.以下为TMS320C55x介绍:
Up to 200 MHz (maximum frequency)
Voltage: 1.5v nominal
One/two instructions executed per cycle
32K x 16-bit on-chip dual-access RAM (DARAM) (64 KB)
48K x 16-bit on-chip single-access RAM (SARAM) (96 KB)
16 KB I-cache, 8 KB D-cache
Video hardware accelerators for DCT, iDCT, pixel interpolation, and motion estimation for video compression

2-3.3 IDE Tool - CCS
CCS(Code Composer Studio)是由德州仪器所提供用来开发DSP程式的套装软体,它提供一个完整的IDE(Integrated Development Environment) ,对於多处理器,多使用者的专案,并且是第一个提供DSP(TMS320C2000,TMS320C5000, TMS320C6000) 与OMAP应用程式开发的环境.
CCS以一致的环境来整合所有host与target工具,包括TI的DSP/BIOS kernel,code-generation tools,fast simulators,debugger,与Real-Time Data Exchange (RTDX) 技术,简化应用程式的开发.
2-4 Peripheral
OMAP元件中有品种丰富的片上周边设备,这些周边设备可分为DSP专用周边设备,DSP公共周边设备,MPU/DSP共享周边设备,MPU公共周边设备和MPU专用周边设备,其中有些周边设备只能用於DSP或ARM,其他的则可由二者共享.OMAP中的两个核心透过几组周边设备汇流排存取周边元件.
下图是OMAP1510的架构图
OMAP1510 System Diagram
第三章 在OMAP1510上建构嵌入式Linux系统
一开始是从无到有,整个嵌入式系统环境一点一滴的建构起来,从事前工具的准备,到Loader,Kernel到Root档案系统建构等过程,都会在前4节详细介绍.
而OMAP1510包含了一个ARM处理器和一个DSP处理器.ARM处理器角色定位为General Purpose Processors (GPP),Linux作业系统就是跑在这上面.DSP处理器相较於GPP,它适合做复杂的运算工作,执行起来会比GPP快.若要能同时使用ARM和DSP处理器,我们的Linux还要能支援这两个之间沟通的机制.这也会在最後两节介绍.
3- 1 嵌入式工具
3-1.1 嵌入式程式开发与一般程式开发之不同
我们先简单了解一下,在嵌入式系统中程式的开发与一般PC下最大的不同是--程式编译与程式执行是在不同的平台.
一般而言,因为嵌入式的硬体平台空间资源以及编辑环境等限制.我们会在桌上型电脑这边,也是host端来编译开发程式,这样会比较方便;而target端是你的目的平台,是真正执行程式的平台.
Host端通常和Target端是不同处理器架构的硬体.
这里需要Cross-Compling,Cross-Compiling 就是在「某个类型的处理器平台」中产生「其他类型处理器」可执行档的编译过程.以x86桌上型电脑(host端)为例,他原本编译出来的程式,是要给x86 CPU执行的,我们要在x86这边编译出能给另外一种CPU架构(如: ARM,PowerPC..)执行的程式,这就是Cross-Compling(跨平台编译).这需要在x86电脑上建一套完整的工具程式如:Linker,Locator,Compiler,还有标准C的函式库.
3-1.2 Cross Compiling的GNU工具程式
在UNIX下,有标准的GNU计划,提供很多标准的程式.当然也包括完整的工具程式和C/C++ 函式库.主要就是binutils ,gcc,glibc,gdb等.以下介绍一下这些工具:
GCC ( GNU Compiler Collection)
可以说是 GNU 计画中最重要的作品之一,它提供了自由软体世界高品质的编译器 (compiler).GCC 一个很大的特色是高度可移植性,目前已知有超过三十种硬体平台与作业系统可以执行 GCC.
Binutils( Binary Utilities )
GNU 计画旗下的 binutils 套件中,主要提供了这两支重要的程式,分别为组译器 as 与连结器 ld.在程式的编译过程中,经过编译器 (如 GCC) 的编译与最佳化之後,其输出往往就是程式的组合语言码.这时还需要经由组译器 (assembler) 的组译动作,将组合语言码翻译成机器语言,其输出通常称之目的档 (object file).再经由连结器 (linker) 将此程式所有的日的档与其所需的系统函式库与启动模组都连结进来 (静态或动态连结) 之後,才能产生个可执行程式.
GLIBC (GNU C Library)
标准的 C 语言中并不包含如资料的输出入,记忆体管理,及其他进阶的系统服务等元件.C语言将这些元件留给作业系统来实作,当我们的程式需要使用这些元件时,必须经由作业系统提供的 C 函式库 (libc) 来取得这些服务.C 函式库可说是所有应用程式赖以执行的基底环境.GLIBC里头主要是C的分享函式库( Shared Library ).
3-1.3 建立ARM-Linux Cross-Compiling 工具程式
在Linux下建立ARM架构的Cross-Compiling 工具的主要步骤 :
Step 1. 建立binutils
Step 2. 设定kernel原始档与标头档
Cross-compiling的gcc与glibc需要kernel的标头档.
kernel的source code要先经过 Montivisa 公司(见参考资料)提供的OMAP1510的patch.再修改Makefile的ARCH和CROSS_COMPILE.
Step 3. 建立temporary gcc without glibc
建立cross-compiled版gcc的先决条件是:必须先安装好cross-compiled版的glibc与标头档.但一开始我们并还没产生glibc,因为产生glibc也需要gcc.所以可说是鸡生蛋,蛋生鸡的关系,gcc需要glibc,而glibc本身又需要gcc.不用glibc产生一个暂时的gcc ,可以参考The 0Dinhibit_libc hack"这篇toolchain HowTO.
Step 4. 建立temporary glibc
用之前建立的cross-compiled 版的temporary gcc来编译glibc,设定
./configure --build = i586-linux --target = arm-linux --enable-add-ons
Step 5. 重新建立完整的gcc
现在glibc和它的标头档已经存在了,重新在编译一次即可.
Step 6. 重新建立完整的glibc
利用完整的gcc来重新编译glibc,成完整的cross-compiled C library
3-1.4 Serial Communication Program
要从host端上看到target 端Linux terminal的画面.我们是透过PC上的序列连接埠(Serial Port) 透过RS232线与Innovator Board 的序列埠相连接.需要透过minicom(Linux下) 或 超级终端机(Windows 内建的序列埠通讯软体) .设定如下:
每秒传输位元: 115200 baud 资料位元: 8 data bits
停止位元: 1 bit 同位检查: no parity
3- 2 Porting kernel
在Kernel之前则要先安装适当的Loader,来负责load kernel以及开机(booting),再将经过patch成OMAP Innovator版本的kernel编译好并烧录到Flash ROM.
3-2.1 Setup CCS
目的:我们希望能利用CCS把loader与kernel放到OMAP上
(1)软体: CCS2(Code composer studio 2)为TI所提供的软体
(2)硬体: 利用ACE模拟器连OMAP的JTAG
设定CCS:
1.事先要先安装ACE emulator的驱动程式
2.启动Setup Code Composer Studio
3.Import a Configuration File,选择OMAP1510 ES2 XDS510 emulator
4.设定Properties,如下图
Board Name & Data File中,选择"Auto-generate board data file
with extra configuration file",然後选择ACE光碟中所附的ace.cfg
(2) Board Properities中的IO Port,value设为0x0
(3) Startup GEL File(s)选择iARM.gel与iDSP.gel (iARM.gel与
iDSP.gel为支援ACE的另外的gel).
5. 设定完之後启动CCS,即结束.
3-2.2 编译及上传Loader
先编译loader,以便之後load kernel用.而loader本身要上传到Flash ROM这动作是由CCS 上传,透过JTAG传输.
编译Loader:
我们利用MontaVista所提供的Loader, 编完之後会产生setup与rrload
上传Loader :
开启在3-1设定好的CCS,并连接好JTAG连线.选择File选项里头的"Load Program",来上传rrload.但实际上此时loader并还没真正烧录到rom,此时是在ram中,但这时我们已经可以藉由serial 传看到loader的画面.
接著,我们选择2.Store RAM [comp] to Flash ,才是真的把loader从RAM烧录到ROM上面,下次重新开机,loader仍然会在ROM上面.
3-2.3 编译及上传Kernel
编译kernel的过程
(1) kernel linux-2.4.19,需patch到linux-2.4.19-rmk7,这是针对ARM的patch, 再利用MontaVista所提供对OMAP的patch,这是针对对OMAP的patch,变成linux-2.4.19-rmk7-omap.
(2)要注意编kernel时要指定CROSS_COMPILE,不然会编成X86版
make ARCH=arm CROSS_COMPILE=arm-linux- innovator_config
make ARCH=arm CROSS_COMPILE=arm-linux- oldconfig
make ARCH=arm CROSS_COMPILE=arm-linux- dep zImage
上传 Linux kernel
利用rrload loader所提供的介面 来load kernel
step 1 用minicom透过serial port 连上omap board
step 2 将 linux image转成 rrload format
mkimage --LAddr 10C08000 --EAddr 10C08000 zImage vmlinuz.rr
mkimage : rrload目录里头的一支tool , 用来产生rrload format image
zImage : original linux kernel with ELF format
vmlinuz.rr : linux kernel with rrload format
step 3 在rrload menu 中选择download kernel (参见上图)
於另外一个tty下,打指令 :cat vmlinuz.rr > /dev/ttyS0
3- 3 建构Root File System
OS可说是由kernel和Root档案系统(Root File System)组成的,这是指一个OS的使用者环境,包括应用程式,设定档,Home目录等.通常嵌入式系统下的Root档案系统,有两种挂载模式,一种是制作成映像档烧录到Flash ROM,另外一种则是NFS 挂载.
3-3.1 Flash ROM
将Root档案系统制作程映像档,烧录进去Flash ROM,由kernel开机时去挂载.但每修改一次系统,就得重新制作映像档和烧录的动作,通常在系统完备之後,才倾向用这种挂载方式.
我们利用rrload loader所提供的介面来上传Root档案系统image,同之前上传kernel,只是在rrload选单改成download filesystem.我们尝试的kernel是由delphi公司(见参考资料[15] )所提供的, 它会mount 本机上的file system 但是我们开机之後 , 一开始初始画面都还顺利,到了mounting file system 便会卡死 .尝试换不同File system ,指定不同位址等等, 还是解决不了问题 .
根据台湾代理商智控公司(见参考资料[16] )的回覆是,因为他Boot ROM上面有加密,暂时无法使用.因此我们打算先采用NFS Mounting.
3-3.2 NFS mounting
另外一种则是NFS挂载(mounting),这种网路远端挂载可解决,嵌入式硬体本身空间不足的问题,更重要的是,在测试系统的阶段,整个File System常常变动,为避免每做一次更改就要重新制作映像档和烧录的动作,NFS Mounting提供我们很方便的模式,来发展我们的嵌入式系统环境.而我们所需要做的工作有:
支援NFS Mounting 的kernel
提供NFS Mounting的Server
提供开机初期网路相关设定的DHCP Server
要让Innovator挂载的Remote Root档案系统
以上过程在接下来几节中,会一一介绍.
3-3.3 支援NFS Mounting 的kernel
由於暂时无法解决file system摆在rom上,所遇到开机无法mount的问题, 因此,打算尝试改采用Mount remote filesystem for the OMAP 这时就用另外一个kernel with NFS mount support ,这个用patch过的rmk-omap的kerenl source即可,它预设即为with NFS mounting.
kernel config要做的修改
(1) 支援DHCP和BOOTP
Networking options
[*] IP: kernel level autoconfiguration
[*] IP: DHCP support (NEW)
[*] IP: BOOTP support (NEW)
Bootp(bootstrap protocol):提供无硬碟主机所需之IP位址和开机资讯
DHCP:DHCP是从原有的BootP协议发展起来的,原来的目的是为无碟工作站分配IP地址的协议,目前更多的用於集中管理IP地址.
DHCP可向前对BOOTP compatible,因此,可用DHCP Server取代BOOTP Server
(2) 支援NFS File system
File system --> Network File Systems
NFS file system support
[*] Provide NFSv3 client support
[*] Root file system on NFS
(3) 下给Kernel 的命令(Command Line)
CONFIG_CMDLINE="mem=32M console=ttyS0,115200n8 noinitrd
root=/dev/nfs fsroot=140.115.50.43:/nfs_root ip=dhcp"
nfs_root 代表nfs server为140.115.50.43 根目录为/nfs_root
console为ttyS0(Serial port 1)
ip是用DHCP发给的
3-3.4 提供NFS Mounting Service
架设NFS server
(1) 要让rpc.nfsd , rpc.mountd,portmap 等daemon顺利跑起来,详细可参考网路上文件还有NFS-HOWTO 等资料 .主要是装nfsutils这套件,再利用 /etc/init.d/nfs这只script,利用它来启动或关闭NFS Service.
这里提供一个测试NFS 相关的RPC Service 运作的指令
[root@monkey monkey]# rpcinfo -p
program vers proto port
100000 2 tcp 111 portmapper
100005 2 tcp 954 mountd
100003 3 udp 2049 nfs
至少要看到上面这三项,你的NFS Server才能正常运作
(2) 编辑/etc/exports
NFS Server设定档很单纯,只有这个/etc/exports,用来设定你要分享出去的目录,可access的对象,读写权限等
以下为我们的/etc/exports之内容:
/nfs_root 140.115.50.0/255.255.255.0(rw,no_root_squash)
/nfs_root/etc 140.115.50.0/255.255.255.0(rw,no_root_squash)
/nfs_root/bin 140.115.50.0/255.255.255.0(rw,no_root_squash)
/nfs_root/sbin 140.115.50.0/255.255.255.0(rw,no_root_squash)
/nfs_root/proc 140.115.50.0/255.255.255.0(rw,no_root_squash)
/nfs_root/dev 140.115.50.0/255.255.255.0(rw,no_root_squash)
/nfs_root/usr 140.115.50.0/255.255.255.0(rw,no_root_squash)
/nfs_root/lib 140.115.50.0/255.255.255.0(rw,no_root_squash)
设定说明 :
/nfs_root/sbin, /nfs_root/etc等这些是我们提供给人分享的目录
可access的对象是140.115.50.0/255.255.255.0 这个网域的IP
读写权限为read/write皆可 .
no_root_squash是可使用root 权限
列出自己目前分享出去的目录
[root@monkey init.d]# showmount -e
Export list for monkey.linux.csie.ncu.edu.tw:
/nfs_root 140.115.0.0/255.255.0.0
/nfs_root/lib 140.115.0.0/255.255.0.0
/nfs_root/mnt 140.115.0.0/255.255.0.0
/nfs_root/usr 140.115.0.0/255.255.0.0
/nfs_root/dev 140.115.0.0/255.255.0.0
/nfs_root/var 140.115.0.0/255.255.0.0
/nfs_root/bin 140.115.0.0/255.255.0.0
/nfs_root/etc 140.115.0.0/255.255.0.0
修改/etc/exports档案之後
并不需要重新启动NFS Server,可利用exportfs( 也在nfsutils套件里 )
名称 : exportfs - maintain list of NFS exported file systems
用法 : #exportfs 0ra
-r Reexport directories
-a Export or unexport all directories.
3-3.5 DHCP Server
一开始kernel 在要准备去挂载远端NFS Server上的档案系统之前,也需要一个IP和相关的网路设定,才能藉此IP来跟NFS Server要求挂载,但在还没挂载档案系统前,他无法读取自己的网路设定,因此需要DHCP提供.过程就是kernel发出BOOTP(bootstrap protocol) REQUEST,而DHCP Server 经过验证後,会回覆BOOTREPLY ,并发给它一个IP.
安装DHCP Server後,重点是他的设定档/etc/dhcpd.conf
以下是/etc/dhcpd.conf的内容
default-lease-time 600;
max-lease-time 7200;
option subnet-mask 255.255.0.0;
option broadcast-address 140.115.255.255;
option routers 140.115.1.254;
option domain-name-servers 140.115.50.1;
option domain-name "csie.ncu.edu.tw";
subnet 140.115.0.0 netmask 255.255.0.0 {
allow bootp;
allow booting;
hardware ethernet 00:00:e8:3d:bb:dd;
fixed-address 140.115.50.7;
}
前面设定了netmask,gateway,DNS,IP,并验证卡号身分,才发给他一个140.115.50.7的IP.
3-3.6 Linux root 档案系统
在NFS Server上建立Innovator所需的root档案系统,刚刚在3-3.4设定档/etc/exports里头的那些目录, 如/lib ,/sbin /bin ,/etc等,要事先建立好.
利用busybox来建构工具软体
使用者环境的一些工具软体,如: /sbin ,/bin ,/usr/bin里头的程式 ls ,cp ,mv ,ping等.
在嵌入式系统下,我们会想只选择一些基本必要的工具,省去一些重复或不常用的功能,使这些工具的空间最小化.BusyBox是结合了许多常见的UNIX基本的GNU fileutils,shellutils等里头的程式的浓缩替代品,他将有我们所不常使用的功能拿掉或是有部分的程式码是可以重复利用的做最好的使用,在维持基本功能的前提下,使他编出来的工具程式最小,以适合嵌入式系统的环境.
编辑必要的设定档
如: /etc/fstab ,/ect/init.d/rcS ,/etc/inittab, /etc/resolv.conf 等Linux要正常运作,最基本需求的设定档
配置/dev 里头的装置档
如: /dev/audio, /dev/console ,/dev/mixer ,/dev/ram0 ,/dev/ttyS0 利用mknod这指令来产生
3- 4 启动及测试Innovator音效装置
3-4.1启动及测试Innovator音效装置
make ARCH=arm CROSS_COMPILE=arm-linux- modules
编好的driver modules在/usr/src/linux-2.4.19-rmk7-omap1/driver/sound里头,共有六个依序挂上
modprobe i2c-core
modprobe i2c-algo-bit
modprobe i2c-omap1510
modprobe soundcore
modprobe omap-audio
modprobe omap1510-aic23
以下为开机画面 , 可看到OMAP1510 audio support initialized这样的字眼
3- 5 建构支援DSP processor的环境
我们的嵌入式系统是在OMAP1510上运作,OMAP1510包含一个ARM处理器和一个DSP处理器,作业系统目前只在ARM处理器下运作,若要使开发的程式除了使用ARM处理器之外,同时还能使用DSP处理器.那我们还要建构一个支援「能使用DSP处理器」的嵌入式系统环境.
3-5.1 Solution -- DSP Gateway简介
DSP Gateway是个能协助程式设计师轻松地「同时」使用ARM和DSP处理器的一种机制.它是NOKIA研究中心推出来的,目前支援的架构,只有我们正在使用的OMAP1510.
DSP Gateway它主要包含的是ARM端的Linux Driver和DSP端的API,负责两者之间底层硬体设定,中断处理,跨处理器沟通传输(Inter-Processor Communication)等工作.
有了这沟通管道,我们便可以在分别在两不同处理器端开发程式,在ARM端我们可以透过对/dev下的device file的操控,来与DSP沟通.在DSP端,也有DSP Gateway提供的API,来对ARM端做沟通或控制.有了DSP Gateway,我们可以不用去管底层硬体架构,轻松地在两端开发程式.到DSP Gateway官方网站(见参考资料[12]),下载程式码来架设,
3-5.2 DSP Gateway运作架构
DSP Gateway 包含 Linux device drivers (ARM side program code)和 DSP libraries (DSP side program code)..以下是DSP-Gateway架构图
Linux应用软体可以透过对device file的读与写来跟DSP做沟通DSP端则是透过DSP Gateway 提供的API,来与ARM端沟通
两端的底层资料传送,是"shared memory"的概念.
两端都能开启一个以上的task,来做不同的事情,每个task有自己的device file来做沟通门户.
DSP Gateway提出mailbox当沟通单位,mailbox包含command,data,flag.前两者是一些控制讯号(Control Signal) 给DSP API或Linux Driver做控制的动作, Data则是实际要传送的资料.
下图即为mailbox的在OMAP中的关系图
3- 6 架设DSP Gateway
3-6.1 重编kernel
我们现在重新编的kernel是支援DSP Gateway以及它的DSP Driver.
Kernel patch
将之前Linux-2.4.19-rmk7-omap的source,再对它做DSP Gateway的patch,成为Linux-2.4.19-rmk7-omap-dsp.
Kernel menu config
在menuconfig选单里头
(1) System Type -> TI OMAP -> OMAP1510 DSP driver 这项要选取.
(2) File System -> /dev file system support (CONFIG_DEVFS_FS)要选.
3-6.2 DEVFS driver
由於DSP Gateway的driver采用DEVFS这种/dev file system架构,这是比较新的.之前其他的driver是旧格式的,因此需要安装devfsd这个daemon来管理,才可以向前相容(Old Compatibility ) .
3-6.3 编译DSP tool和API
DSP tool
在抓回来的程式码里头有个DSPtools的目录,里头的程式码用我们的cross-compiler编译,产生的dspctl这只工具程式.dspctl是我们执行DSP程式之前的Program Loader及管理设定的工具.
DSP API
在抓回来的程式码里头有个DSP的目录,里头的tokliBIOS.pjt可以用CCS开启来编译.编出的tokliBIOS.lib就是我们可以在写DSP端程式时使用的DSP API.
3-6.4 测试
执行dspctl start task_testB.out 来载入我们写的task_testB.out这DSP程式,若跑出DSP configuration ….successed的讯息,代表载入成功.
第四章MP3 Player
4- 1 MP3 简介
在MPEG-1的标准中,将声音讯号的压缩标准分为三个层级,分别是MPEG LAYER1,MPEG LAYER-2与MPEG LAYER-3.MP3 就是MPEG LAYER-3的产物了.而MP3就是把现在的CD音乐档,以压缩的方式储存,透过CPU强大的运算能力,以软体解压缩的方式,就可以在电脑上听到好听的音乐了.普通的CD音乐大约是以44.1khz的频率,16位元取样,平均每分钟音乐必须花掉十多MB的储存空间.以目前每片光碟650MB的容量来说,一片CD的储存量约在六十五到七十五分钟之间.
MP3就是将这些音乐透过压缩的方式,增加更多的储存量.由於MP3的压缩比大约在十到十二倍之间,一分钟的乐曲透过MP3压缩,只要一 MB左右的储存空间,换言之每片光碟可以储存六百五十到七百五十分钟的音乐,值得注意的,即使压缩比如此大,音乐的品质依然直追CD,因为利用人类听觉遮蔽的缘故,以现在一般个人电脑CPU的速度解压MP3时,人类听觉没办法分辨压缩後有所不同,让使用者不须为了追求高容量,而牺牲了听的品质.
MPEG/audio 的压缩,其Sampling rate可分为32,44.1,48kHz,其主要是利用人类听觉系统在某些情况下,会产生听觉的mask而无法分辨出量化的杂讯,根据实验亦发现人类听觉有一个极限,也就是人类所能听到的声音频率约为20Hz到20kHz之间
MPEG/audio将声音信号分配成接近critical band的subband,然後依据每一个subband的听觉量化杂讯程度来量化.最有效的压缩,即是将不需要的听觉量化杂讯移除.也就是我们可以将一大部份人类听觉系统所无法察觉的资料移除,以减少资料档案达到压缩的效果.
4- 2 MP3 解码原理
MP3没有一个主要的档案标头档,而是由连续的小部分所组成,我们称为frame,而每个frame独自包含标头档与audio资讯.
在Layer1与Layer2中,每个frame都是independent,所以说若拿掉其中一个frame的话,解码也不会发生问题,但是在Layer3中每个frame却不是independent,所以说若要解码一个frame,那可能需要其他的frame.每个frame利用Hufferman table解码,中间再经过Requantizer,Synthesis filterbank等处理,最後再经由IMDCT(inverse modified discrete consin transform).
以下为MP3的大概解码流程
PS:
IMDCT(inverse modified discrete consin transform):
为decode中最复杂的几何转换.
4- 3 Linux MP3 player 0 splay
4.3-1 splay介绍
我们所改写的是Linux下的一个MP3 player--splay,可以拨放MPEG Layers 1, 2 与 3 和 WAV 档案,重要的是支援fixed-point与floating-point,但为了考量DSP只支援fixed-point,所以我们编译的时候必须以fixed-point版本来编,不然可能无法拨出音乐.
4.3-2 编译splay
./configure
修改makefile,apps/makefile,libs/makefile,把里面的CC=cc改成CC=arm-linux-gcc,表示我们是把splay编成ARM的版本.
4.3-3 splay 的使用说明
sh>./splay 参数
参数有以下几种:
-2 : playing with half frequency
-e : exit when playing is done. (only XSPLAY)
-f : display frame and time info (played and remaining)
-m : force to mono
-r : repeat forever
-s : shuffle play
-v : verbose, Very verbose, Very very verbose
-M : playing MPEG-Audio file as standard input
-V : display version
-k num : start playing at frame num
-d dev : Set dev as device or file
-l list : list file
-t buf : Set number of buffer. (default : 50)
第五章 程式改写
5-1 程式评估与改写
5-1.1 Inter-Processor Communication Scheme
Inter-Processor的策略为执行权主要还是在ARM,而遇到有复杂运算时,可以藉由I/O device丢到DSP端执行,执行完之後再丢回来给ARM端.
5-1.2 ARM part programming
我们必须考量几点:
(1)运算效率:程式的哪一部分适合DSP来做 我们发现到,需要大量运算的地方为IMDCT.
(2)架构限制速度:但基於DSP-gateway架构的限制,要丢给DSP端
的资料,并不能一次就丢给DSP,而必须分多次的传送,这样是否会造成效率的降低.
5-1.3 DSP part programming
我们必须考量几点:
(1)判断语法:DSP适合运算,但对於判断语法,比如说if等,不是说很适合DSP端来做,所以应该减少把这些语法来给DSP端做.
(2)library 使用:CCS提供两个相当好的lib,为dsplib与imglib,dsplib是要用来处理复杂运算的,如复立叶转换,而imglib里有提供image与vedio的encode与decode的函式.要考虑是否我们所改写的MP3程式是否能用到这些lib.
5-2 程式码
简单的说,ARM端与DSP端我们是以一个global ipbuf_d的阵列来互相传递资料,而ipbuf_d有4个,当其中一个ipbuf_d被ARM hold时,DSP端就不可以去存取,反之亦然,所以使用完之後都要release掉,才可以继续使用.
ARM端：
以下为程式大概步骤
程式修改:我们只取片段程式
(a)open device:
bool Mpegfileplayer::playingwiththread(int verbose,int framenumbers)
{
/*我们要读写的I/O device为 /dev/test4*/
char *mydevfn ="/dev/dsptask/test4";
if(framenumbersmakethreadedplayer(framenumbers);
/*开启device 并指定给myfd,device 我们只开一次
myfd=open(mydevfn,O_RDWR);
if(myfdrun(-1,myfd))return false; // Initialize MPEG Layer 3
if(verbose>0)showverbose(verbose);
/*开始对每个frame decode*/
while(server->run(100,myfd)); // Playing
server->freethreadedplayer();
……
……(以下略)
}
(b)dct36:
in的资料型态为class:
class REAL {
int x;
……..
……..(以下略)
}
static void dct36(REAL *inbuf,REAL *prevblk1,REAL *prevblk2,
const REAL *wi,REAL *out)
{
…….
…….(以上略)
/*对device写入in,大小为18,因为每个subband大小为18*/
write(myfd,in,72);
/*DSP处理完,对device读入 ,in 已经在DSP有做了一些处理*/
read(myfd,in,72);
register const REAL *c = cos_18;
register REAL *out2 = prevblk2;
register REAL *out1 = prevblk1;
register REAL *ts = out;

REAL ta33,ta66,tb33,tb66;
ta33=in[2*3+0]*c[3];
ta66=in[2*6+0]*c[6];
tb33=in[2*3+1]*c[3];
tb66=in[2*6+1]*c[6];
……….
……….(以下略)
}
(2)DSP端：
#include
#include "mailbox.h"
/*此为dsp gateway的API,而引入的header*/
#include "tokliBIOS.h"
#include
#include
static Uns t4_rcv_bksnd(struct dsptask *task, Uns rbid, Uns cnt);
struct task_t4 {
struct dsptask task_head;
long in[18];
};
struct task_t4 task_test4 = {
{
0, // 传送编号 tid
"test4", // 装置档名称
// 传送方式: active block snd, passive block rcv
MBCMD_TTYP_BKDM | MBCMD_TTYP_ASND | MBCMD_TTYP_BKMD,
t4_rcv_bksnd, // 注册负责处理 "send request"的函式
NULL, // 注册负责处理 "receive request"的函式
NULL, //注册负责处理 "task control" 的函式
NULL //程式设计者可以指定DSP/BIOS TSK性质
},
};
/*rbid代表ipbuf_d的id*/
static Uns t4_rcv_bksnd(struct dsptask *task, Uns rbid, Uns cnt)
{
Int bid; // 要送给ARM端的ipbuf_d的id
Int ipbuf_trycnt;
Int j;
struct task_t4 *task_t4 = (struct task_t4*)task;
/*ARM端送来资料会放在ipbuf_d阵列中,所以我们把它copy到in中*/
memcpy(task_t4->in,ipbuf_d[rbid],cnt);
/*释放掉ipbuf_d,以给其他使用*/
unuse_ipbuf(task, rbid);

/*运算过程*/
task_t4->in[17]+=task_t4->in[16];task_t4->in[16]+=task_t4->in[15];
task_t4->in[15]+=task_t4->in[14];task_t4->in[14]+=task_t4->in[13];
task_t4->in[13]+=task_t4->in[12];task_t4->in[12]+=task_t4->in[11];
task_t4->in[11]+=task_t4->in[10];task_t4->in[10]+=task_t4->in[ 9];
task_t4->in[ 9]+=task_t4->in[ 8];task_t4->in[ 8]+=task_t4->in[ 7];
task_t4->in[ 7]+=task_t4->in[ 6];task_t4->in[ 6]+=task_t4->in[ 5];
task_t4->in[ 5]+=task_t4->in[ 4];task_t4->in[ 4]+=task_t4->in[ 3];
task_t4->in[ 3]+=task_t4->in[ 2];task_t4->in[ 2]+=task_t4->in[ 1];
task_t4->in[ 1]+=task_t4->in[ 0];
task_t4->in[17]+=task_t4->in[15];task_t4->in[15]+=task_t4->in[13];
task_t4->in[13]+=task_t4->in[11];task_t4->in[11]+=task_t4->in[ 9];
task_t4->in[ 9]+=task_t4->in[ 7];task_t4->in[7] +=task_t4->in[ 5];
task_t4->in[ 5]+=task_t4->in[ 3];task_t4->in[ 3]+=task_t4->in[ 1];
ipbuf_trycnt = 0;
/*寻找一个尚未使用的ipbuf_d*/
do {
bid = get_free_ipbuf(task);
if(bid >= 0) // valid bid
break;
if(++ipbuf_trycnt >= 100)
return MBCMD_EID_STVBUF;
for(j=0; jin,72);
/*要把in再送回给 ARM端*/
bksnd(task, bid, 36);
/*结束*/
return 0;
}
5-3 双处理器程式开发注意事项
(1)资料型态的不同:
变数的资料型态长度并非一样,比如说在ARM端的int长度为4,但DSP端却是2,所以若ARM丢一个int过去,DSP则需要用long去接,而不能用int去接.
(2)endianism的不同:
注意ARM与DSP的记忆体排列顺序不一样,ARM是big endian,而DSP为little-endian,对於word(16-bits)不会有多大的问题,比如说ARM端丢一个值0x0123,DSP端将接到0x0123,但对於处理32-bits的data,就会出现问题,比如说ARM丢一个值0x01234567给DSP端,则在DSP端看到将是0x45670123,这是由於endianism的不同所造成的.
(3)支援c++不是很完整:
CCS说支援c/c++,但我们实际测试,CCS似乎没有对c++做什0支援,比如说没有支援class.
第六章 效能评估与讨论
任何装置在效能上的表现,我们在乎它处理的速度,CPU的负载,此外,对OMAP平台诉求的行动装置而言,行动装置的耗电量也是很重要的议题.因此在此节,我们会分别评估我们OMAP1510在「速度」,「CPU负载」,「耗电量」来做效能的评估.
6-1 速度
单纯测试ARM与DSP的数学运算速度
Algorithm:

(2)改写的程式,每个granules包含18 * 32 subband samples.,而我们的运算是以subband为单位,所以每个frame我们必须传32次,每次为4*18(bytes)的大小给DSP端做处理,很明显的可以发现对於ARM端与DSP端的沟通,似乎会花很多时间.所以总结起来,我们改完之後的程式似乎可以在改进.
(3)因为卡在splay原始程式码的架构,虽然说可以看出哪里有数学运算,若要照著原来程式架构改写,那必须要传更多的参数到DSP端,我们相信这样可能会造成更大的负担.
6-2 CPU负载
对於CPU的负载,我们只是做了一个简单的测试,利用Linux的指令uptime来监测CPU(ARM)的使用,可以发现对於只是使用ARM与对於同时使用 ARM与DSP的程式而言,可以发现同时使用双处理器减少了CPU的使用率,对於这样的结果,我们可以知道,DSP端可以分担ARM端CPU的使用率,相对的基於DSP需要的功率较低,所以这样能够更省电.
6-3 讨论
6-3.1分工处理的经济效益-Inter-processor communication 的代价
在写双处理器分工的程式之後,我们了解到并不是所有运算都适合拿来做分工处理,DSP处理器在做运算时的确比ARM快,但你还要考量到当要将某部分的资料交由DSP端做分工,不可避免的是你要把资料从ARM端传送过去,并且再接收DSP运算之後回传的结果.
因此有可能,你将一段耗时不多的运算交由DSP运算,它固然运算快了一点,但是Inter-processor communication却耗去它更多的时间,如此一来,不符合经济效益,比起ARM端本身自己来做还不划算.
6-3.2音质v.s 浮点与定点运算
对MP3解码来说,使用定点(Fixed point) 与浮点(Floating point)运算皆可,差别在於「音质」,浮点可使解码的结果较精确,相对的音质会比较好.而定点比较简单,速度会较浮点运算稍快.我们采用的OMAP1510里头的DSP处理器,是德州仪器TMS320系列中的C5000,它并不支援浮点运算,但不同的OMAP处理器,可能采用不同的DSP系列,若是C6000系列就有支援,也因此可以将我们的MP3 Player采取浮点运算,让音质更好.
6-3.3 DSP Gateway架构的限制
我们OMAP双处理器的沟通架构是采用DSP-gateway,因此我们也遵循著其程式架构去改写,便多少受限於这程式架构,像是ARM端和DSP端的沟通单位mailbox它提供的data buffer只有256byte,因此传送资料,参数时不能像一般程式一样随心所欲,需要分批传送,还得在另一端分批接收起来.
6-3.4减少IO沟通
前面讲到双处理器分工,不可避免的就是两者的I/O沟通,此时程式的撰写就需要些技巧,比如说:要传三个阵列时,或许三个可合并在一次传送,而不要分三次传送,当然如此会增加程式的复杂度,因为你在另一端接收时就需要很清楚不同阵列的接受顺序,大小,在做分配.另外,只传送必要的资料,比如说:传三笔资料A,B,C过去处理(C = A / B),此时要回传结果时,A,B就没必要回传,只需传C,这种减少不必要的传送,也是节省IO沟通的一个关键.
6-3.5网路挂载File System的Delay
目前File System使用NFS挂载而非在Flash ROM上面,相信也是一个影响效能的因素,藉由网路线连到NFS Server上的File System是会多一些delay,以下面两图来比较说明:
OMAP board (Flash ROM)
OMAP board (NFS mounting) NFS Server

第一张图是把filesystem放在 ROM上面,而第二张图是利用NFS,我们可以看出利用NFS需要多上额外的传输时间.
侯凯元:
整个专题中,对於嵌入式系统环境发展多了很多经验,像是:处理器的认识,嵌入式工具,trace OS kernel和driver code,双处理程式开发等,能将一个硬体「从无到有」建构出一个完整的环境并开发应用程式,是很有成就感的.做专题的过程遇到问题时,我们会自己思考出一些可能的解决方法,接著就0集资料,学习需要的技术,大胆假设後并尝试,这样的解决问题模式,让我们学习到的经验很多.而吴晓光教授会提供我们「方向」,像是一开始MP3 Player改版後效果不好,老师建议我们可以分析一些数据,後来我们也从这些数据中发现到效能差的症结所在.教授对於做研究的经验,的确是很丰富,值得学习.
黄致远:
这次专题是在做关於嵌入式系统,在这之前,其实我们没什0经验,所以一开始花了许多时间研究摸索.在这专题中,我觉得这是一个新的尝试,而且OMAP发展并没有很久,资料0集相当有限,而且全部都必须从外国网站找到, 顿时觉得英文真的相当重要,因为最新的资讯获得都必须上国外网站.虽然说专题做的时间不到一年,我们也是尽全力的去摸索,不论我们是否成功的完成这个专题,但我觉得在这专题的过程将是一个美好的经验,也是值得的.
参考资料
[1] Craig Hollabaugh , " Embedded Linux-Hardware, Software, and
Interfacing " (2002)
[2] John Lombardo , "Embedded Linux" (2002)
[3]吴贤财 , "数位信号处理实务-通讯应用型DSP" (2001)
[4]台大电机DSP/IC实验室徐志玮 , "离散馀弦转换及其架构" (2002)
[5] Texas Instrument , "OMAP Technology Overview" (2001)
[6] NOKIA research center , "dsp_gateway_specification" (2003)
[7] MPEG Audio standard , ISO/IEC 11172-3 (1993)
[8] CHALMERS University CS Department, "Design and
Implementation of an MPEG-1 Layer III Audio Decoder" (2001)
[9] 中央大学通讯所音视讯处理LAB , "音视讯处理专题MP3随身听" http://roger.ee.ncu.edu.tw/chinese/pcchang/course98b/comsp/mp3/index1.html , (1998)
[10] 德州仪器 , " OMAP 技术概述"
http://www.ti.com.tw/articles/detail.asp sno=13&catalog=4 (2001)
[11] 电子工程专辑 , "下一代开放式多媒体应用平台(OMAP)综述"
http://www.eetc.globalsources.com/ART_8800309801_617717876045.HTM.9dbfb280 , (2003)
[12] NOKIA DSP Gateway Solution http://dspgateway.sourceforge.net/
[13] Texas Instrument http://www.ti.com
[14] MontaVista http://www.mvista.com/
[15] Delphi Inc. http://www.delcomsys.com/
[16]智控科技 http://www.ict.com.tw/
[17]Linux MP3 Player -splay 是以GPL授权的软体
DSP
ARM
PC-file system
I/O device
DSP
ARM
File system on Flash ROM
移植OMAP Linux Kernel
熟悉DSP程式
开发工具CCS
建立嵌入式系统环境
架设ARM与DSP 沟通环境
学习写DSP程式
(使用C语言)
改写MP3 player的ARM端程式
写MP3 player的DSP端程式
测试与debug
DSP enhanced
MP3 player
Trace MP3 player
splay程式码
阅读MP3
ISO标准文件
建立嵌入式系统工具
General-purpose processor
OS adaptor
GPP OS
DSP manager

DSP OS
DSP task and I/O control
OS adaptor
TMS320 DSP
subbandsynthesis()
Dct12()
Extractlayer3()
layer3hybrid()
决定邀由DSP分担MP3解码的程式部分
使用,评估CCS提供的DSP函式库
启动OMAP音效并测试
订好Inter-processor communication scheme
了解MP3 decode,trace解码部分的程式码
效能评估分析
建立并挂载Root档案系统
练习双处理器间
的沟通程式
认识OMAP Architecture
熟悉我们的硬体OMAP Innovator
Dct36()))
output
IMDCT
Windowing
Requantizer,Synthesis filterbank
Huffman decoding
Decode frame header
Decode side information
Decode Main data
Device driver
DSP API
/dev/AP3
/dev/AP2
/dev/AP1
AP1
AP2
AP3
DSP task
Application
ARM Linux
DSP
mailboxx
Interrupt handler
Int handler