2009年3月29日星期日

什么是字节对齐,为什么要对齐?

现代计算机中内存空间都是按照byte划分的,从理论上讲似乎对任何类型的变量的访问可以从任何地址开始,但实际情况是在访问特定类型变量的时候经常在特定的内存地址访问,这就需要各种类型数据按照一定的规则在空间上排列,而不是顺序的一个接一个的排放,这就是对齐。
对齐的作用和原因:各个硬件平台对存储空间的处理上有很大的不同。一些平台对某些特定类型的数据只能从某些特定地址开始存取。比如有些架构的CPU在访问一个没有进行对齐的变量的时候会发生错误,那么在这种架构下编程必须保证字节对齐.其他平台可能没有这种情况,但是最常见的是如果不按照适合其平台要求对数据存放进行对齐,会在存取效率上带来损失。比如有些平台每次读都是从偶地址开始,如果一个int型(假设为32位系统)如果存放在偶地址开始的地方,那么一个读周期就可以读出这32bit,而如果存放在奇地址开始的地方,就需要2个读周期,并对两次读出的结果的高低字节进行拼凑才能得到该32bit数据。显然在读取效率上下降很多。

二.字节对齐对程序的影响:
先让我们看几个例子吧(32bit,x86环境,gcc编译器):
设结构体如下定义:
struct A
{
int a;
char b;
short c;
};

4Byte
|---------|
| a |
|----|----|
| b -| c -|
|---------|


struct B
{
char b;
int a;
short c;
};

|--------|
|b |
|--------|
| a |
|--------|
| c |
|--------|

现在已知32位机器上各种数据类型的长度如下:
char:1 (有符号无符号同)
short:2 (有符号无符号同)
int:4 (有符号无符号同)
long:4 (有符号无符号同)
float:4 double:8
那么上面两个结构大小如何呢?
结果是:
sizeof(strcut A)值为8
sizeof(struct B)的值却是12

结构体A中包含了4字节长度的int一个,1字节长度的char一个和2字节长度的short型数据一个,B也一样;按理说A,B大小应该都是7字节。之所以出现上面的结果是因为编译器要对数据成员在空间上进行对齐。上面是按照编译器的默认设置进行对齐的结果,那么我们是不是可以改变编译器的这种默认对齐设置呢,当然可以.例如:

#pragma pack (2) /*指定按2字节对齐*/
struct B
{
char b;
int a;
short c;
};
#pragma pack () /*取消指定对齐,恢复缺省对齐*/
sizeof(struct B)值是8。


修改对齐值为1:
#pragma pack (1) /*指定按1字节对齐*/
struct B
{
char b;
int a;
short c;
};
#pragma pack () /*取消指定对齐,恢复缺省对齐*/
sizeof(struct B)值为7。

后面我们再讲解#pragma pack()的作用.

三.编译器是按照什么样的原则进行对齐的?

先让我们看四个重要的基本概念:
1.数据类型自身的对齐值:对于char型数据,其自身对齐值为1,对于short型为2,对于int,float,double类型,其自身对齐值为4,单位字节。
2.结构体的自身对齐值:其成员中自身对齐值最大的那个值。
3.指定对齐值:#pragma pack (value)时的指定对齐值value。
4.数据成员和结构体的有效对齐值:数据成员(数据类型)和数据结构的自身对齐值和指定对齐值中小的那个值。(数据成员对齐了数据结构自然也就对齐了)

有了这些值,我们就可以很方便的来讨论具体数据结构的成员和其自身的对齐方式。有效对齐值N是最终用来决定数据存放地址方式的值,最重要。有效对齐N,就是表示"对齐在N上",也就是说该数据的"存放起始地址%N=0".而数据结构中的数据变量都是按定义的先后顺序来排放的。第一个数据变量的起始地址就是数据结构的起始地址。结构体的成员变量要对齐排放,结构体本身也要根据自身的有效对齐值圆整(就是结构体成员变量占用总长度需要是对结构体有效对齐值的整数倍,结合下面例子理解)。这样就不难理解上面的几个例子的值了。

例子分析:
分析例子B;
struct B
{
char b;
int a;
short c;
};
假设B从地址空间0x0000开始排放。该例子中没有定义指定对齐值,在笔者环境下,该值默认为4。第一个成员变量b的自身对齐值是1,比指定或者默认指定对齐值4小,所以其有效对齐值为1,所以其存放地址0x0000符合0x0000%1=0.第二个成员变量a,其自身对齐值为4,所以有效对齐值也为4,所以只能存放在起始地址为0x0004到0x0007这四个连续的字节空间中,复核0x0004%4=0,且紧靠第一个变量。第三个变量c,自身对齐值为
2,所以有效对齐值也是2,可以存放在0x0008到0x0009这两个字节空间中,符合0x0008%2=0。所以从0x0000到0x0009存放的都是B内容。再看数据结构B的自身对齐值为其变量中最大对齐值(这里是b)所以就是4,所以结构体的有效对齐值也是4。根据结构体圆整的要求,
0x0009到0x0000=10字节,(10+2)%4=0。所以0x0000A到0x000B也为结构体B所占用。故B从0x0000到0x000B
共有12个字节,sizeof(struct
B)=12;其实如果就这一个就来说它已将满足字节对齐了,
因为它的起始地址是0,因此肯定是对齐的,之所以在后面补充2个字节,是因为编译器为了实现结构数组的存取效率,试想如果我们定义了一个结构B的数组,那么第一个结构起始地址是0没有问题,但是第二个结构呢?按照数组的定义,数组中所有元素都是紧挨着的,如果我们不把结构的大小补充为4的整数倍,那么下一个结构的起始地址将是0x0000A,这显然不能满足结构的地址对齐了,因此我们要把结构补充成有效对齐大小的整数倍.其实诸如:对于char型数据,其自身对齐值为1,对于short型为2,对于int,float,double类型,其自身对齐值为4,这些已有类型的自身对齐值也是基于数组考虑的,只是因为这些类型的长度已知了,所以他们的自身对齐值也就已知了.
同理,分析上面例子C:
#pragma pack (2) /*指定按2字节对齐*/
struct C
{
char b;
int a;
short c;
};
#pragma pack () /*取消指定对齐,恢复缺省对齐*/
第一个变量b的自身对齐值为1,指定对齐值为2,所以,其有效对齐值为1,假设C从0x0000开始,那么b存放在0x0000,符合0x0000%1=
0;第二个变量,自身对齐值为4,指定对齐值为2,所以有效对齐值为2,所以顺序存放在0x0002、0x0003、0x0004、0x0005四个连续字节中,符合0x0002%2=0。第三个变量c的自身对齐值为2,所以有效对齐值为2,顺序存放
在0x0006、0x0007中,符合
0x0006%2=0。所以从0x0000到0x00007共八字节存放的是C的变量。又C的自身对齐值为4,所以C的有效对齐值为2。又8%2=0,C
只占用0x0000到0x0007的八个字节。所以sizeof(struct C)=8.


