使用DM648评估板之程序自启动
1、DM648上电过程说明
DM648评估板的启动过程相比传统的TI DSP设备启动过程稍显复杂。主要是涉及较多的软件和硬件。
评估板上电启动过程如下：
1）评估板上电，MSP430运行进行内部检测并使DM648上电；
2）DSP被设置为NOR快速启动（AIS）方式。DM648的ROM启动装载程序（RBL）将从CE2中读取NOR设备中的内容；
3）NOR存储器的开始存放了作为用户启动程序（UBL）的第二个启动装载程序二进制AIS镜像文件。这个UBL
AIS镜像文件由RBL进行解析；
4）UBL AIS镜像文件执行对DDR2内存和系统时钟的初始化。RBL将装载程序代码和数据到DSP内部缓存（L2）；
5）RBL将控制转到UBL，在DSP缓存中运行；
6）RBL查看NORflash的第二块，搜索演示程序的AIS镜像文件。如果没有找到，UBL将保持在NOR设备的初始处；
7）当程序AIS镜像文件被装载，UBL（更象是RBL）解析AIS镜像文件，并将其装载到DDR2内存。
8）当装载完成，UBL修改DM648内部PINMUX寄存器使能视频3、4端口。同时UBL通过I2C设置外部控制器（MSP430）。在演示程序启动之前这两步必须先完成。
DM648_NORWriter工具用来将两个AIS镜像程序写入DM648评估板的NOR存储器中。写入完成后，将板下电，重新设置开关，就可以自启动程序了。
2、DM648程序烧录过程说明
为了实现DM648的自启动，需要按照下面的步骤进行。注意需要Perl解释程序来运行“create_ais.bat”文件（主要是要调用“genAIS.pl”Perl描述语句）。
1）进入&dvsdk_install_dir&\flashutil目录，在.\DM647_8\CCS\UBL目录中打开UBL工程，从Debug目录拷贝UBL.out文件到&dvsdk_install_dir&
\flashutil目录；
2）拷贝自己的out文件到&dvsdk_install_dir&\flashutil目录；
3）打开命令窗口，如下运行。（以dm648_demo.out为例）：
create_ais.bat dm648_demo
将看到如下输出：
&&&&&&&&&&&
这一步将生成两个AIS文件：UBL.ais and dm648_demo.ais。
4）在&dvsdk_install_dir&\flashutil目录下，进入.\DM647_8\CCS
\DM648_NORWriter目录并打开DM648_NORWriter工程。
5）设置评估板开关到仿真模式：
■ SW2[1..8] =
■ SW3[1..8] =
6）评估板上电，在CCS中与之相连。
7）装载DM648_NORWriter.out文件并执行。
8）CCS中的显示如下：
9）在生成对话框中输入UBL镜像文件如下：
10）UBL镜像文件将传输到评估板，NOR将被擦写：
11）当UBL文件写完，将要求输入第二个镜像文件，对话框如下：
12）当程序的应用文件镜像写完，显示信息如下：
13）完成后，断开CCS连接，重新设置评估板开关如下：
■ SW2[1..8] =
■ SW3[1..8] =
14）开关设置好后，重启评估板。
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。From Texas Instruments Wiki
The Digital Video Software Development Kit (DVSDK) is common term describing a set of software and data for development targetting for misc TI processors. Only few devices are supported by a specific version. Newer versions are typically for newer chip designs. Device support has been added and dropped every now and then in the long term development of packages bearing this label.
at Update Advisor
Note: The above linked page states that there are currently no community linux based DVSDKs. This might be outdated.
The latest inclusion of a specific device type is highlighted in bold. RN stands for release notes. DL stands for download.
DSP/BIOS DVSDK v1.01 (Supports DM6437)
DSP/BIOS DVSDK v1.10 (Supports DM648)
DSP/BIOS DVSDK v1.11 (Supports DM648/DM6437, with combined )
(for v1.30,v1.40,v2.00)
MVL-based DVSDK v1.30 (Supports DM6446 and DM355)
MVL-based DVSDK v1.40 (Supports DM6467)
MVL-based DVSDK v2.00 (Supports DM355, DM6446, DM6467) DL:
Linux DVSDK v2.05 (Supports DM357)
Linux DVSDK v2.10 (Supports DM365) DL:
Linux DVSDK v3.01 (Supports OMAP3530 and OMAP3525; special support for OMAP35x EVM)
Linux DVSDK v3.10 (Supports DM6467T and DM355) DL:
(Supports TMS320DM365, OMAPL138, TMS320DM3730, OMAP3530)
(Supports TMS320DM365, OMAP-L138, TMS320DM3730/25, OMAP3530/25), see also
(Supports DM365/368, OMAP-L138, TMS320DM3730/25)
DVSDK for Windows CE 5.0
DVSDK for Windows CE 6.0TMS320DM368 数字媒体片上系统 (DMSoC)_BDTIC代理TMS320DM368
TMS320DM368 数字媒体片上系统 (DMSoC)
Developers can now deliver crystal clear multi-format video at up to 1080p
H.264 at 30fps (encode and closed-looped decode) in their digital video designs
without concerns of video format support, constrained network bandwidth, limited
system storage capacity or cost with the new TMS320DM368 DaVinci(TM) video
processors from Texas Instruments Incorporated (TI).
The DM368 is capable of achieving HD video processing at 1080p 30fps H.264
and is completely pin-to-pin compatible with the DM365 processors, using the
same ARM926EJ-S core running at 432 MHz. This ARM9-based DM368 device supports
production-qualified H.264BP/MP/HP, MPEG-4, MPEG-2, MJPEG and VC1/WMV9 codecs
providing customers with the flexibility to select the right video codec for
their application
Applications
Audio,Consumer Electronics,Energy,Industrial,Security,Video and Imaging
Operating Systems
Neutrino,PrOS,Integrity,Windows Embedded CE,Linux
ARM MHz (Max.)
ARM MIPS (Max.)
Video Acceleration
1 MJCP,1 HDVICP
Video Capability
Decode,Encode Image Enhance,Single channel
TI Video Codecs
H.264BP/MP/HP,MPEG-4,MPEG-2,MJPEG,VC1/WMV9
Video Resolution/Frame Rate
1080p,30 FPS
Other Hardware Acceleration
OSD,Previewer,Resizer
On-Chip L1 Cache
32 KB (ARM9)
General Purpose Memory
Async SRAM,GPMC,NAND Flash,NOR Flash,OneNAND,SmartMedia/xD
1 16-bit (LPDDR-336, DDR2-680)
UART (SCI)
Video Port (Configurable)
1 Dedicated Input,1 Dedicated Output
IO Supply (V)
Trace Enabled
Pin/Package
TMS320DM368 特性
Highlights
High-Performance Digital Media System-on-Chip (DMSoC)
432-MHz ARM926EJ-S Clock Rate
Two Video Image Co-processors (HDVICP, MJCP) Engines
Supports a Range of Encode, Decode and Video Quality Operations
Video Processing Subsystem
HW Face Detect Engine
Resize Engine from 1/16x to 8x
16-Bit Parallel AFE (Analog Front-End) Interface Up to 120 MHz
4:2:2 (8-/16-bit) Interface
8-/16-bit YCC and Up to 24-Bit RGB888 Digital Output
3 DACs for HD Analog Video Output
Hardware On-Screen Display (OSD)
Capable of 1080p 30fps H.264 video processing
Peripherals include EMAC, USB 2.0 OTG, DDR2/NAND, 5 SPIs, 2 UARTs, 2
MMC/SD/SDIO, Key Scan
8 Different Boot Modes and Configurable Power-Saving Modes
Pin-to-pin and software compatible with DM365
Extended temperature (-40°C - 85°C) available
3.3-V and 1.8-V I/O, 1.35-V Core
338-Pin Ball Grid Array at 65nm Process Technology
TMS320DM368 芯片订购指南
封装 | 引脚
封装数量 | 封装载体
TMS320DM368ZCE
29.00 | 1ku
TMS320DM368ZCED
34.80 | 1ku
TMS320DM368ZCEDF
36.30 | 1ku
TMS320DM368ZCEF
30.50 | 1ku
TMS320DM368 质量与无铅数据
铅/焊球涂层
MSL 等级/回流焊峰
环保信息与无铅 (Pb-free)
DPPM / MTBF / FIT 率
TMS320DM368ZCE
Green (RoHS & no Sb/Br)
Level-3-260C-168 HR
TMS320DM368ZCE
TMS320DM368ZCE
TMS320DM368ZCED
Green (RoHS & no Sb/Br)
Level-3-260C-168 HR
TMS320DM368ZCED
TMS320DM368ZCED
TMS320DM368ZCEDF
Green (RoHS & no Sb/Br)
Level-3-260C-168 HR
TMS320DM368ZCEDF
TMS320DM368ZCEDF
TMS320DM368ZCEF
Green (RoHS & no Sb/Br)
Level-3-260C-168 HR
TMS320DM368ZCEF
TMS320DM368ZCEF
TMS320DM368 应用技术支持与电子电路设计开发资源下载
TMS320DM368 工具与软件
软件/工具类型
TMS320DM368 评估模块
开发电路板/EVM
Code Composer Studio (CCStudio) 集成开发环境 (IDE) v4.x
Code Composer Studio(TM) IDE
XDS510 类仿真器
仿真器/分析仪
DM6467T SD 子卡
TMS320DM6467 引脚 Mux 实用程序
实用程序/插件
基于 C64x+
器件的加密（OMAP35x、C645x、C647x、DM646x、DM644x, DM643x、DM674x、DM648）
演示 - DM6467 应用示例和演示代码
用于 TI DSP+ARM 处理器的 C6EZAccel
软件开发工具
用于 TMS320C64x+ 和 TMS320C55x
处理器的电信和媒体库 - FAXLIB、VoLIB 和 AEC/AER
AM/DM37x 评估模块
开发电路板/EVM
DM6467T 数字视频评估模块
开发电路板/EVM
DM814x/AM387x 评估模块
开发电路板/EVM
DM816x/C6A816x/AM389x 评估模块
开发电路板/EVM
THS8135 评估模块
开发电路板/EVM
TVP5151 评估模块
开发电路板/EVM
TVP5158 评估模块
开发电路板/EVM
编解码器 - 针对 DM6467 器件进行了优化
算法/ 解码器
编解码器 - 音频、视频、语音 - 适用于基于 C64x+
的器件（OMAP35x、C645x、C647x、DM646、DM644x、DM643x）
算法/ 解码器
Linux 数字视频软件开发套件 (DVSDK)
v2x/v3x - 达芬奇数字媒体处理器
软件开发套件 (SDK)
QQ: ；TradeManager
深圳***：136
西安***：130
&1993 - 2016 & BDTIC 版权所有转：嵌入式Processor决战2012，达芬奇5年7宗罪
看完前线专业视角观点，虽然我做过SOC相关项目，但16位远远落后于当前64位和32位市场，处理器芯片市场1.2GHZ已经遭遇瓶颈，达到饱和，未来数字处理器的发展和前景何在，似乎已经完全成熟化，但核心思想，结构和算法，我相信一定不会没落。也就是说，最高精技
看完前线专业视角观点，虽然我做过SOC相关项目，但16位远远落后于当前64位和32位市场，处理器芯片市场1.2GHZ已经遭遇瓶颈，达到饱和，未来数字处理器的发展和前景何在，似乎已经完全成熟化，但核心思想，结构和算法，我相信一定不会没落。也就是说，最高精技术含量的DSP芯片，已经没有什么设计价值，但技术一定是值得借鉴的。
换言之，即使我知道高精技术芯片一出来就没有二次开发的必要，但高效结构和精密算法蕴含其中。也就是说，在自己能达到的范围内进行探索和挖掘，虽然并不能把它作为一项职业。
芯片是产业链上游重要的一个环节，一颗小小的芯片具有极高的技术含量和价值，半导体行业每年都会有一个各大厂商营业额的排名，除去2009年，常年盘踞在前三名位置的分别是英特尔，三星半导体和德州仪器，英特尔凭借的是桌面处理器，三星半导体凭借的是其全面的存储器产品线，德州仪器则是凭借模拟器件，嵌入式处理器和无线半导体这&三驾马车&。
终端是产业链中上游重要的一个环节，终端厂商用芯片设计出嵌入式硬件，并且基于该硬件开发相应的嵌入式软件，从而构成一个完整的嵌入式终端产品，形象的说就是一块电路板套一个外壳，这里面最重要的一个核心价值的产生就是附加在嵌入式可编程器件上的软件，成为嵌入式软件。
系统是产业链中下游重要的一个环节，系统厂商通过平台软件使得多个嵌入式终端通过互联网进行信息的传递，从而为最终用户提供产品和服务。
嵌入式产业系统 = 芯片 + 嵌入式终端 + 平台软件
达芬奇处理器最具革命性意义的就是它的全平台开放性，不同于用硬件直接做多媒体加速的应用处理器，达芬奇处理器提供的ARM，DSP和VICP是三个全部开放且可编程的内核。达芬奇技术的核心其实并不在于硅片本身，而是基于Linux的那套软件框架，它把一个基于多媒体应用的嵌入式软件抽象为应用软件和算法软件，采用CodecEngine框架组件规范了算法软件的开发标准（xDAIS）和统一接口（xDM），应用软件通过CodecEngine来调用算法软件，在这个层面上，应用软件只运行于Linux之上，并不关心Linux运行于何种处理器内核上，算法软件被CodecEngine统一管理，所以应用软件也无需关心算法软件运行于何种处理器内核上。
层出不穷的内核Bug和匮乏的独立开发DSP端算法的资源可是苦了做产品的企业，光是一个Audio OSS全双工的Bug就愣是N个月没有给出完全搞定的Patch，那个时候可真是一个内核升级的Patch都十分抢手，更别说拥有Linux下的cgtools和dspbios***包可以笑傲江湖
遥想当年，华旗推出的基于DM6441的高端MP5产品也是名噪一时，后来，时代飞腾又基于DM6441推出了网络电视一体机的方案，但是DM6441的价格居高不下使得这个曾经是TI阵营王牌IDH的公司彻底转向Telechips的平台，笔者在时代飞腾的一个朋友抱怨到，TI一颗芯片都赶上别人的一个BOM了。那个时候我就在想，究竟怎样的附加值和商业模式才能击碎消费市场产业链的利润&微笑曲线&，还是终究在消费市场做IDH就是一个利润夹缝中苟延残喘但又创造着将冰冷的芯片变成有生命力产品奇迹的商业行为？
伴随着DM643x处理器出现的还有一个在技术上非常拉风的东西，那就是跑在DSP内核上的Linux虚拟机，这是一家叫做Virtuallogix的公司做的软件产品，它可以使得DSP支持Linux，这再一次证明了TI想在Linux下统一管理和开发它的全部嵌入式处理器的软件框架战略，在前面提到过DVSDK里的一个组件叫做CodecEngine，它可以使得应用软件通过RPC调用算法软件完成多媒体算法的调用
DM643x因为有着比DM642更先进的DSP内核架构和达芬奇响亮的名头走进了千家万户，在终于找到了CSL并且抛弃了虚拟机之后，工程师们又开始抱怨，为什么DM6437只有一个VPFE而并非像DM642有多个VPort呢，这对处理多路视频将是多么的复杂，于是DM643x被打入冷宫，直到DM3xx应用处理器的IPNC大行其道，才被重新定为视频分析协处理器，视频分析软件供应商ObjectVideo将DM643x做成独立的视频分析模块，但阻碍这颗达芬奇处理器涅磐的依然是ObjectVideo昂贵的软件入门费和版税。
DM648横空出世，这是一个至今已经可以跑到1.1GHz的DSP处理器，它集成了2个千兆以太网接口和5个VPort视频口，DM648才是真正的将DM642精神发扬光大的产品。在万众瞩目下，一个奇怪的事情又发生了，DM648的开发板居然不是TI御用的Spectrum公司设计的，相关的设计资料也是乏善可陈，至今仍然想不通为什么DM648为何落得如此下场，国内第三方做DM648开发板的跟DM6446简直不在一个数量级。
TI或许已经意识到了在中国这样一个神奇的土地上，有这样一个潜规则，那就是只有硬件是可以卖钱的，硬件上跑的所有东西你都要送我。于是TI开始做出这样一个决定，Linux内核维护从以MonvtaVista为主树转移到以自己维护的内核为主树，逐渐往Community Linux靠拢，彻底摆脱MontaVista；于是TI开始做出这样一个决定，自己做Codec，因为客户听到第三方Codec昂贵的入门费统统都吓跑，自己去做有中国特色的Codec去了，TI可郁闷了，这得做到猴年马月才能量产，于是N多项目胎死腹中。
Ateme还是转向FPGA平台，Ittiam传言准备自己做ASIC，Ingenient则被Sasken收购，而此时的时代飞腾，则彻底放弃了TI的平台，转向更加经济实惠的Telechips和Marvell，于是，TI的Codec阵营就在这一年土崩瓦解。
最后TI终于祭出大招，OMAP3530的BeagleBoard以一种社区开源模式面世，所有的硬件设计源文件以及驱动和操作系统都可以从网络社区下载
在2009年的TI开发商大会上，Cortex-A8内核确实是独领风骚，OMAP阵营的参展商一举压倒了DaVinci参展商，诸多的Android，WinCE独立软件供应商和无线模组供应商开始加入TI的阵营。
TI在DM355处理器内部集成了一个叫做ISP的硬件影像处理单元，可以直接支持RAW格式数据的处理，我们姑且管这一块叫做影像预处理，有了ISP，DM355处理器就可以无缝的对接各种图像传感器了。再来看看图像传感器供应商，Aptina的传感器一般叫做Sensor，可以直接输出RAW格式的数据，Ovt的传感器一般叫做SoC，内置了ISP，低分辨率的产品可以直接输出YUV的数据，高分辨率的产品也是输出RAW格式数据。不知是因为TI和Aptina高层的关系很好，还是为了彰显DM355处理器ISP的英明神武，在Appro的这个参考设计里选择了Aptina公司的MT9P031 5MP传感器，专门使用DM355的ISP开发了针对MT9P031 CMOS图像传感器的影像预处理算法。
TI认为自己的这番努力已经秒杀了掌握最先进ISP技术的日系厂商，成功的把DSC的成像技术移植到了IPNC，势必会引爆一个巨大的市场，高清视频，极低的成本，成熟的ISP技术，甚至连镜头和外壳连带完整的硬件参考设计都已经准备就绪
什么叫方案知道么？只要注入一笔钱，再找个工厂一量产，产品和利润就出来了，我们做方案的口号就是，不求最好，但求最快！是的，当时笔者还真是听说深圳有人直接拿Appro的这个参考设计去工厂生产，一个非常典型的深圳市客户，他们崇拜的是MTK式的神话，他们需要的是一个可以马上量产的方案，他们需要的是一个可以带动生产力和现金流的Turn-Key-Solution，他们的特点就是简单快速，薄利多销。
从技术角度看，DM355的功耗和性价比还是非常不错的，采用了0.65mm的点距，内建了ISP装置得以处理Aptina的5MP像素传感器的RAW格式数据，该传感器使用了2x2的binning模式来增强成像质量，可以输出720P30的MPEG-4视频流。但遭人诟病的是，DM355内部的ISP行缓存不够长，在做5MP抓拍的时候，需要2-Pass才能完成处理，2-Pass就是先把图像采集到内存，上半边通过ISP处理一下，下半边再通过ISP处理一下，也正巧了，赶上那年交通行业的相机都要5MP抓拍，惹得全国上下用DM355做相机的厂商怨声载道。
后来的DM365和DM368时代，Ambrella和MG3500已经可以在这个市场分到一杯羹，TI人无我有的战略优势丧失殆尽，顿时变成了人有我优。。。
相比于Ambrella的IPNC方案和海斯的DVR方案，TI的参考设计又明显缺乏成熟的&山寨化&软件；纵观跟进TI的烈士般的公司们，累的跳楼的心都有了，光是那一套套不一样的DVSDK，一堆堆形形***的Patch，就已然头昏脑胀了。。。
DSP这种处理器架构还能保持多久的生命力是一个值得探讨的问题，嵌入式处理器市场的竞争本质还是架构之争。
首先在C64x和C64x+的DSP内核架构之后，又推出了C674x+内核架构，该架构统一了浮点DSP和定点DSP内核；其次在DM8168和OMAP4处理器上，TI则会统一硬件协处理器的架构，即OMAP4和DM8168都采用IVA-HD这种相同的硬件加速器；至此，TI在SoC上已经形成了C674x+Cortex+IVA-HD的统一架构SoC雏形。
ADI公司早在若干年前就关闭了以色列的TigerSharc设计中心，其理由是，该处理器已经登峰造极，没有再发展的必要；在桌面处理器市场，主频提升早已遭遇瓶颈，多核心时代正在到来，而ARM此时已经不声不响迈入双核2GHz的Cortex-A9时代。TI的DSP也是如此，C6000架构已经成熟多年，1.2GHz似乎已经是不可逾越之极限，于是2009年TI发布了3个1.2GHz核心的高性能多核DSP处理器TMS320C6474，这也是一颗从垂直行业市场拿到通用市场的处理器。
但恐怕由于功耗的原因，基于65nm工艺的C647x系列很难再有突破。多核心DSP未来的道路确实很艰难，因为它已经处于一个非主流的位置，虽然不排除在更先进的工艺节点上植入更多的DSP内核甚至是Cortex-A9内核完成统一处理器架构和软件框架的疯狂构想。
Xilinx在SoPC的战略上无疑是成功的，它选择了同样昂贵，功耗很高但同时性能也很高的PPC硬核，从Virtex-II一直到Virtex-5的产品中都可以看到集成PPC硬核的产品，但是这一切都将在28nm节点工艺改变，在28nm技术上，Xilinx选择了高性能低功耗的工艺，而Altera则选择了更高性能但高功耗的工艺。因为在28nm，Xilinx将植入Cortex-A9硬核处理器，创造真正的低成本，低功耗的SoPC产品，继续向嵌入式市场挺进，试想如果一颗集成了Cortex-A9的SoPC芯片售价15美金，你还会选择相同价位的SoC吗？
你最喜欢的