L6218E: Image$$ZI$$Limit
Posted by gavinkwoe
昨天遇到一个十分麻烦的问题，我把MTK编译时遇到这样的错误：
Error : L6218E: Undefined symbol Image$$ZI$$Limit (referred from sys_stackheap.o).
Not enough information to produce a SYMDEFs file.
而没有这三个：
Not enough information to list image symbols.
Not enough information to list the image map.
Not enough information to list the image sizes and/or totals.
网上只有两种解释，是这样：
1. reimplement __user_initial_stackheap()
解决办法大概意思是重新装配__user_initial_stackheap()函数。
2.分配内存的时候,要分配内存的结构中使用了ARM不支持的数据类型.通常定义了结构体的指针，然后用
malloc分配空间时为结构体类型指针，而ARM不支持这种数据类型，所以会有这种错误。解决办法：用
typedef预定义这个结构类型，使得编译器识别这种类型。
第一种方法离我太远，应该不会涉及到；
第二种方法试过，没用，但我也大概知道方向是malloc函数的问题。
今天终于解决：
这个问题是由于代码或者Lib中调用了 C Lib的malloc或者类似于strdup，printf 这样的会调用malloc的
C Lib function 引起的。MTK Platform不支持 C lib的malloc，而用 Ctrl Buffer机制代替了malloc，
以便于调试memory leak问题。MTK中的Osl层有专门处理内存的函数，于是我想，我用malloc是跳过Osl层
直接分配内存，这样没有经过系统处理，危险性大。所以我用系统自带的OslMalloc和OslMfree来处理内
存空间，问题解决。
山寨机教父蔡明介:联发科10年迅速崛起的秘诀
Posted by gavinkwoe
“常常有人问我,联发科在过去10年里迅速崛起,有什么秘诀?并且希望这些’秘诀’对正在快速发展中的中国大陆芯片企业有所启发.”给人印象深刻的一副标志性的大眼镜,从外表看,联发科技董事长蔡明介并不具备在商场上拼杀的枭雄造型.然而,他却是台湾赴美引进半导体技术的先驱,被誉为台湾集成电路设计“教父”.
1995年蔡明介领导台湾“联华电子”的集成电路设计部门独立创业，成立了“联发科技”的前 身多媒体小组，联华电子是仅次于台积电的全球第二大流片厂。IC行业流传着一句难以溯源的话———现在的芯片业，每个非大厂都不希望联发科涉及自己的领 域，那样自己就“离死不远了”。
并非危言耸听，经历10余年的发展，目前联发科已成为世界顶尖的IC专业设计公司，位居全球 消费性IC片组的领航地位。产品领域覆盖数码消费、数字电视、光储存、无线通讯等多个系列，是亚洲唯一连续六年蝉联全球前十大IC设计公司唯一的华人企 业，被美国《福布斯》杂志评为“亚洲企业50强”。
没有听说过联发科，只要是对手机产业链稍有了解的人，也会对MTK这三个字母的组合有些印象。MTK是联发科技股份有限公司的英文简称，英文全称叫MediaTek.
「杀手锏」一站式方案
或许有人不太喜欢这家公司，因为从早年的黑手机到现在的山寨机，草莽气息背后是MTK方案被广泛应用。波导、夏新，老牌手机厂商令人堪忧的一份份财务报告中总会附带“受到黑手机、山寨机冲击”的说明，MTK可被视作始作俑者之一。
但你不得不佩服MTK的创新和成功，甚至也找不出更多口诛笔伐的理由。因为MTK的存在，近年来国内手机产业进入了前所未有的蓬勃发展阶段。事实上MTK除了为山寨机提供方案，也同时为正规厂商提供全面解决方案，包括近两年迅速崛起的天语、金立等正规品牌。
“我们有个客户的工程师曾经很形象地打了个比方，他说MTK的解决方案更像是一本”烹饪手册 “，它只能保证厨师不会把鱼香肉丝做成京酱肉丝，至于这道菜做出来的色香味如何，那还是看终端厂商的水准。”联发科首席财务官兼新闻发言人喻铭铎曾向本报 记者表示，MTK提供的是一个把厂商开发过程中可能遇到的问题尽量提前考虑到的参考性的解决方案。厂商在开发过程中如果遇到一些原先技术能力较为薄弱的地 方，可以从这个参考性的解决方案中获得借鉴与补充，从而不断弥补原来的不足。
凭借这种“菜谱”方式，MTK在大陆市场上结结实实地击败了众多国际芯片厂商。操作软件，甚至液晶、摄像头等部件，MTK都可以“一站解决”，大大缩短了手机的生产环节并降低了研发成本。这正是Turnkeysolution（一站式方案）模式。
Turnkeysolution正是MTK手机平台的核心。在这套解决方案中，将手机芯片和 手机软件平台预先整合到一起。这种方案可以使终端厂商节约成本，加速产品上市周期。MTK公司的产品因为集成较多的多媒体功能和较低的价格在大陆手机公司 和手机设计公司得到广泛的应用。加上MTK的完工率较高，基本上在60%以上，这样手机厂商拿到手机平台基本上就是一个半成品，只要稍稍的加工就可上架出 货了。
数年前，德州仪器（TI）的LoCosto、OMAP平台，英飞凌的ULC解决方案，还一度是这些国际知名厂商广泛采用的模式。然而MTKTurnkey方案的巨大成功则证明了在这一领域平台技术不再是TI、英飞凌这些巨头的专属。
「性价比」到底到什么程度
1999年，当时的联发科在台湾科技行业中还仅是一家生产光存储和DVD芯片的二线厂商。然而当时，蔡明介看中了利润更加丰厚的手机芯片业务，恰逢中国手机市场进入第一次高速增长期，他的眼光自然而然地落在了中国大陆市场。
2001年开始，MTK开始在手机行业逐渐渗透Turnkeysolutio模式，这种模式内蕴着极高的性价比。在国内手机制造仍处于朦胧阶段的时刻，这种性价比着实让人难以抗拒。
号称2007年全年销量达到1500万台的天宇朗通便广泛采用了MTK的产品。“感谢 MTK，感谢台湾人。”天宇朗通销售总监卢伟冰在今年天津手机展新闻发布会上曾表示，中国拥有全球配套最完善的手机产业集群。都说手机没有核心技术，都说 在欧美人的手里，大家都觉得很失望。但是我们的台湾人做了很多基础芯片研究，MTK的问世把没有技术、没有解决方案这个历史进行了改写。
天宇朗通是近年来当之无愧的国产手机黑马。在其面向下游的销售模式中，和MTK的高性价比、 低价出牌也有着惊人的相似。本地一位零售商代表向记者表示，天宇朗通完全摒弃了过去手机企业的价保模式，取而代之的是以较低的价格出货给代理商，再由下游 定价。“一款产品我们的进货价若只有300元，定价600元销售也有可能，毕竟同等功能配置的洋品牌还要贵上至少100元。”
300元，只是手机厂商给予渠道的价格，他们从MTK手中获得的方案呢，性价比究竟能高到什 么程度？以行业内最普遍使用的联发科（MTK）低端方案6223为代表。可支持T-flash扩展卡，彩屏，具备自动应答留言机功能，键盘采用动感炫灯。 如量产二十万台，单价在14美金左右，不到人民币100元。
同样是在2001年，联发科在台湾上市，更素有“台湾股王”之称。直至2007年，其营业收 入已达到新台币804.09亿元，较2006年增长51%.根据最新市场资料显示，2007年联发科年手机晶片出货量高达1.5亿颗，全球市场占有率近 14%，仅次于德州仪器及高通。
「声誉」骂名、美名
联发科真正开始在大陆市场上崭露头角，2005年是关键年。在那个还没有取消手机核准制度的 年代，早前依靠贴牌韩国方案而迅速崛起的国产手机在洋品牌的全线反攻下，跌入了全线溃败的谷底。夏新、波导、TCL，大量的民族手机品牌惨遭洗牌，国产手 机也因此背上了“质量不好”的包袱。
然而就在这一时期，具有中国特色的黑手机跃上了手机产业的历史舞台。这些手机主要通过模仿知 名品牌的外形。以及低廉的价格来吸引消费者。黑手机一词诞生于联发科Turnkeysolutio模式广泛进入中国市场之前，但因为MTK的存在，黑手机 发生了“革命性”的变化。MTK也因此背上了“黑手机之父”的骂名。
早期的黑手机，在没有采用MTK方案之前规模并不大，以翻新、通过各种渠道寻找廉价方案为主 要表相。在MTK全面解决方案进入中国市场后，生产方一次过便可以获得包括基带芯片、操作软件，甚至液晶显示屏、摄像头等部件等全套或半套解决方案。一举 将原来的6-9个月甚至是一年的手机研发周期，缩短到了3个月以内。
直至国家取消手机牌照核准制度，黑手机这个称谓已不合时宜，源于MP3行业的“山寨”一词取而代之。不过MTK并未因此而被改称作“山寨机之父”。在国产手机产业发展到目前的规模，讨论MTK的成分变得丝毫没有意义。
可以说，黑手机、山寨机空前的泛滥与MTK有着必然联系，但无论从技术还是道德的范畴，如今 更为理性的观点大都认为不应该由MTK为这种泛滥负责。Turnkeysolutio模式的崛起、MTK的成功，背后更多体现的是手机行业新兴市场飞速发 展的带动和技术的成熟和全球化，技术门槛降低后的必然结果。
至于黑手机、山寨机偷税漏税等问题，更多体现的是法律环境的不健全。在知识产权保护、税收、产品质量、工人权益、生产和市场准入、走私控制等方面所存在的漏洞，而这些实际才是黑手机为生产、流通和销售创造优越环境的根本。
MTK从未为任何有关于自己的报道辩驳，但依然落入了尴尬的境地。这种情况目前随着越来越多的品牌厂商采用其方案而获得改善，MTK的模式更成为不少IC企业效仿的对象。
联发科发展的几个瞬间
1995年，成立……
蔡明介领导台湾“联华电子”的集成电路设计部门独立创业，成立了“联发科技”的前身多媒体小组，初始只有20余人。
2001年，钟情手机芯片
联发科在台湾成功上市，51岁的蔡明介则必须做出选择———创业前4年，联发科必须在CD- ROM、CD-RW以及DVD-ROM等几代芯片的稳定发展后找到下一个拳头产品，这可以说是决定联发科生死的问题。按照蔡明介经验，一定要符合市场足够 大；有一定的技术门槛和别人拉开差距；和联发科原来的开发技术有一定的相关性这三个标准。
经过内部激烈的讨论后，联发科决定投入手机芯片研发。当时台湾手机代工行业逐渐兴起，作为上游，联发科最终决定跟着客户走，杀入手机芯片领域。
2003-2004年，成长的低谷
是联发科颇为难熬的一段日子，手机行业的前景在哪里？当时，处于中游的台湾手机代工企业活得并不好，选定道路的联发科则不得不加大研发费用的投入。
此时，联发科之前的光存储和DVD产品市场已经逐渐饱和，价格开始下滑。手机芯片虽然在 2003年底开发成功，却迟迟无法打开市场。更重要的是，想“跟着”的那些客户并没有预想的成功，联发科必须去寻找新的客户。2004年四季度，代工行业 的连锁反应落在了联发科身上，其毛利率大跌40%%，在投资人会议上，蔡明介甚至亲自拿出采用自家芯片的手机进行演示，希望能够给投资人以信心。
据统计，当年全球IC设计产业总体增长率为27%，而联发科营收仅增长了5.23%.
2004年，猛虎出笼……
最终台湾一家叫达智的手机制造小公司因为无力采购国际IC设计巨头的产品，在实属无奈的情况 下采用了联发科的方案。由于当时手机IC设计领域并没有重视媒体功能的植入，大多仍采用双芯片分别控制通话和多媒体的设计，成本较高。而联发科因为此前做 CD、DVD芯片的开发，有这方面基础，迅速打开了市场。
2008年，跻身世界前三
手机芯片部门的收入已经占到联发科营收的50%以上，联发科也仅次于德州仪器及高通，跻身世界前三大IC手机设计厂商。
文/《南方都市报》
[转] 实现动态加载VXWORKS .O/.OUT模块
Posted by gavinkwoe
转至：http://www.cnblogs.com/hpunix/articles/355758.html
整个过程为：
创建文件系统–》下载文件–》加载模块–》查找符号地址并执行
以下为演示该过程的一个简易实现文件，有使用或者引用的话，也
打个招呼，或者给评论一下：
==============START OF THE FILE=============
/*********************************************************
* 版权所有 NP系统工作室。
*
* 文件名称： \FilseSystemCreate.c
* 文件标识：
* 内容摘要： 创建文件系统，在系统启动之后保存文件
* 其它说明：
* 当前版本： S 1.0
* 作 者： william
* 完成日期： 2005-10-12 17:04
* 当前责任人-1：william
*
* 修改记录1：
* 修改日期：2006-3-21 12:00
* 版 本 号：S 1.0
* 修 改 人：william
* 修改内容：创建
* 修改记录2：
**********************************************************/
#include <taskLib.h>
#include <vxWorks.h>
#include <stdio.h>
#include <string.h>
#include <ioLib.h >
#include <symLib.h >
#include <loadlib.h >
#include “dosFsLib.h”
#include “ramDrv.h”
#include “usrLib.h”
typedef int STATUS;
#define ERROR -1
#define OK 0
#define DIAG_RAM_DISK_SIZE (0×100000*10) /* 64M */
#define DIAG_RAM_DISK_NAME “/selfdev/”
STATUS FileSystem_Init()
{
BLK_DEV *pBlkDev;
char *pFileSysRamDiskBase = NULL;
ramDrv();
pFileSysRamDiskBase = malloc(DIAG_RAM_DISK_SIZE);
if(NULL == pFileSysRamDiskBase)
return ERROR;
bzero(pFileSysRamDiskBase,DIAG_RAM_DISK_SIZE);
pBlkDev = ramDevCreate( pFileSysRamDiskBase,
/* start address */
512,
/* sector size */
64,
/* sectors per track */
(int)(DIAG_RAM_DISK_SIZE/512),
/* total sectors 64 MBytes */
0);
/* offset */
if(NULL == pBlkDev)
{
free(pFileSysRamDiskBase);
return ERROR;
}
if(NULL == dosFsMkfs (DIAG_RAM_DISK_NAME, pBlkDev))
{
free(pFileSysRamDiskBase);
return ERROR;
}
return OK;
}
extern SYMTAB_ID sysSymTbl ;
void runModule()
{
STATUS status=ERROR;
int fd;
MODULE_ID hModule ;
FUNCPTR taskEntry = NULL ;
SYM_TYPE * pType ;
if ((fd = open(”/selfdev/youown.o”, O_RDONLY, 0)) < 0)
{
printf(”\nCannot open memory device.\n”);
goto done;
}
if ((hModule=loadModule(fd,LOAD_ALL_SYMBOLS))==NULL)
{
printf(”loadModule error = 0x%x.\n”,errno) ;
goto done;
}
status = symFindByName(sysSymTbl,
“willian_test”,
(char **)&taskEntry,pType ) ;
if (status==ERROR)
{
printf(”symFindByName error=%d\\n”, errno) ;
goto done;
}
else
{
printf(”taskEntryr=0x%x, type=%d\n.”,
(int)taskEntry,(int)*pType);
status = taskSpawn(”test1″,
100,
0,
30000,
taskEntry,
0,0,0,0,0,0,0,0,0,0) ;
if (status==ERROR)
{
printf(”taskSpawn error=%d\n”,errno) ;
goto done;
}
}
done:
if (fd >= 0)
close(fd);
}
int downLoadModules(
char *hostName,
char *srcfileName,
char *destfileName,
char *usr,
char *passwd)
{
………
/*实现下载远端PC模块到本地机*/
return (filesize);
}
STATUS test_dynamic_download()
{
STATUE status = OK;
int fileLenth = 0;
status = FileSystem_Init();
if(status == ERROR)
{
printf(”\nerror occured during init file system\n”);
return ERROK;
}
fileLenth = downLoadModules(”winner2″,
“youown.o”,
“/selfdev/youown.o”,
“target”,
“target”);
if(ERROR == fileLenth)
{
printf(”\nSome error occured when download files\n”);
return ERROK;
}
else
{
if(0 == fileLenth)
{
return OK;
}
}
runModule();
}
=============END OF THE FILE==========
几个需要注意的问题：
1：在文件系统初始化中使用的是MALLOC，该部分是使用的实际是
BSP的空间在实际申请的过程中一定要根据自己可能拷贝的文
件大小和实际的BSP的空间
2：在创建文件系统之后，可以查看该目录的文件列表，或者执行
COPY，前提是必须在TORNADO中选择初始化文件系统组件；
3：在下载文件的过程中，有的BSP初始化已经可以直接通过COPY
在远端FTP SERVER直接拷贝文件，比如：
copy “youown.o”,”/selfdev/youown.o”
这种情况没有必要再调用downLoadModules，至于如何使能，
大家关注的话可以在后边对其专门论述。
4：加载模块的过程可以调用如下代码：
if ((hModule=loadModule(fd,LOAD_ALL_SYMBOLS))==NULL)
同样也可以如下实现：
ld(1,0,”/selfdev/youown.o”);
至于各个参数什么意思，参考HELP就可以找到结论了！
5：在 status = symFindByName(sysSymTbl,
“willian_test”,
(char **)&taskEntry,pType ) ;
中，有可能实际返回错误，但是通过lkup 是可以实际找到的，
对于这个问题，我看网上答案比较少，原因是这样的：
假如你在主机运行shell,默认的远端目标机是没有符号表
（symbol table）的，只有在主机的shell上，你运行LKUP的
时候，才能找到这个符号，不信你可以这样尝试一下，打开两
个SHELL，一个通过串口，一个通过TORNADO的网口，你在其中
一个中能够使用LKUP找到，而在另外一个则不能找到，是不是
呀？？
接下来继续解释，我们的symFindByName是在目标机器上
执行的，所以自然的就返回错误了，也是没有找到了！
解决方法是这样的：在目标机中包含符号表，同时将其和
主机保持同步。
Wind River told us to include all this defines in the
config files for the target:
#define INCLUDE_SYM_TBL_SYNC
#define INCLUDE_LOADER
/* object module loading */
#define INCLUDE_NET_SYM_TBL
/* load the symbol table by whatever means */
#define INCLUDE_SHELL
/* target-based shell */
#define INCLUDE_SHOW_ROUTINES
/* optional target-based system utilities */
#define INCLUDE_STAT_SYM_TBL
/* optional target error status routines */
#define INCLUDE_SYM_TBL
/* symbol table package */
#define INCLUDE_UNLOADER
/* optional object module unloading */
#define INCLUDE_WDB
[转] 嵌入式单地址空间中实现动态加载的过程
Posted by gavinkwoe
转至：http://blog.csdn.net/pengzhenwanli/archive/2008/04/23/2319412.aspx#875603
之前有一篇文章是关于嵌入式单地址空间实现动态加载的想法，里面描述的是我根据相关资料进行猜测的地方，以及从技术上来说，可能需要的技术，最近难得有空闲时间，我实现了一下动态加载的。目前已经成功实现，下面说一下实现的过程。
先说一下实现此技术需要的平台：
OS：Nucleus
CPU：ARM7+cache
Baseband：VT3406
ADS1.2
说一下这些东西的来历，Nucleus是实时嵌入式单地址空间操作系统，CPU是介于ARM7与ARM9之间的CPU，BB芯片是VIA出的，这些东西目前都已经收掉不再使用，我也正好离职，从而有时间去实现一下动态加载的问题。
从理论上来说，动态加载很简单，只需要把当前的PC指针指向下一句执行的语句即可。也就是使用如下的ASM就可以实现：
MOV PC, Address
这样就可以顺利执行程序，在我实现的时候，考虑如下问题，程序执行如何返回，参数如何传递，程序执行完毕返回到哪里。
这些问题的解决，看起来比较复杂，其实很简单，程序的返回是放在LR中，这样在上一个函数调用的时候，只要LR的值不变，这样可以在下一个函数调用的时候，同样使用LR，这样就可以顺利返回。关于参数传递，由于ARM中使用r0-r3传递参数，这样只要不更改r0-r3，就可以顺利传递参数。这个地方想明白，我用了好久，特别是返回地址的问题，程序如何执行，应该返回哪里。解决方法如下
实现DynamicLoader(UINT8 *pAddress)
MOV PC, R0
这个地方一定要用ASM实现，否则无法完成需要的功能。由于在调用此函数时，已经把函数的返回地址放到LR中，具体ASM如下：
MOV r0,address
BL DynamicLoader
由于DynamicLoaer的实现问题，没有实际的返回，也就是不需要使用
BX lr
这样来做为函数的返回。这是由于R0所指向的一个函数的开始地址，从DynamicLoader开始，其实执行的是另一个函数，这里的DynamicLoader只是起到了一个跳转的作用。但是又必须使用函数调用的方式来进行，而不能直接跳转，否则函数没有办法返回。由于BL的时候填充了LR，这样在下一个由于实际调用不是使用的B指令，因为并没有设置LR，这样仍旧是在调用DynamicLoader时的LR，因此可以正确返回。
函数可以正确调用并返回，这是程序很大的一个进步，这样就可以实际构造可以运行的程序了。
下面说一下ADS编译为二进制可执行文件的问题，使用编译器如果一开始把所有的数据都放好，这样包括全局变量和静态变量，以及函数的执行地址等，都已在LINK的时候根据指定规则确定实际的运行地址，也就是说所有的函数的实际运行地址在LINK的时候已经确定。这样对于动态运行来说是不可行的，因为既然要动态加载，就需要所有地址都是静态的，因为每次对于读入内存的数据，起始地址是不缺定的，因此不能再LINK时把所有的地址固定死。
解决这个问题有两种方式，一种是在scatter loader中把程序的可执行地址固定好，在LINK时不LINK实际的数据，而在系统启动的时候，把这部分可执行文件拷贝的固定的地址，这样可以作为一个整体运行。但是这种方式由问题，就是应用的大小什么的都是固定死的，不能太灵活，不能根据应用实际调整。
这里使用另外一种方式，选择程序不在LINK的时候把所有的地址固定死，而是使用相对独立的函数调用方式。如下：
原来的方式可能使这这样
BL 0×10008;
而使用相对的地址程序如下：
ADD r5,pc,#18
BL r5
这样虽然多了一句，但是可以做到函数的运行地址是动态指定的，而不是编译为固定的地址。
其实ADS提供了把函数编译为独立地址的方式，
COMPILER使用如下的参数/ropi/rwpi
LINK使用如下的参数-rwpi –ropi
就可以把编译的程序做到运行时地址是独立的。
从上面来开，编译时地址的问题，还有运行时加载的问题，都已经顺利解决。但是这里还有一个问题，就是如何确保动态应用如何每次在使用的时候，都从固定的入口进入的问题。也就是说，虽然有了内存中的运行地址，但是如何保证每次都从固定的函数开始执行呢？如果每次都从编译的可执行文件0地址开始执行，没有办法保证每次调用的是同一个函数。
这个可以通过LINK来保证每次是同一个函数在0地址，使用如下的参数
-first DyanmicAppEntry
这样就可以保证DyanmicAppEntry的入口地址为可执行文件的开始了。
上面的文章解决了动态编译和加载的问题，下面说一下动态应用的问题。如果要使一个应用有价值，比然需要提供本地的功能调用，而且对于手机来说，系统已经基本上实现了大多数的功能，如果在动态应用中再重复实现一些功能，可以说既浪费了空间，又浪费了时间。而且对于硬件相关的功能，必须通过本地调用来进行，这样就需要如何把本地调用传入动态应用中。如上文所说，本地的调用地址都是在LINK的时候确定的没有办法直接在动态应用中使用，这样需要在运行时把本地调用传入动态应用，由于动态应用的入口还有好几个参数可以使用，这样就可以构造一张系统调用的表，在运行的时候传入动态应用，这样可以通过表来调用系统功能，这样就解决了系统本地调用的问题。
这里要特别说一下安全的问题，由于动态应用是直接更改PC指针运行的，这样，如果应用出错，系统可能就CRASH了，无法再继续运行，而且由于可以调用本地系统调用，可能做许多意想不到的功能，这样就可以在系统调用的时候
增加一个中间层，一些核心功能，必须满足一定的权限在可以调用。
[转] 在嵌入式单地址空间OS中实现动态加载的问题
Posted by gavinkwoe
转至：http://blog.csdn.net/pengzhenwanli/archive/2007/02/26/1514689.aspx
本文的的主要想法是来源于手持设备可运行应用程序和如何实现智能机问题的思考。问题的主要来源是关于可扩充应用程序的考虑，目前大部分手机都是非智能机，也就是不能扩充应用程序
1.智能手机与非智能手机
一般来说，智能手机目前公认三大系统，Windows Mobile，Linux和Symbian，也即是说采用这三种系统的手机，都成为智能机。我认为，从技术上来讲，智能机最主要的特征就是第一可扩充应用程序，也就是说用户可以自行安装需要的程序而不局限于手机自带的，第二就是多用户任务，也就是用户具有同时运行多个应用程序的权力。而非智能手机的操作系统可以说是五花八门，什么都有。但是基本上都有一个核心的特征，就是同时只能运行一个应用程序，而且所有的应用程序都运行在相同的地址空间，而智能机是运行在独立地址空间。一般来说，非智能机也支持多任务，不同的是这些任务共用相同的地址空间。用户操作的UI就是一个单独的任务，用户所能使用的功能基本上就是由UI提供的。
我原来对于非智能机是非常的不屑，认为没有什么发展前途，但是我最近又弄了一个非智能机的手机用了一下，发现很多功能都非常的人性化，从使用上来讲，并不亚于智能机，由此引发了我对于非智机功能的思考。对于智能机来讲可扩充的应用程序一般来说，都是由第三方开发商开发的，稳定性都有所缺陷，并不如原生的系统应用程序稳定。而且有些比较好的用程序价格不菲，我见过使用智能机的人大部分都是使用破解的应用程序，我本人也是。这个行为是违法的，当市场成熟以后，比如像美国，是不太可能的。
智能机由于操作系统功能强大，一般要求系统的硬件性能强劲，这样相应的功耗也大，待机时间相应的缩短。非智能机可以运行在性能较差的硬件上，并且获得的UI表现，不弱于智能机。这样就可以在相同的电力消耗的情况下，获得更长的使用时间。
2.非智能机获得智能机功能必须的要求
如上文所说，只要非智能机实现智能机最主要的两个特征即可获得智能机的功能。一个是用户自行安装应用程序的功能。另一个是同时运行多个应用程序的功能。
3.用户自行安装应用程序的功能
除了智能机以外，目前有两种技术都实现了用户可自行安装应用程序的功能，一个是BREW另一个是Java ME(J2ME)。下面分别说一下这两种技术，BREW技术由Qualcomm（高通）创建，包括一整套的体系，从运营到分发都有。在本文里只是对于客户端技术的说明，对于BREW技术而言，已经非常符合本文中所提及的技术，本文从另一方面来讲，也可以说是分析了BREW的基本技术。BREW技术高通把持的非常严密，目前而言，并没有开放源代码而且对于技术内部也是进行严密的封锁，因此目前出现的文章都是猜测技术的实现，但是对于技术来讲，万变不离其宗，要实现某种技术，有些东西是绕不开的，就像使用CDMA技术，无论是WCDMA，CDMA2000，还是TDS-CDMA都无法绕开CDMA的基本专利一样。BREW技术基本达到了本文的技术要求，既能动态加载，也能同时运行多个任务，而且对于系统功能的使用不像JavaME一样有严重的限制，基本上来说，可以使用系统提供的所有功能。而对JavaME，所提供的功能十分有限，就连存取本地文件都不可以。对于系统功能的使用，如果没有附加的支持，基本上不可能，目前应用最得的是游戏，最多有些网络方面的应用。对于提供系统级别的应用，比如说闹钟等，根本无能为力。也许以后能够提供，但是本人不太看好。另外还有一个就是Flash Lite技术，这个技术我并没有接触，就不详细说了。对于BREW和JavaME我都有相当长时间的接触，了解也比较细致，有些问题还是能够说一下的。
要解决用户可以自行安装应用程序的问题，必须解决以下几个问题，应用程序的加载运行问题，系统API的调用问题。
3.1应用程序加载
对于嵌入系统来讲，与通常的Windows系统不一样，Windows的所用应用程序都在硬盘上，运行的时候根据需要加载到内存中，在运行，或者是使用虚拟内存技术，直接映射的硬盘也可以执行。而嵌入式系统通常是在ROM中，并不需要加载到内存才能运行，直接就可以运行，因此大部分的嵌入式系统都是统一做好一个系统的Image，然后放到ROM中运行。这样所有的地址都在编译期间确定，要是再动态加载应用程序，将会面临运行时地址确认的问题。一般而言，对于嵌入式系统，ROM使用Flash来代替，Flash中一部分作为ROM，另一部分作为嵌入式的文件系统，具体的系统格式这里不作考虑。要是可加载应用程序的话，一般来说是放在文件系统中。这样要运行可动态加载的应用程序，并不复杂，只要把应用程序调入内存中，运行时设置正确的寄存器就可以了。
这里也就是把可执行的文件加载到内存中，由于是单地址空间的，而不是像Windows一样每个应用程序都是独立的地址空间，这样应用程序可以从任意地址开始执行，这样载入内存以后，把当前的执行指针PC这为此内存地址即可。这也是单地址空间的程序可以执行的关键。
3.2系统API的提供
要提供可以运行时call的API，在单地址空间可加载应用程序的约束条件下，可以使用的方法也非常的单调。一般来说，单地址空间的应用程序是统一编译和链接的，这样生成可执行文件以后，所有的地址已经固定了，这样如3.1所说，应用程序如果每个都调用相同的系统API，比如memset等，由于应用程序时独立加载的，这样由于在编译过程中已经把所有的地址确定，所以每个应用必须链接独立的lib，这样造成了空间浪费。如果只是单独的应用，不提供这一步，系统已经可以动态加载了。
但是目前是要求在嵌入式单地址空间实现，必须考虑空间的问题。因此必须解决系统库可以动态加载的问题。也就是库的地址不是在链接的时候确定。只要能够解决编译时的链接问题，就可以做到。
关于
4.同时运行多个应用程序的功能
[转] 嵌入式系统中的模块动态加载技术
Posted by gavinkwoe
摘要
提出一种适用于嵌入式系统的模块动态加载技术，设计实现简单，占用资源少，开销小，并且成功运用于DeltaOS．可提高系统的灵活性和扩属性.介招加载与动态链接的原理和应用情况，解释相关术语，描述基本设计思路：详细说明该技术的核心。即模块声明、调用库、两级重定位表，最后给出结论。
关键词
模块 动态加栽 嵌入式系统DeltaOS
引 言
随着电子技术的飞速发展，嵌人式设备应用越来越广泛，复杂度也越来越高。这使得硬件和软件设计比例发生了很大变化，软件开发的比重越来越大。然而传统嵌入式开发过程中需要将应用与操作系统编译链接成一个整体，然后下载到目标机上运行。如果在调试过程中发现问题，需要重新编链接然后重复下载运行的过程。这样的开发流程周期长而且繁琐，已经越来越不适应快速市场化的需要。
为了适应多样化的嵌入式应用和加快嵌入式系统的开发过程，除了需要可靠的基础平台软件的支持，如带有文件系统、网络协议栈的RTOS和配套的集成开发环境，更重要的是需要可以动态扩展的系统平台。近年来，新一代的嵌入式操作系统已经开始使用动态扩展技术：将基本系统(包括操作系统以及其他共享功能调用库)和应用程序开发分开处理，支持模块更新和动态加载技术。很多主流的传统嵌入式操作系统厂商，如windRiver、Green HilIs、Lynxworks，都推出了面向航空航天、基础通信设备等领域的高可靠、高性能的RTOS版本，支持应用和系统组件的动态加载和更新；而在消费电子领域，相关的操作系统厂商，如symbian、Palm、Microsoft，更是积极推出了具有相应功能的操作系统，在新一代移动设备上得到了广泛应用。
为了成为可动态扩展系统平台，大部分嵌入式操作系统需要使用动态加载技术。总的来说，动态加载是指应用或者系统在运行过程中需要使用某模块的服务，于是通过一系列预定的动作将指定模块加载到系统中，让调用者继续顺利工作。它实现的关键就是加载与动态链接技术。因为加载和动态链接互相依赖，关系紧密，所以将两者放在一起进行讨论。
1 加载与动态链接机制
加载主要负责将模块程序从二级存储设备(比如硬盘或者Flash)搬移到指定内存空间，并且将模块交由系统加载器统一管理。
程序链接分为静态链接、加载时链接和运行时链接。静态链接就是将程序和它运行所需的全部库链接成一个执行文件。它的优点是可以独立运行、速度快，但是它链接生成的代码尺寸比较大。加载时链接是指程序在编译链接时不会把它用到的库链接到执行程序中，而是在它被加载器加载时才解析执行文件，依次把用到的库装载到系统中让其运行。它的优点是程序本身代码量减小，但运行时程序占的内存并没有减小，同时增加了加载器的工作量。动态链接是加载时链接的进一步发展，它是指将库的加载过程延迟到程序运行时执行。这种方式不会给程序引入额外的代码，也不会增加加载器的开销，只有当应用真正使用某库时才会加载该库，减少了不必要的空间占用。它的缺点是可能会有一些运行开销。
嵌入式系统中动态加载和普通的动态链接概念类似，但是嵌入式系统中的加载链接器有其自身的特点：它是交叉加载，主机端做一部分工作，比如程序的重定位，执行文件的解析等等；而目标机端相对简单，主要做模块搜索定位和空间分配，以及指定物理地址或者映射虚拟地址让其运行。一部分嵌入式系统不支持虚拟内存，应用和内核共享存储空间。当系统加载了多个应用到系统中时，一般需要使用overlap技术来解决内存空间有限的问题，即是当多个应用的运行地址空间冲突时，加载器会冻结当前暂时不运行的应用，让新加载的应用使用指定的地址空间，PairnOS中就采用了这样的设计。对于支持虚拟内存的嵌入式系统，加载器的工作被大大简化，每个应用都有可以运行在同样的虚拟的空间，不需要加载器为其重定位或使用overlap技术，因此提高了工作效率。Vxworks6．O，WinCE都使用了这种设计。两种方式在不同的领域都有比较多的应用。
文中提出的模块动态加载技术是基于支持MMU(Memory Management Unit)的32位嵌入式操作系统，采用了加载与动态链接技术。使用该技术构建的嵌人式系统面向高端市场，特别是对系统可靠性、安全性要求很高的领域。在DeltaOS新一代高可靠的版本HAR(High Available Reliable system)的研发过程中，即成功地实现了基于该设计的加载器LambdaLoader，达到了预期的性能要求。
2 模块动态加载的设计
2.1 设计思路
首先定义一些概念：模块、目标程序、接口函数地址表和调用库(call Library)。
①模块，主要是指加载器加载的一个单位，并且这里模块的概念主要是强调它是为应用或者系统提供一系列服务的提供者。
②目标程序，是指模块的使用者。它可以是应用，也可以是另一个模块。
③接口函数地址表(文中也称之为模块重定位表)，指在模块中有一个数组表，该数组表的内容是该模块对外提供的函数接口的地址。
④调用库，是供模块调用者链接使用的专有库。它与相关模块一一对应，将封装了的模块接口供目标程序使用。除此以外，它还有一个运行时才确定的模块重定位表地址指针和模块动态查找定位的代码。
如果在系统中要实现动态加载，首先需要一种模块定位机制，使得调用者能够在系统中动态定位需要的模块，其次是要能让模块与目标程序动态的关联在一起，协调工作。为了解决这些问题，需要一系列相关的设计：规定模块的声明方式；简化目标机端模块地址空间定位的工作；重定位表的机制等等。基于这样的设计，系统可以比较顺利地实现动态加载。模块动态加载的工作流程如图l所示。这里描述的主要是目标机端的工作。
2.2 模块的声明
模块首先要定义它的相关属性。这里使用模块声明文件来完成这个工作。模块声明文件中需要定义：模块名字、版本、对外提供的API接口。在系统编译模块程序后，会调用一系列的script代码。这些script会根据模块名字查找模块对应的模块声明文件，并根据该文件生成供模块调用者使用的调用库和与模块一起链接的附加库。
附加库包含系统后台通过调用script生成的接口函数地址表和模块注册函数。在每个模块的初始化函数中，会调用一个模块的注册函数(该函数主要工作是向系统注册模块的名字和接口函数地址表地址)。当模块被加载时，初始化函数会被系统调用，向系统注册模块信息，此后模块交由加载器统一管理。
2.3 调用库
每个模块在提供一个模块重定位表的同时，必须提供一个与之对应的模块调用库。别的目标程序必须并且只能通过调用库来使用这个模块提供的服务。每个调用库都有一个存储本模块重定位表的地址指针变量。该变量在模块被目标程序第一次使用时会被初始化为相应模块重定位表地址。
在模块第一次被目标程序使用即开始动态加载过程时，首先运行的是调用库的库初始化代码(Library initialcode)，它通过指定的系统调用来初始化库中的模块重定位表基地址指针。此后每次目标程序使用模块提供的函数接口时，都通过以下公式得到该接口的实际地址：模块接口实际地址=模块重定位表基地址+函数index×4
在该公式中，函数index是指对应函数在模块重定位表中的数组下标值。因为根据模块声明文件生成的调用库中已经包含了每个函数的索引信息(index)，同时在32位系统中需要乘以4得到准确的偏移量，所以当调用库中重定位表地址被初始化后，可以通过这样一个简单计算得到指定接口实际地址，完成函数调用。
当一个目标程序使用了模块，并正确动态加载后，其关系如图2所示。目标程序中链接了调用库，包含了函数跳转表和指向模块重定位表基地址的指针(ModuleBase)；模块中则链接了附加库，包含了函数接口地址表(模块重定位表)。调用模块函数时，经过动态加载模块的过程以后，目标程序的模块重定位表基址指针指向了对应模块的函数接口表，然后函数调用就可以顺利进行了。
2.4 两级重定位表
在嵌入式领域，为了降低性能开销和增加确定性，目标机端加载器不会做程序重定位，而将相关工作在主机端完成，所以目标机端加载的所有程序都是绝对定位后的程序．为了实现系统动态扩展，必须使各个模块能够单独链接生成执行程序，并且运行时不用关心彼此的定位，这样即使一个模块被动态替换后也能同其他程序一起协调运行。这里通过两级重定位表机制来完成这个协调性的工作。
对于内核、操作系统组件模块或提供服务给其他目标程序使用的模块，要维护一张本模块提供的接口函数地址表(即模块重定位表，这里称之为二级重定位表)。为了保证本模块的向后兼容性，模块必须保证其接口函数在模块重定位表中的相对位置固定。即使今后不能提供这个接口函数，也需要将其保留，以保证同以前版本的二进制兼容性。
在模块的初始化代码中，模块通过系统调用向加载器注册这个模块重定位表的地址，注册时需提供模块名和模块重定位表的地址。加载器中管理着一个称为一级重定向表的表格。这个表的表项是“模块名”到“模块重定位表地址”的映射。因为这只是一个映射关系，所以各个模块对应的表项在一级表中的具体位置是可以改变的。
二级重定位表如图3所示。
使用两级重定位表的规则如下：
①模块可通过模块重定位表向其他目标程序提供接口函数；
②目标程序要使用别的模块提供的接口函数必须通过对应模块的调用库来实现；
③目标程序在使用别的模块提供的接口函数之前，必须通过加载器提供的系统调用服务获取对应模块重定位表来基地址初始化对方的调用库。
结 语
该设计实现了在嵌入式系统中的模块动态加载与更新，使得在嵌入式软件开发过程中，开发人员可以更有效的设计系统，共享资源，达到提高效率、产品快速市场化的目的。在基于DeltaOS的实现中，可以完成应用的任意加载卸载，系统组件的动态更新；多个应用可以共享一个全局的模块；一个应用可以同时使用多个模块等等。整个系统扩展性和灵活性大大提高，较好地满足了实际需要。但是设计中对容错性、健壮性的考虑还不够，在应用与模块的间接调用处理上还有优化的空间，所以在这些方面还需要进一步改进。
[转] J2me流媒体技术实现讨论[3]
Posted by gavinkwoe
Jffmpeg应该是对 ffmpeg 这个C编写的工具的Java封装。
另一个封装的是
http://fobs.sourceforge.net/
FOBS, the C++ & JMF wrapper for ffmpeg.
Cleverpig said：“
| 其实，感觉上可以自己编写一套流媒体规范的实现，比如将源文件指定为wav格式或者其它的raw格式，然后分段发送到mobile。。 但是这样做确实效率低，而且浪费带宽。本人研究了一下Tea Vui Huang的mobilecast实现有些心得，在此与大家讨论一下： 1。使用MMS发送radiocast：由于MMS服务可以使用图片、音乐等多媒体元素，而且技术比较成熟，所以将它作为radiocast的载体是方便的选择。而对于mobile用户来讲，cast的使用方式可以采用请求和订阅两种模式； 2。radio文件格式的选择：对于某些手机不能支持mp3格式文件，即使支持mp3也受到memory size的限制，所以采用更为普遍、压缩比更大的amr格式是比较好的choice； 3。amr文件的分割：由于目前大多数手机仅能支持100KB左右的彩信，所以最佳的cast长度应该是50秒。比如将大约5分钟的mp3文件分割为6个 amr章节文件，每个章节文件所包含的audio长度为45-50秒。而每个amr格式的压缩比将是普通mp3格式3-6倍。按照播放率为 600KB/min的mp3格式计算，保守地假定amr格式压缩比为mp3格式的6倍，amr格式的播放率为100KB/min，而45秒的amr文件大 小为75KB。 所以Tea Vui Huang的做法是很clever的。” |
我试验过了，利用ffmpeg的这两个参数，可以控制让ffmpeg来将一个大mp3劈分成许多小段的独立播放的amr文件。
-ss time_off set the start time offset
-t duration set the recording time
比如你写这么个perl文件，然后运行：
@inputFilename = "C:\\opt\\media\\changjin.wma";
@outputFilename = "C:\\opt\\media\\changjin";
for($i=1,$j=1;$i<=1000;$i+=10,$j++)
{
system("C:\\software\\ffmpeg.exe -i @inputFilename -ac 1 -acodec amr_nb -t 10 -ss $i @outputFilename.$j.\".amr\"");
}
就把一个大文件拆分成许多小amr了，每一个amr文件只有17KB。
Qinjiwy said：“
| 提一个优化的小建议 如果分段太小,播放的间断太多的话,用户感觉上和系统开销都不是很合适. 可以考虑多开几个线程, 另外,每个文件不一定要一样大,可以考虑 |
”
Cleverpig said“
| to qinjiwy：这个边收听边下载的方法可以作为一个应用程序选项，因为并不是每个人都需要不间断的听，也许只想听第一段试试看，如果好的话再继续听下去。而且有些人还可能直接从中间的部分收听，如果这时文件变大的话，可能等待时间更长。 |
”
[转] J2me流媒体技术实现讨论[2]
Posted by gavinkwoe
cleverpig said“
| 之所以有些格式的媒体文件不支持分段播放，是因为它们文件中不含有索引信息。 就像在以顺序方式读取文件时无法seek一样。。 这个问题可以通过人工（或者用程序）将文件分割后部署放到服务器上来解决。 |
”
以及“
| 随着iTunes4.9版的发布，podcaster（pod播客们）能够建立自己的podcast，并可以通过增加幻灯片式的图片使其更加吸引人。而且 在附加信息中的URL还可使用户门自由的找到其他的podcast资源。这成为了podcast世界的“大地震”。目前这一特性移植到手机上是通过划分“ 章节”来完成的，即将podcast资源文件划分为多个章节，这样做才能让没有“重播/定位”能力的手机进行播放。
但是另一个挑战将摆在移动用户面前，例如：移动收听必须对中断事件进行管理。当我们正开始播放20-40分钟的podcast时，一个电话或者短信突然到 来，这些情况将使播放被迫中断。此时我们只能选择重新打开podcast从头再听或者是没有心情从头听。另外媒体文件格式问题也是对移动用户的“噩梦”， 大多数手机都不支持mp3或者AAC这种podcast的文件格式，但它们都支持.3gp的标准AMR格式文件。而且能够保存几兆mp3或者AAC文件） 的手机目前也不是很普及。 但是Tea Vui Huang制作的javacast改变了这一切。这个软件就是将mp3音乐转换为手机可以播放的.3gp 标准amr（audio recording format）格式。大家可以到http://www.ringtone4me.com/看看，上面有一些具有此类功能软件链接。 javacast的作者——Tea Vui Huang也是Mobcast的作者, 已经制作了一套处理工具将转换Podcast到一个java Midlet中（用户只需要在手机中调用javacast无线下载这个j2me应用程序，并可以播放podcast）。这使那些podcasters们通 过简单的增加一个下载这个midlet的链接就能很容易是获得他们的podcast。 |
”
Huang的Mobcast，确实非常著名，几个月以前，在我写toodouPodcastMidlet时就看过许多人介绍过他，但是就是连不上http://www.geocities.com/tvhuangsg/m…��睹真容。
转换各种格式的video为3gp，转换各种格式的audio为amr，这些在开源软件mplayer手下是随手拈来，只需要看懂mplayer的各种参数即可做到了。所以拜mplayer所赐，我也能够制作手机看交通实况录像，都要感谢那些mplayer的开发人员！
“移动收听必须对中断事件进行管理”，这个确实需要考虑。当进入Paused状态时，需要通知播放线程暂停，同时连接线程暂时就不要去抓取服务器的媒体数据了；等界面切换回来后，播放线程继续replay，连接线程继续下载音乐。
斑竹说“可以通过人工（或者用程序）将文件分割后部署放到服务器上来解决”，我想也是，简单的文件分割是不够的，或者说仅仅适合于wav这种原始数据格 式。应该事先将音乐文件用mencoder分解成一段一段的音乐文件放在服务器上，mencoder将处理每一段的格式问题保证能独立播放，这样手机下载 起来只需要按照编号一段一段地下载即可，服务器不再需要运算和添加头信息。
美中不足，如果两个player切换播放，中间会有一个卡啪声。
cleverpig said“
| 有兴趣的话可以看jffmpeg，是一种能够处理音频视频的java媒体框架。 |
”以及
“
| 想了一下，提出一个“移动音频流网关”的想法：可以使用服务器采用“实时”转化格式的方式，将mp3、wav等格式音频转换为amr格式，当然也可以做分 段，无论音频源是什么（甚至是podcast）都可以下载到手机上收听。但这样做的话，服务器的负载是个问题，尽管已用采集过的音频源不用再次处理。 |
”
其实，我原来写的toodouPodcast就是这么一个概念，由于那些播客们提供的音乐格式不符合手机播放，所以我都用toodouPodcast这么 个java web service调用ffmpeg工具进行音频转换。转换格式，确实是一个很费CPU资源的事情，而且时间很长，如果用户多的话，对服务器压力极大。
那么现在做做分段也不错，这样，更适合手机用户。
Jffmpeg应该是对ffmpeg这个C编写的工具的Java封装。
另一个封装的是
http://fobs.sourceforge.net/
FOBS, the C++ & JMF wrapper for ffmpeg.
[转] J2me流媒体技术实现讨论[1]
Posted by gavinkwoe
看到很多很多人持续在问这个问题。
以前我也听说，好像kvm底层实现不太支持j2me来做streaming video/audio，但我不知道那人为什么这么说。
那么现在国外有一个人提出下面这种思路，并且号称在Nokia6260[相关数据：诺基亚 6260 Nokia62602.0 (3.0436.0) SymbianOS7.0s Series602.1 ProfileMIDP-2.0 ConfigurationCLDC-1.0]
上真实实现了(两种网络方式：蓝牙和GPRS都试验过)，但我怀疑他的前提条件是“你的手机必须允许同时实现player的多个实例进入prefetched状态（预读取声音流）”：
第一步：
声明两个Player；
第二步：
HttpConnection开始向服务器请求该audio文件的第一部分字节，我们定这次读取的字节数为18KB；
第三步：
等第一部分数据到位后，Player A开始realize和prefetch，并开始播放；
第四步：
在Player A播放同时，(18KB的amr数据可以播放10秒钟)，HttpConnection继续请求第二部分数据(假设GPRS每秒钟传输3KB，那么18KB需要传输6秒，算上前后通讯损失的时间，应该不会超过10秒钟)；
第五步：
第二部分数据到位后，假设Player A还没有播放完(这需要调整你的每一部份数据字节数来使得假设成立)，那么将数据喂给Player B让它realize和prefetch；
第六步：
Player A播放完后，得到事件通知，于是让Player B开始播放。
如此往复。
大家看看此种理论可否。
我自己在nokia 7610上测试了一下，我上面说的前提被证明是可行的：“你的手机必须允许同时实现player的多个实例进入prefetched状态（预读取声音流）”。真实Nokia手机确实可以如此：
两个线程中各自有一个Player，都开始做m_player.realize();和m_player.prefetch();，然后等候。
先播放线程1的Player，等她播放完后，
通过
/*
* 本类实现了PlayerListener接口。通过这个事件来告知媒体已经播放完毕
*/
public void playerUpdate(Player player, String event, Object data){
if(event == PlayerListener.END_OF_MEDIA){
try{
System.out.println("playerUpdate>>PlayerListener.END_OF_MEDIA");
stopGauge();
playForeground();
}catch(Exception e){
e.printStackTrace();
}
}
}
来通知第二个线程的Player播放。
这样是可以的。
qinjiwy说“可以,不过前提是该音频文件允许分段播放,有些音频文件就是不允许的.”，你说得对。确实有很多格式的媒体文件不支持分段播放。我所知道的是wav可以，mp3也可以。
服务端每次只读取这两种媒体文件的某一部分，如果是mp3文件的话，我暂时不知道是否每次需要加上特殊的头信息。
但是如果是WAV文件，那么肯定每次都要加上WAV特定的头，要不然Player也无法播放。
这种形式肯定是可行的。因为以前我在VC++上写Text To Speech程序时，就是这么做的：WAV文件的前若干个字节肯定是头信息，这是一定的，随后跟的全是RAW DATA；我每一次读取WAV的RAW DATA若干字节后，传给我的播放线程，他需要给这段RAW DATA前加上一个WAV HEADER，然后就可以正常播放了。
[转]AT指令集及S寄存器
Posted by gavinkwoe
AT命令使计算机或终端与调制解调器通讯,所有命令行必须由ASCII字符“AT”开始并由 <Enter> 结束。除了A/指令和推出(缺省为+++)。这些将在后面讨论。字母”AT”用以提醒调制解调器注意，其后将有一条或多条命令出现, “AT”及其后的字母可以是大写或小写。
AT必须同为大写或小写。如”At”或”aT”是不允许的。
一串命令可以写在一行里。为了便于阅读可以加或不加空格。命令中或命令间的空格会被忽略，命令行的最多字符数为39(包括”AT”)。在输入一条命令期间，可以用退格键(backspace)改正除”AT”以外的错误。若命令行中任一处出现语法错误，本行其后的内容将被忽略，并返回ERROR。大数带有超出正常范围的参数的命令将不被接收并返回 ERROR.本章列出所有设置调制解调器的命令。包括控制ACTIVE调制解调器的贺氏标准AT命令集。贺氏V系列命令集和扩展命令集
AT命令集的描述
符号 * 表明该命令的设置可用AT&Wn命令存于两个用户方案中的一个
A/ 重执行命令
重执行前一AT命令行，主要用于连接时占线，无应答或号码错误。这一命令必须单独构成一命令行并由”/”字符结束,(<Enter> 不能用于结束命令)。
+++ 退出字符 缺省:+
切换调制解调器从在线状态到命令状态，而不会中断数据连接。可以通过改变S寄存器S2的值来改变这一字符。
AT=x 写入被选的S寄存器
这一命令将数值x写入当前被选的S寄存器，一个S寄存器可由ATSn命令选择，若 x 是一个数字,所有S 寄存器将返回 OK 响应。
AT? 读被选的S寄存器
这一命令读并且显示被选的S寄存器的内容。一个S寄存器可由ATSn命令选择。
ATA 应答
它必须是命令行中的最后一条指令。调制解调器在应答方式下继续执行连接程序。在与远端调制解调器交换载波后进入连接状态,如果在由寄存器S7规定的时间内(缺省值=50秒)没有检测到载波, 调制解调器将挂机。在连接过程中，通过DTE输入的任何一个字母都将中断这一命令。
ATBn* 选择ITU-T或Bell模式 缺省=0
ATB0 选择在1200和300bps速率下通讯的ITU-T V.22和V.21协议
ATB1 选择在1200和300bps速率下通讯的Bell 212A和103协议ATCn 载波控制缺省=1
包含这一命令只是为了保证兼容性，执行号只是返回一结果码而没有其它作用。
ATC1 正常传输载波切换ATDn 拨号
它必须是命令行中的最后一条指令, ATD命令使调制解调器摘机后, 根据输入的参数拨号,以建立连接。如果不带参数，调制解调器摘机后，不拨号进入发起方式。
使用标点可使命令更易读懂。圆括号,连字符和空格符会被忽略。拔号命令行中如果出现了非法字符，则该字符及其后的内容将被忽略。调制解调器允许的拨号命令长度为36个字符。
参数：0-9 A B C D * # L P T R ! @ W , ; ^ S=n
0-9 DTMF 符号0到9
A-D DTMF 符号A,B,C和D。在一些国家中不使用这些符号
* “星”号(仅用于音频拨号)
# “#”号(仅用于音频拨号)
J 为本次呼叫执行在可提供的最高速率下的MNP10链路协商(可选)
K 使本次呼叫MNP10链路协商期间电源电平可调(可选)
L 重拨上一次拨过的号码
P 脉冲拨号
T 双音频拨号
R 逆叫方式。允许调制解调器使用应答方式呼叫只能作为发起使用的调制解调 器, 必须作为命令行中的最后一个字符输入。
! 使调制解调器按照S29中规定的值挂机一段时间再摘机。
@ 使调制解调器等待5秒钟的无声回答
w 按照寄存器S7中规定的时间，在拨号前等待拨号音。
, 在拨号过程中，按照寄存器S8中规定的时间,暂停
; 拨号后返回命令状态
^ 打开呼叫音
() 被忽视，用于格式化号码串
- 被忽视，用于格式化号码串
<space> 被忽视,用于格式化号码串
S=n 用AT&Zn 命令存在地址n处的号码拨号ATE* 命令回应 缺省:1
ATE0 关闭命令回应
ATE1 打开 命令回应ATHn 摘挂机控制 缺省:0
ATH0 使调制解调器挂机
ATH1 当调制解调器处于挂机状态，使调制解调器摘机，返回响 OK，等待进一步的命令。ATIn 识别
I0 报告产品代码
I1 报告ROM中预先计算的校验和
I2 计算校验和并与ROM中的校验和比较,返回”OK”或”ERROR”结果码
I3 报告固件修正
I4 报告OEM定义的识别串
I5 报告国家代码参数
I6 报告固件修正
I7 报告调制解调器数据泵类型ATLn* 扬声器音量 缺省:2
ATL0 扬声器低音量
ATL1 扬声器低音量
ATL2 扬声器中音量
ATL3 扬声器高音量ATMn* 扬声器控制 缺省:1
ATM0 关闭扬声器
ATM1 扬声器在呼叫建立握手阶段打开至检测到来自于远端调制解调器的载波后关闭
ATM2 扬声器持续开
ATM3 扬声器在应答期间打开。当检测到来自于远端的调制解调器的载波和拨号时关闭ATNn* 调制握手 缺省:1
ATN0 要求调制解调器S37选择连接速率,若S37＝0,则连接速率必须与发出的上一条AT命令的速率相匹配。如果所选择的速率可用不止一个通讯标准实现(如Bell212A或ITU-T V.22 速率在 1200bps)调制解调器同时参考ATB 命令选择。ATN1 允许时使用双方调制解调器都支持的任一速率握手，使能够自动检测。在这一方式下，ATB命令被忽视，调制解调器只用ITU-T方式连接。
ATOn 进入数据在现状态 缺省:0
ATO0 使调制解调器从命令在现状态直接返回数据在线状态,不经过自动均衡。
ATO1 使调制解调器从命令在现状态返回数据在状态,经过自动均衡。ATP* 设脉冲拨号为缺省
ATQn* 结果码显示 缺省:0
ATQ0 调制解调器向DTE发送结果码
ATQ1 禁止调制解调器向DTE发送结果码
ATSn 设S寄存器n为缺省寄存器
ATSn? 读S寄存器读S寄存器中的内容，所有的S寄存器都可以读
ATSn=x 写入S寄存器
将 x值写入指定的S寄存器n
ATT* 设音频拔号为缺省
ATVn* 结束码类型 (消息控制) 缺省:1
ATV0 发送短型 (数字型) 结果码
ATV1 发送长型 (字符型) 结果码ATWn* 协商进程报告 缺省:0
ATW0 不报告纠错呼叫进程
ATW1 报告纠错呼叫进程
ATW2 不报告纠错呼叫进程，CONNECT xxxx指示DCE速率。ATXn* 扩展结果码 缺省:4
ATX0 调制解调器忽视拨号音和忙音。当由盲拨建立连接时，发送CONNECT信息。ATX1 调制解调器忽视拨号音和忙音。当由盲拨建立连接时，CONNECT XXXX 反映的是比特速率
ATX2 调制解调器忽视忙音，但在拨号前等待拨号音，如果5秒钟内检测不到拨号音，则发送NO DIAL TONE 信息，连接建立后 发送 CONNECT xxxx反映比特速率。
ATX3 调制解调器忽视拨号音,若检测到忙音,发送BUSY信息,当由盲拨建立起连接时, CONNECT XXXX 反映的是比特速率。
ATX4 如果5秒钟内检测不到拨号音，发送NO DIAL TONE 讯息,检测到忙音, 发送BUSY信息。连接建立后发送CONNECT XXXX 反映比特速率。
ATYn* 控制长间隔拆接 缺省:0
ATY0 不允许长间隔拆接
ATY1 允许长间隔拆接ATZn 复位 缺省:0
重新调出由用户方案规定的动态配置
ATZ0 软复位并重新调出用户方案0
ATZ1 软复位并重新调出用户方案1AT&An* 握手异常终止(备选) 缺省:1
AT&A0 在握手时禁止用户进行异常终止。当拨号或应答时，握手不能异常终止,只有DTR 信号下降。AT&A1 用户可以在握手时进行异常终止.在接收到DTE的字符后,发起和应答可以在握手期间随时进行异常终止.
AT&Cn* RS232-C DCD 设置缺省:1
AT&C0 DCD为ON，不论来自远端的调制解调器的数据载波的状态为何。
AT&C1 DCD 跟随来自于远端调制解调器的数据载波的状态AT&Dn* RS232-C DTR 设置缺省:2
决定了调制解调器与来自串口的DTR信号相关的操作。由于跟踪DTR的下降引起的操作在下表列出:
1 调制解调器断开连接并发送结果码OK
2 若在数据状态下,则进入命令状态,并发送结果码OK
3 调制解调器断开连接并发送结果码OK, DTR 为 OFF时不能自动应答
4 调制解调器执行热启动(即与ATZ命令相同)
AT&Fn 重新调用工厂 设置缺省:0
&F0 重新调用作为V.42bis自动可靠方式的出厂缺省设置
&F1 重新调用作为MNP5自动可靠方式的出厂缺省设置
&F2 重新调用作为DIRECT方式的出厂缺省设置
&F3 重新调用作为MNP10方式自动可靠方式的出厂缺省设置(可选)
AT&Gn* 设置保护音 缺省:0
AT&G0 无保护音
AT&G1 无保护音
AT&G2 1800HZ保护音
AT&Jn* 电话插头选择 缺省:0
包含这一命令只是基于兼容性的考虑，没有任何功能
AT&J0 不操作任何功能
AT&J1 不操作任何功能
AT&Kn* DTE/调制解调器流 控制缺省:3
AT&K0 关闭流控制
AT&K3 使用RTS/CTS流控
AT&K4 使用XON/XOFF流控
AT&K5 使用透明XON/XOFF流控
AT&K6 使用RTS/CTS和XON/XOFF流控(作为传真方式下的缺省)
AT&Ln* 传输线类型 缺省:0
AT&L0 拨号线
AT&L1 二线专线 （备选）
AT&L2 四线专线 （备选）