四.如何修改编译器的默认对齐值?
1.在VC IDE中,可以这样修改:[Project]|[Settings],c/c++选项卡Category的Code
Generation选项的Struct Member Alignment中修改,默认是8字节。
2.在编码时,可以这样动态修改:#pragma pack .注意:是pragma而不是progma.

---------------------------------------------------------
· 使用伪指令#pragma pack (n),C编译器将按照n个字节对齐。
· 使用伪指令#pragma pack (),取消自定义字节对齐方式。

---------------------------------------------------------
· __attribute((aligned
(n))),让所作用的结构成员对齐在n字节自然边界上。如果结构中有成员的长度大于n,则按照最大成员的长度来对齐。
· __attribute__
((packed)),取消结构在编译过程中的优化对齐,按照实际占用字节数进行对齐。


五.针对字节对齐,我们在编程中如何考虑?
如果在编程的时候要考虑节约空间的话,那么我们只需要假定结构的首地址是0,然后各个变量按照上面的原则进行排列即可,基本的原则就是把结构中的变量按照类型大小从小到大声明,尽量减少中间的填补空间.还有一种就是为了以空间换取时间的效率,我们显示的进行填补空间进行对齐,比如:有一种使用空间换时间做法是显式的插入reserved成员:
struct A{
char a;
char reserved[3];//使用空间换时间
int b;
}

reserved成员对我们的程序没有什么意义,它只是起到填补空间以达到字节对齐的目的,当然即使不加这个成员通常编译器也会给我们自动填补对齐,我们自己加上它只是起到显式的提醒作用.


六.字节对齐可能带来的隐患:
代码中关于对齐的隐患,很多是隐式的。比如在强制类型转换的时候。例如:
unsigned int i = 0x12345678;
unsigned char *p=NULL;
unsigned short *p1=NULL;

p=&i;
*p=0x00;
p1=(unsigned short *)(p+1);
*p1=0x0000;
最后两句代码,从奇数边界去访问unsigned
short型变量,显然不符合对齐的规定。在x86上,类似的操作只会影响效率,但是在MIPS或者sparc上,可能就是一个error,因为它们要求必须字节对齐.

七.如何查找与字节对齐方面的问题:
如果出现对齐或者赋值问题首先查看
1. 编译器的big little端设置
2. 看这种体系本身是否支持非对齐访问
3.
如果支持看设置了对齐与否,如果没有则看访问时需要加某些特殊的修饰来标志其特殊访问操作。

DSP代码移植

基于DSP系统开发的视频编解码系统,国内几乎都是走的移植,优化的路线,并且移植的代码,都是开源的。毕竟花费大量的人力,物力去开发一套自己的代码,并不见得比一些成熟的开源代码效率更高,健壮性更好。更何况开发速度对于一个产品的发展而言,更是重要。
目前对于H.264而言,移植的代码主要有JM,x264和T264。移植的时候,就需要对各个代码进行测试,以确定要移植的代码。相对而言,JM
的移植更容易,但效率比较差,如果基于科学研究,移植JM的比较多,多见于各高校的研究人员。对企业而言,考虑到实时性的要求,移植以X264和T264
居多。
将视频编解码移植到DSP的时候,考虑到DSP系统资源的宝贵,主要考虑的因素是系统空间,包括程序空间和数据空间,所以需要对原始的C代码,进行评估,这就需要对于所移植的代码有一个比较详细的了解。代码空间一般可以通过map文件进行估算。数据空间的估计,需要计算程序中内存的使用情况,除了
malloc申请的空间,还包括静态数组,主要是H.264标准中的各种表格数组以及一些全局变量等等。
准备好了这些,就可以开始移植了,移植,也是一个考验你的过程。
做好了移植的准备工作,就进入了开发过程的第一个重要阶段---移植。
移植开发的时候,最好准备两个版本,一个纯C代码,在VC下编译,运行,另一个是VDSP下的版本(ccs同理),VC版本主要是验证代码运行是否正确,
VDSP版本就是移植以后的版本,两个版本同步更新,即尽量保持两个版本的一致性,但能够同时在VC和VDSP下运行。在移植过程中,一般会遇到的问题如下:
1.头文件的不同,一般问题都是linux下的头文件,在VDSP中没有存在。最典型的就是inttypes.h
和
stdint.h,这种头的作用主要是定义了8字符,16字符,32字符,64字符的数据类型,移植的时候,可以自己建一个头文件或者直接在其他的头文件中把这些数据类型的定义加进去,这样的话,就不会出现问题。其他的类似
,要么找相应的头文件替换,要么干脆自己定义。
2.Int64_t和Uint64_t 的问题, 在第一步中,其实也存在这个问题,
不过我最初是用long和Unsigned long
来代替,不过这样的话,编译是可以通过,但仔细分析,其实是有问题的。一般来讲,64位数的用途有两个,第一种是这个数字可能比较大,当累积到一定的程度,可能超过32位,这种情况下,可以用32位代替,不过最好加上注释,告诉自己这个数可能越界,在后面调试的时候,要提示自己注意一下。另一种用途,是开发者为了速度的要求,对一些变量复制的时候,使用了强制性的指针赋值,这种情况下,就不能直接该成32位数据了,那样的话,虽然编译通过,后面运行,肯定有错误的。这种情况下,可以使用32位数据类型,分两条语句对变量赋值,当然,这是个时候要千万注意,不要把地址搞错了。
3.
Inline的问题,移植以后,编译的时候Inline经常会报错。虽然有编译选项可以去掉错误,不过你如果和我一样不熟悉的话,直接去掉
Inline关键字,到后面随着对VDSP熟悉以后,如果有优化的需要,再按照VDS
P的语法,为自己想要嵌入的函数增加Inline关键字。
经过上面的修改,一般情况下,编译就没有问题了,当然,这只是移植的第一步。距离成功,还很远!
1.
配置LDF文件。因为刚移植的代码,往往数据和程序都非常大,所以,SRAM里面肯定是放不下的,这个时候,链接就会有问题。刚开始的时候,最好把所有的程序和数据都放在SDRAM里面去,这样的,链接就不会有问题了。Stack和heap情况类似,开始的时候,都先放到SDRAM。开始的时候,你需要的是一个可以运行正确的程序,速度倒在其次。
2.Malloc的问题。DSP下的开发,malloc都是一个需要解决的问题。动态申请内存,就算可以运行,结果往往也是不对的。所以,最好进行静态分配,用数组的形式分配,这样做的好处是可以方便自己管理,那些数组多大,放在那里,自己都很清楚,因为优化的时候,有一些是要放在SRAM中,另外一些特别大的才放在SDRAM中,这样才能取的比较好的效果,另外,静态数组也稳定性一些,不需要记着去释放。
3.文件操作。在VDSP的SETTING下,有一个STDIO的开关,其实可以支持文件操作,但是我调试的时候发现,有些情况下是有问题的。比如我在一个循环中使用fread,但是他只有第一次的读取是有效的,但有些时候,它好像又可以。所以,你调试的时候,如果发现结果和VC下运行的不同,可以重点看看,是不是这里出了问题。
4.调试跟踪。经过上面的准备,程序已经可以运行了。你可以在Simulator下仿真,或者板子上直接仿真。在SI下,速度会很慢,不过
Sesion里面,有一个blackfin
family那个sision,速度还可以,当然,有板子会更好。我们开发的时候,我使用板子的时间总共不到两个月,所以浪费了很多时间,现在回头看看,好心痛。
调试结果OK了的话,说明移植已经成功了。就可以进入下一个最主要的阶段---优化了

DSP CACHE操作选项说明

直写式(write
through),也叫写透。即CPU在向Cache写入数据的同时,也把数据写入主存以保证Cache和主存中相应单元数据的一致性,其特点是简单可靠,但由于CPU每次更新时都要对主存写入,速度必然受影响。    
回写式(write
back)即CPU只向Cache写入,并用标记加以注明,直到Cache中被写过的块要被进入的信息块取代时,才一次写入主存。这种方式考虑到写入的往往是中间结果,每次写入主存速度慢而且不必要。其特点是速度快,避免了不必要的冗余写操作,但结构上较复杂。 
当CPU要进行写入操作时,只把数据写入Cache,而不直接写入主内存。这时,Cache与主内存之间会出现暂时不一致的数据块。当Cache中的不一致数据块将要被替代时,再把数据写回主内存,从而使Cache中的数据与主内存中的数据又再保持一致。在此方式下,需要在Cache中加入一个控制位(Dirty
bit),若Cache中的某数据块是由CPU写入的,则控制位=1,否则控制位=0。发生块替代时,Cache先检查被替代块的控制位,若控制位=0,则无需把内容写回主内存,若控制位=1,则执行写回操作。这样做的好处是当CPU多次刷新同一数据块时,只需把最后的结果写回主内存即可,从而避免了重复写入,因而具有较高的效率。在早期版本的BIOS中,用户还可以对采用写通方式还是写回方式进行设置,但在新版本的BIOS中已取消了这一设置。
可以认为Dirty表示cache中的数据被更改了
invalidate()则将内存中数据写入高速缓冲存储器。
因此,可以简单认为:在写之前需要invaliate,(invalidate里包含了writeback操作)
若一个cache是dirty的,则若需要对这块cache进行写操作时,需要将它writeback。

CCS中各个项目文件的作用

1.include头文件(.h)的主要作用
头文件,一般用于定义程序中的函数、参数、变量和一些宏单元,同库函数配合使用。因此,在使用库时,必须用相应的头文件说明。

2.DSP/BIOS CONFIG FILES
开发基于DSP/BIOS的程序保存BIOS配置之后自动产生的文件。在保存BIOS配置时候会产生program.cbd/programcfg.h54/programcfg.s54/programcfg.cmd/programcfg.h/programcfg_c.c(C5000的example,program为你的项目名),这些文件被分配在project不同目录。

3.Source Files
源程序,实现DSP系统指定功能的主要代码部分

4.Program.cmd
链接文件,在源文件经过汇编器(Assembler)输出的OBJ Files(目标文件)需要通过Linker(链接器)才能得到OUT files,在链接阶段Linker根据.cmd里面存储区、Section分配以及lib来链接rst.lib、csl.lib、DSP/BIOS library跟对段的重定位

5.Library Filers的作用
Rst.lib:C语言实时运行支持库,建立C运行环境,由_c_int00主要完成设置堆栈指针、初始化全局变量、调用main()
Csl.lib:芯片支持库,实现片内外设的操作
DSPLIB/IMGLIB:信号处理库,利用针对不同DSP的优化的函数进行数学运算
通用的视/音LIB:例如263、264、jpeg、G.7XX、mp3、wmv。。。
其他自己封装的LIB:例如bsl.lib(board source library),对DSP系统板上资源的操作。

其他文件:
.opt工程关于开发环境的参数文件。如工具条位置等信息;
.aps (AppStudio File),资源辅助文件,二进制格式,一般不用去管他.
.clw ClassWizard信息文件,实际上是INI文件的格式,有兴趣可以研究一下.有时候ClassWizard出问题,手工修改CLW文件可以解决.如果此文件不存在的话,每次用ClassWizard的时候绘提示你是否重建.
.dsp (DeveloperStudio Project):项目文件,文本格式,不过不熟悉的话不要手工修改.DSW(DeveloperStudio
Workspace)是工作区文件,其他特点和DSP差不多.
.plg 是编译信息文件,编译时的error和warning信息文件(实际上是一个html文件),一般用处不大.在Tools->Options里面有个选项可以控制这个文件的生成.
.hpj (Help Project)是生成帮助文件的工程,用microsfot Help Compiler可以处理.
.mdp (Microsoft DevStudio
Project)是旧版本的项目文件,如果要打开此文件的话,会提示你是否转换成新的DSP格式.
.bsc 是用于浏览项目信息的,如果用Source Brower的话就必须有这个文件.如果不用这个功能的话,可以在Project Options里面去掉Generate Browse Info File,可以加快编译速度.
.map 是执行文件的映像信息纪录文件,除非对系统底层非常熟悉,这个文件一般用不着.
.pch (Pre-Compiled File)是预编译文件,可以加快编译速度,但是文件非常大.
.pdb (Program Database)记录了程序有关的一些数据和调试信息,在调试的时候可能有用.
.exp 只有在编译DLL的时候才会生成,记录了DLL文件中的一些信息.一般也没什么用.
.ncb 无编译浏览文件(no compile browser)。当自动完成功能出问题时可以删除此文件。build后会自动生成。

转一个哥们儿的简历

http://www.soyudesign.com/zblog/post/209.html

求职意向: 嵌入式 or DSP开发工程师

教育背景: 2002年9月-2006 年7月:西安电子科技大学

项目经验:

1.
智能视频监控产品:基于DM642平台,负责软硬件及相关算法开发工作(以及相关的技术文档编写):

1) 硬件方面:

电路图PCB改版设计(使用PROTEL),硬件电路板焊接调试,

CPLD(ALTERA MAX II EMP240)程序编写,实现看门狗功能等(Verilog语言);

2) 软件方面:

DM642主程序框架的搭建,基于DSP/BIOS,采用RF5框架,

DM642驱动程序编写(EDMA,串口及云台控制,I2C,网络,FLASH,BOOT烧写启动,音频视频输入输出mini驱动),

PC端网络接收程序编写(基于TI及合众达demo程序修改);

3) 算法方面:

MPEG4算法:编码算法在DM642平台的移植及优化(程序结构调整,已经汇编优化等),

音频编解码算法在DM642平台的移植(G.711、G.726等算法),

智能视频算法:参与技术讨论(区域入侵、阴影去除、目标跟踪、人脸识别等算法),DM642平台部分算法的验证及移植(验证基于模板匹配的跟踪算法,移植mean
shift跟踪算法)。

2.
智能交通项目:基于DM642平台(硬件由大恒图像公司负责提供),负责软件及算法开发工作(以及相关的技术文档编写):

1) 软件方面:

DM642 主程序框架的搭建,基于DSP/BIOS,

DM642 FLASH烧写及boot实现,利用flashburn工具烧写;

2) 算法方面:

参与技术讨论(车牌定位分隔识别,车流密度检查等算法),

车牌字符识别算法在PC上实现及在DM642平台的移植(主要利用特征提取模板匹配算法)。

3.
DAVINCI开发项目:是与北京维德利公司智能视频监控产品的合作项目,基于DM6441
DAVINCI平台(硬件及相应linux驱动由上海通力公司负责提供),负责智能视频算法的移植整合以及linux下应用软件的开发工作:

1) 算法方面:

智能视频算法(区域入侵、摄像头诊断、丢包检测算法)在DAVINCI平台的移植,按照TI
xDM算法标准对这些算法进行打包;

2) 软件方面:

对应上面的算法编写相应的ARM端嵌入式应用程序,实现从视频驱动获取视频图像传给DSP算法端以及将算法处理结果输出等。

4. ADI BF561开发项目:基于ADI BlackFin BF561平台,负责软件及算法开发工作:

1) 软件方面:

主程序框架的搭建,

视频输入输出驱动的开发;

2) 算法方面:

摄像头消抖算法的移植验证。

5. PC上MPEG4编解码开发项目:

1) 编码方面:

算法优化,涉及到程序结构的调整,汇编优化(mmx、sse、sse2等),

2) 解码方面:

算法的实现以及优化,使用了intel的IPP库,解码速度为axis公司解码器速度的2/3。

6. 基于硬件压缩的视频监控产品:

1) Z1510 MPEG1视频监控产品:电路图设计
PCB,DOS应用程序(嵌入式)及驱动开发(cf卡、视频输入)。

2) SAA6752
MPEG2视频监控产品:电路图设计、PCB、DOS应用程序(嵌入式)及驱动开发(cf卡、视频输入)。

3) FIC8120 MPEG4 IP camera产品:电路图设计,PCB,linux
(arm9)应用程序及驱动开发(按键、 LED、 Flash、
boot、视频输入(SAA7113)输出(SAA7121))。

7. 其他的一些项目及产品开发等工作:

1) DSP5402的USB项目:处理器为TI
TMS320VC5402,usb接口芯片为PDIUSBD12,负责dsp端usb驱动程序以及PC端测试应用程序的编写(驱动采用D12通用驱动);

2) 使用过的其他器件:

ARM:S3C2410、S3C2440(驱动及应用程序),

单片机:c51、c8051F、MSP430、AVR、68HC等系列(软件硬件都做),

FPGA:EP1C3T144、EP1C6Q240(硬件以及Verilog程序,熟悉NIOS硬核),

DSP:TMS320F2407(驱动程序);

3) 使用的开发工具:

PC软件开发:

VC、C++builder、Matlab,

嵌入式软件开发:

Keil、IAR430、CodeWarrior、ICC、ADS、CCS、Visualdsp、VMware,

嵌入式硬件开发:

PROTEL、OrCad、Quartus、

熟练使用示波器外用表等硬件调试工具,熟练器件焊接。

4) 维护公司服务器(server 2003)以及网站(论坛后台)等。

自我评价:

知识结构比较完善,自学能力强,富有创造性思维,敢于做尝试性挑战性工作。
附录

大学期间的项目经验:
2004.9 -2004.12《声音定向系统》

实现功能:探测10米范围内声源方位。负责系统方案制定及硬件电路设计工作,该项目获2004年"首届全国大学生
IC设计大赛" 本科组一等奖。
在此期间还参加了"中国集成电路设计产业发展十周年高层论坛暨中国半导体行业协会集成电路设计分会'2004年会"。
成员:3人;
2004.12 《墙体探测器》

实现功能:探测墙内7厘米范围是否有异物,作品以"构思新颖,独特创新"获2004年校"星火杯"特等奖。
2005.1 -2005.5 《智能媒体播放器》

负责脉搏采集部分方案制定和模拟电路设计,该项目获2005
"DSP西部高校邀请赛"团体入围奖。 成员:6人;
2005.6 《3D显示器》

参加全国挑战杯项目,负责系统分析及硬件电路设计,并参与机械部分设计
成员:3人;
2005.9 《简易频谱分析仪》

此为参加全国电子设计竞赛所选题目,基本完成题目要求,获陕西赛区二等奖。主要负责主控芯片的编程工作,采用MSP430F149单片机作为主控芯片,
EP1C6Q240 FPGA实现外围控制和部分高速处理。
成员:3人;
2004.8 《基于DSP5416的脉象采集及分析系统》

项目方案来自《智能媒体播放器》,根据其心情识别部分所做改动,负责其系统硬件设计及编程,(算法来自《智能媒体播放器》心情识别部分)
成员:2人;
2003.12 《USB串口并口转换器》

使用PDIUSBD12,完成USB1.1接口转换功能;
2003.12 《USB2.0接口应用》

使用ISP1581 ,采用51单片机作为主控芯片,完成 USB2.0数据收发;
2004.3 《三角法激光测距仪》

负责硬件电路部分设计,该项目是与西安某公司合作;
2005.10 《nRF905无线收发模块》

功能:采用TI5402
DSK板,结合本模块实现语音信号的采集传输及回放,参与电路测试及软件调试,该项目以被列为TI-XD
DSP 实验室学生试验题目。成员:3人。
2006.1 -2006.6《TPMS汽车轮胎压力监测系统》

这是毕业设计所选题目,采用FREESCALE方案,所用主要芯片为:MC68hc908RF2,MC33594,MPXY8020A
,完成系统样机。

Linux/Unix环境下的Make和Makefile语法和详解

无论是在Linux还是在Unix环境中,make都是一个非常重要的编译命令。不管是自己进行项目开发还是安装应用软件,我们都经常要用到
make或make
install。利用make工具,我们可以将大型的开发项目分解成为多个更易于管理的模块,对于一个包括几百个源文件的应用程序,使用make和
makefile工具就可以简洁明快地理顺各个源文件之间纷繁复杂的相互关系。而且如此多的源文件,如果每次都要键入gcc命令进行编译的话,那对程序员
来说简直就是一场灾难。而make工具则可自动完成编译工作,并且可以只对程序员在上次编译后修改过的部分进行编译。因此,有效的利用make和
makefile工具可以大大提高项目开发的效率。同时掌握make和makefile之后,您也不会再面对着Linux下的应用软件手足无措了。
但令人遗憾的是,在许多讲述Linux应用的书籍上都没有详细介绍这个功能强大但又非常复杂的编译工具。在这里我就向大家详细介绍一下make及其描述文件makefile。
Makefile文件
Make工具最主要也是最基本的功能就是通过makefile文件来描述源程序之间的相互关系并自动维护编译工作。而makefile
文件需要按照某种语法进行编写,文件中需要说明如何编译各个源文件并连接生成可执行文件,并要求定义源文件之间的依赖关系。makefile
文件是许多编译器–包括 Windows NT
下的编译器–维护编译信息的常用方法,只是在集成开发环境中,用户通过友好的界面修改
makefile 文件而已。
在 UNIX 系统中,习惯使用 Makefile 作为 makfile
文件。如果要使用其他文件作为 makefile,则可利用类似下面的 make
命令选项指定 makefile 文件:
$ make -f Makefile.debug
例如,一个名为prog的程序由三个C源文件filea.c、fileb.c和filec.c以及库文件LS编译生成,这三个文件还分别包含自己的
头文件a.h
、b.h和c.h。通常情况下,C编译器将会输出三个目标文件filea.o、fileb.o和filec.o。假设filea.c和fileb.c都要
声明用到一个名为defs的文件,但filec.c不用。即在filea.c和fileb.c里都有这样的声明:
#include "defs"
那么下面的文档就描述了这些文件之间的相互联系:
———————————————————
#It is a example for describing makefile
prog : filea.o fileb.o filec.o
cc filea.o fileb.o filec.o -LS -o prog
filea.o : filea.c a.h defs
cc -c filea.c
fileb.o : fileb.c b.h defs
cc -c fileb.c
filec.o : filec.c c.h
cc -c filec.c
———————————————————-
这个描述文档就是一个简单的makefile文件。
从上面的例子注意到,第一个字符为 #
的行为注释行。第一个非注释行指定prog由三个目标文件filea.o、fileb.o和filec.o链接生成。第三行描述了如何从prog所依赖的
文件建立可执行文件。接下来的4、6、8行分别指定三个目标文件,以及它们所依赖的.c和.h文件以及defs文件。而5、7、9行则指定了如何从目标所
依赖的文件建立目标。
当filea.c或a.h文件在编译之后又被修改,则 make
工具可自动重新编译filea.o,如果在前后两次编译之间,filea.C 和a.h
均没有被修改,而且test.o还存在的话,就没有必要重新编译。这种依赖关系在多源文件的程序编译中尤其重要。通过这种依赖关系的定义,make
工具可避免许多不必要的编译工作。当然,利用Shell脚本也可以达到自动编译的效果,但是,Shell
脚本将全部编译任何源文件,包括哪些不必要重新编译的源文件,而 make
工具则可根据目标上一次编译的时间和目标所依赖的源文件的更新时间而自动判断应当编译哪个源文件。
Makefile文件作为一种描述文档一般需要包含以下内容:
◆ 宏定义
◆ 源文件之间的相互依赖关系
◆ 可执行的命令
Makefile中允许使用简单的宏指代源文件及其相关编译信息,在Linux中也称宏为变量。在引用宏时只需在变量前加$符号,但值得注意的是,如果变量名的长度超过一个字符,在引用时就必须加圆括号()。
下面都是有效的宏引用:
$(CFLAGS)
$2
$Z
$(Z)
其中最后两个引用是完全一致的。
需要注意的是一些宏的预定义变量,在Unix系统中,$*、$@、$?和$<四个特殊宏的值在执行命令的过程中会发生相应的变化,而在GNU
make中则定义了更多的预定义变量。关于预定义变量的详细内容,宏定义的使用可以使我们脱离那些冗长乏味的编译选项,为编写makefile文件带来很
大的方便。
———————————————————
# Define a macro for the object files
OBJECTS= filea.o fileb.o filec.o
# Define a macro for the library file
LIBES= -LS
# use macros rewrite makefile
prog: $(OBJECTS)
cc $(OBJECTS) $(LIBES) -o prog
……
———————————————————
此时如果执行不带参数的make命令,将连接三个目标文件和库文件LS;但是如果在make命令后带有新的宏定义:
make "LIBES= -LL -LS"
则命令行后面的宏定义将覆盖makefile文件中的宏定义。若LL也是库文件,此时make命令将连接三个目标文件以及两个库文件LS和LL。
在Unix系统中没有对常量NULL作出明确的定义,因此我们要定义NULL字符串时要使用下述宏定义:
STRINGNAME=
Make命令
在make命令后不仅可以出现宏定义,还可以跟其他命令行参数,这些参数指定了需要编译的目标文件。其标准形式为:
target1 [target2 …]:[:][dependent1 …][;commands][#…]
[(tab) commands][#…]
方括号中间的部分表示可选项。Targets和dependents当中可以包含字符、数字、句点和"/"符号。除了引用,commands中不能含有"#",也不允许换行。
在通常的情况下命令行参数中只含有一个":",此时command序列通常和makefile文件中某些定义文件间依赖关系的描述行有关。如果与目
标相关连的那些描述行指定了相关的command序列,那么就执行这些相关的command命令,即使在分号和(tab)后面的aommand字段甚至有
可能是NULL。如果那些与目标相关连的行没有指定command,那么将调用系统默认的目标文件生成规则。
如果命令行参数中含有两个冒号"::",则此时的command序列也许会和makefile中所有描述文件依赖关系的行有关。此时将执行那些与目标相关连的描述行所指向的相关命令。同时还将执行build-in规则。
如果在执行command命令时返回了一个非"0″的出错信号,例如makefile文件中出现了错误的目标文件名或者出现了以连字符打头的命令字符串,make操作一般会就此终止,但如果make后带有"-i"参数,则make将忽略此类出错信号。
Make命本身可带有四种参数:标志、宏定义、描述文件名和目标文件名。其标准形式为:
Make [flags] [macro definitions] [targets]
Unix系统下标志位flags选项及其含义为:
-f
file  指定file文件为描述文件,如果file参数为"-"符,那么描述文件指向标准输入。如果没有"-f"参数,则系统将默认当前目录下名为
makefile或者名为Makefile的文件为描述文件。在Linux中, GNU make
工具在当前工作目录中按照GNUmakefile、makefile、Makefile的顺序搜索
makefile文件。
-i   忽略命令执行返回的出错信息。
-s   沉默模式,在执行之前不输出相应的命令行信息。
-r   禁止使用build-in规则。
-n   非执行模式,输出所有执行命令,但并不执行。
-t   更新目标文件。
-q   make操作将根据目标文件是否已经更新返回"0″或非"0″的状态信息。
-p   输出所有宏定义和目标文件描述。
-d   Debug模式,输出有关文件和检测时间的详细信息。
Linux下make标志位的常用选项与Unix系统中稍有不同,下面我们只列出了不同部分:
-c dir   在读取 makefile 之前改变到指定的目录dir。
-I dir   当包含其他 makefile文件时,利用该选项指定搜索目录。
-h   help文挡,显示所有的make选项。
-w   在处理 makefile 之前和之后,都显示工作目录。
通过命令行参数中的target
,可指定make要编译的目标,并且允许同时定义编译多个目标,操作时按照从左向右的顺序依次编译target选项中指定的目标文件。如果命令行中没有指定目标,则系统默认target指向描述文件中第一个目标文件。
通常,makefile 中还定义有 clean
目标,可用来清除编译过程中的中间文件,例如:
clean:
rm -f *.o
运行 make clean 时,将执行 rm -f *.o
命令,最终删除所有编译过程中产生的所有中间文件。
隐含规则
在make
工具中包含有一些内置的或隐含的规则,这些规则定义了如何从不同的依赖文件建立特定类型的目标。Unix系统通常支持一种基于文件扩展名即文件名后缀的隐
含规则。这种后缀规则定义了如何将一个具有特定文件名后缀的文件(例如.c文件),转换成为具有另一种文件名后缀的文件(例如.o文件):
.c:.o
$(CC) $(CFLAGS) $(CPPFLAGS) -c -o $@ $<
系统中默认的常用文件扩展名及其含义为:
.o  目标文件
.c  C源文件
.f  FORTRAN源文件
.s  汇编源文件
.y  Yacc-C源语法
.l  Lex源语法
在早期的Unix系统系统中还支持Yacc-C源语法和Lex源语法。在编译过程中,系统会首先在makefile文件中寻找与目标文件相关的.C
文件,如果还有与之相依赖的.y和.l文件,则首先将其转换为.c文件后再编译生成相应的.o文件;如果没有与目标相关的.c文件而只有相关的.y文件,
则系统将直接编译.y文件。
而GNU make
除了支持后缀规则外还支持另一种类型的隐含规则–模式规则。这种规则更加通用,因为可以利用模式规则定义更加复杂的依赖性规则。模式规则看起来非常类似于
正则规则,但在目标名称的前面多了一个 %
号,同时可用来定义目标和依赖文件之间的关系,例如下面的模式规则定义了如何将任意一个
file.c 文件转换为 file.o 文件:
%.c:%.o
$(CC) $(CFLAGS) $(CPPFLAGS) -c -o $@ $<
#EXAMPLE#
下面将给出一个较为全面的示例来对makefile文件和make命令的执行进行进一步的说明,其中make命令不仅涉及到了C源文件还包括了
Yacc语法。本例选自"Unix Programmer's Manual 7th Edition, Volume 2A" Page
283-284
下面是描述文件的具体内容:
———————————————————
#Description file for the Make command
#Send to print
P=und -3 | opr -r2
#The source files that are needed by object files
FILES= Makefile version.c defs main.c donamc.c misc.c file.c \
dosys.c gram.y lex.c gcos.c
#The definitions of object files
OBJECTS= vesion.o main.o donamc.o misc.o file.o dosys.o gram.o
LIBES= -LS
LINT= lnit -p
CFLAGS= -O
make: $(OBJECTS)
cc $(CFLAGS) $(OBJECTS) $(LIBES) -o make
size make
$(OBJECTS): defs
gram.o: lex.c
cleanup:
-rm *.o gram.c
install:
@size make /usr/bin/make
cp make /usr/bin/make ; rm make
#print recently changed files
print: $(FILES)
pr $? | $P
touch print
test:
make -dp | grep -v TIME>1zap
/usr/bin/make -dp | grep -v TIME>2zap
diff 1zap 2zap
rm 1zap 2zap
lint: dosys.c donamc.c file.c main.c misc.c version.c gram.c
$(LINT) dosys.c donamc.c file.c main.c misc.c version.c \
gram.c
rm gram.c
arch:
ar uv /sys/source/s2/make.a $(FILES)
———————————————————-
通常在描述文件中应象上面一样定义要求输出将要执行的命令。在执行了make命令之后,输出结果为:
$ make
cc -c version.c
cc -c main.c
cc -c donamc.c
cc -c misc.c
cc -c file.c
cc -c dosys.c
yacc gram.y
mv y.tab.c gram.c
cc -c gram.c
cc version.o main.o donamc.o misc.o file.o dosys.o gram.o \
-LS -o make
13188+3348+3044=19580b=046174b
最后的数字信息是执行"@size
make"命令的输出结果。之所以只有输出结果而没有相应的命令行,是因为"@size
make"命令以"@"起始,这个符号禁止打印输出它所在的命令行。
描述文件中的最后几条命令行在维护编译信息方面非常有用。其中"print"命令行的作用是打印输出在执行过上次"make
print"命令后所有改动过的文件名称。系统使用一个名为print的0字节文件来确定执行print命令的具体时间,而宏$?则指向那些在print
文件改动过之后进行修改的文件的文件名。如果想要指定执行print命令后,将输出结果送入某个指定的文件,那么就可修改P的宏定义:
make print "P= cat>zap"
在Linux中大多数软件提供的是源代码,而不是现成的可执行文件,这就要求用户根据自己系统的实际情况和自身的需要来配置、编译源程序后,软件才能使用。只有掌握了make工具,才能让我们真正享受到到Linux这个自由软件世界的带给我们无穷乐趣。

quickfix提高vim编程编译调试效率

以前使用vim编程时,在终端下面至少2个tab,一个编辑一个编译,编译出错时,切换到编辑tab页进行差错纠正。今天又学习了vim的quickfix模式,quickfix是vim自带的,无需插件。

vim由一个程序员开发,而且为更多的程序员所使用,所以在vim中加强了对软件开发的支持,quickfix模式的引入就是一个例子。所谓quickfix模式,它和Normal模式、Insert模式没什么关系,它只是一种加快你开发速度的工作方式。
Quickfix模式的主要思想是保存一个位置列表,然后提供一系列命令,实现在这个位置列表中跳转。
位置列表的产生可以从编译器的编译输出信息中获得,也可以由grep命令的输出信息中获得。

[编译]
通常,我们在开发过程中,经常要写代码,编译,修改编译错误,这个过程会数十遍上百遍的重复。如果你是根据编译器输出的错误信息,打开出错的文件,找到出错的行,然后再开始修改,那效率未免太低下了。
利用vim的quickfix模式,可以大大加快这一过程,你可以在vim启动编译,然后vim会根据编译器输出的错误信息,自动跳到第一个出错的地方,让你进行修改;修改完后,使用一个快捷键,跳到下一个错误处,再进行修改,方便的很。
为了做到这一点,你首先要定义编译时所使用的程序,对大多数使用Makefile的项目来说,vim的缺省设置"make"已经可以满足要求了。如果你的项目需要用一个特殊的程序进行编译,就需要修改'makeprg'选项的值。
大家在学编程时大概都读过"hello world"程序,我们就以这个简单的例子为例,讲一下quickfix模式的用法。

该程序的内容如下,里面包含了三个小小的错误:
/* hello world demo */
#include <stdio.h"
int main(int argc, char **argv)
{
int i;
print("hello world\n");
return 0;
}

输入编译命令了:
:make
在使用":make"时,vim会自动编译,并把编译输出重定向到一个临时文件中,当编译出现错误时,vim会从上述临时文件中读出错误信息,根据这些信息形成quickfix列表,并跳转到第一个错误出现的地方。
对于我们上面的程序来说,光标会停在第三行,也就是第一个出错的位置,vim同时会提示出错信息。如果你没看清出错信息,可以输入":cc"命令,vim会更次显示此信息,或者干脆使用":cw"命令,打开一个quickfix窗口,把所有的出错信息显示出来,见下图:


现在我们知道错在哪儿了,修正一下,然后使用":cn"命令(或者在Quickfix List对应行上输入回车)跳到下一个出错的地方,以此类推,直到修正全部错误。
好了,千辛万苦,我们的hello world终于工作了。乍一看这个例子,似乎Quickfix并没有提高什么效率,但如果你的错误出现在多个不同目录的不同文件里,它可以帮你省很多时间,使你可以集中精力在修正bug上。
vim可以同时记住最新的10个错误列表,也就是说你最近10次使用":make"命令编译所遇到的错误都保存着,可以使用":colder"和":cnewer"命令,回到旧的错误列表,或者到更新的错误列表。

在quickfix模式里经常用到的命令有:
:cc 显示详细错误信息 ( :help :cc )
:cp 跳到上一个错误 ( :help :cp )
:cn 跳到下一个错误 ( :help :cn )
:cl 列出所有错误 ( :help :cl )
:cw 如果有错误列表,则打开quickfix窗口 ( :help :cw )
:col 到前一个旧的错误列表 ( :help :col )
:cnew 到后一个较新的错误列表 ( :help :cnew )

更多的命令,以及这些命令更详细的解释,请参见手册。
对于经常用到的命令,最好提供更方便的使用方法,在我的vimrc中的定义:
autocmd FileType c,cpp map <buffer> <leader><space> :w<cr>:make<cr>
nmap <leader>cn :cn<cr>
nmap <leader>cp :cp<cr>
nmap <leader>cw :cw 10<cr>

现在使用",<space>"(先按,再按空格)就可以编译,使用",cp"和",cn"跳到上一个和下一个错误,使用",cw"来打开一个quickfix窗口。这下顺手多了!
如果你希望跳转到出错的文件时,使用一个分隔的窗口打开,请参阅'switchbuf'选项的值。
在vim7中,每个窗口都可以拥有自己的位置列表,这样,你就能够同时打开多个位置列表了,而quickfix列表在整个vim中只有一个。你可以使用位置列表来显示编译错误信息,具体命令参阅手册:":help location-list"以及":help :lmake"。

结合文章http://dongpingli.blogspot.com/2009/03/makefile_27.html编写的通用makefile,这下在写新程序时,直接copy makefile到程序目录,在vim里面写完程序后直接make,然后查错修改在一个tab下,省得来回tab切换,效率会提高不少。