1.MDK中的char类型的取值范围是?
在MDK中,默认情况下,char 类型的数据项是无符号的,所以它的取值范围是0~255。它们可以显式地声明为signed char 或 unsigned。因此,定义有符号char类型变量,必须用signed显式声明。我曾读过一本书,其中有一句话:“signed关键字也是很宽宏大量,你也可以完全当它不存在,在缺省状态下,编译器默认数据位signed类型”,这句话便是有异议的,我们应该对自己所用的CPU构架以及编译器熟练掌握。
2.赋初值的全局变量和静态变量,初值被放在什么地方?
- unsigned int g_unRunFlag=0xA5;
- static unsigned int s_unCountFlag=0x5A;
这两行代码中,全局变量和静态变量在定义时被赋了初值,MDK编译环境下,你知道这个初值保存在那里吗?
对于在程序中赋初值的全局变量和静态变量,程序编译后,MDK将这些初值放到Flash中,紧靠在可执行代码的后面。在程序进入main函数前,会运行一段库代码,将这部分数据拷贝至相应RAM位置。若是你不小心将这些位置的数据擦除掉,嘿嘿...反正我是碰到了。
PS:后来看ARM的链接器,才知道ARM映象文件各组成部分在存储系统中的地址有两种:一种是在映象文件位于存储器中时(也就是该映象文件开始运行之前,通俗的说就是下载到Flash中的二进制代码)的地址,称为加载地址;一种是在映象文件运行时(通俗的说就是给板子上电,开始运行Flash中的程序了)的地址,称为运行时地址。赋初值的全局变量和静态变量在程序还没运行的时候,初值是被放在Flash中的,这个时候他们的地址称为加载地址,当程序运行后,这些初值会从Flash中拷贝到RAM中,这时候就是运行时地址了。
3.最新的keil MDK(V4.54)在编辑界面中已经可以支持中文编码了,所以可以在编辑器中直接输入汉字和中文标点符号,再也不会显示乱码或者不显示了。虽然乱写汉字和中文标点在编译时依然会报错,但好歹能显示,也从侧面说明中国市场的崛起。开启方法见http://blog.csdn.net/zhzht19861011/article/details/7741928 不再贴了。
我还清楚的记得自己在大学刚开始用Keil C51那会,一次不小心在一行代码后面用了个中文分号,在当时这个中文分号是不被显示的,然后编译,编译器报错,我双击报错信息定位到报错的代码行,却怎么也检查不出来错误来,当时着急的心情现在想想还很好笑的,那个时候只能将错误代码行用双斜杠注释掉,才能看到那个中文分号。但从V4.54之后,就应该再不会遇到我当时的情况了。
4.不知道从什么版本开始,keil MDK的标题栏可以显示工程路径了,我是从V4.10直接升级到V4.54,V4.10的标题栏还是下图的这个样子:
如果你同一个工程有多个备份,你有同时打开了多个备份工程,要想识别出那个工程是那个备份,可是件不容易的事情,还好,keil更新较快.
5.这一条真伪未知,因为我搜索了很久都没有查证.
在一个论坛上看到的,Keil原来是一个人名,住在德国,最初的keil C51编译器就是他开发的.为人低调,话不多,但超级认真.当然,也超级厉害.
6.Stack分配到RAM的哪个地方?
keil MDK中,我们只需要定义各个模式下的堆栈大小,编译器会自动在RAM的空闲区域选择一块合适的地方来分配给我们定义的堆栈,这个地方位于RAM的那个地方呢?通过查看编译列表文件,原来MDK将堆栈放到程序使用到的RAM空间的后面,比如你的RAM空间从0x4000 0000开始,你的程序用掉了0x200字节RAM,那么堆栈空间就从0x4000 0200处开始。具体的RAM分配,其实你可以从编译后生成的列表文件“工程名.map”文件中查看。
7.有多少RAM会被初始化?
大家可能都已经知道,在进入main()函数之前,MDK会把未初始化的RAM给清零的(在程序中自己定义变量初值的见第二条),但MDK会不会把所有RAM都初始化呢?答案是否定的,MDK只是把你的程序用到的RAM以及堆栈RAM给初始化,其它RAM的内容是不管的。如果你要使用绝对地址访问MDK未初始化的RAM,那就要小心翼翼的了,因为这些RAM的内容很可能是随机的,每次上电都不同。至少,NXP的LPC2000系列就是这样。
8.还是一个新版本的变化,还是关于版本V4.10和V4.54
V4.10版本,只要你重新打开工程,点击"Build target files"(就这个图标:),编译器就会将所有文件都编译一次,不管你的文件在这之前有没改动.但V4.54就不一样了,再次打开文件,点击"Build target files"它会只编译改过的文件的.早该这么做了,每次打开工程都要编译个十几秒钟,着实等的难受.
9.好个一丝不苟的编译器
这是个十分奇葩的问题,碰巧被我遇到了,我承认是我代码写的不够规范,但正是这个不规范的代码,才得以发现这个奇葩的事件。实在忍不住用了两个奇葩来形容。把过程简化一下,如下所述:
假如你的工程至少有两个.c文件,其中一个为timer.c,里面有个定时器中断程序,每10ms中断一次,定义一个变量来统计定时器中断次数:
- unsigned int unIdleCount;
- extern unsigned int unIdleCount;
在main.c函数中,包含timer.h文件,并利用定时器变量 unIdleCount来精确延时2秒,代码如下:
- unIdleCount=0;
- while(unIdleCount!=200); //延时2S钟
- while(unIdleCount!=200);
- 122: unIdleCount=0;
- 123:
- 0x00002E10 E59F11D4 LDR R1,[PC,#0x01D4]
- 0x00002E14 E3A05000 MOV R5,#key1(0x00000000)
- 0x00002E18 E1A00005 MOV R0,R5
- 0x00002E1C E5815000 STR R5,[R1]
- 124: while(unIdleCount!=200); //延时2S钟
- 125:
- 0x00002E20 E35000C8 CMP R0,#0x000000C8
- 0x00002E24 1AFFFFFD BNE 0x00002E20
看到这里,也许你已经笑翻了:你这个小白,这很明显是没用volatile修饰变量unIdleCount造成的!!!不错,比起从RAM中读写数据,ARM或其它硬件从寄存器读取数据要快的多的多的多...因此编译器会“自作主张”的将某些变量读到寄存器中,再次运算时也优先从寄存器中读取,上面的例子就是这样。解决这样的方法是用关键字volatile修饰你不想让编译器优化的变量,明白的告诉编译器:你不准优化我,每次使用我你都要本本分分的从RAM中读取或写入RAM。
所以先不要笑,我是不会犯这种错误的,之所以从这里说起,是为了照顾下还不知道volatile关键字的。。。
其实在timer.c中我是这样定义统计定时器中断次数变量的:
- unsigned int volatile unIdleCount;
- extern unsigned int unIdleCount;
- 122: unIdleCount=0;
- 123:
- 0x00002E10 E59F11D4 LDR R1,[PC,#0x01D4]
- 0x00002E14 E3A05000 MOV R5,#key1(0x00000000)
- 0x00002E18 E1A00005 MOV R0,R5
- 0x00002E1C E5815000 STR R5,[R1]
- 124: while(unIdleCount!=200); //延时2S钟
- 125:
- 0x00002E20 E35000C8 CMP R0,#0x000000C8
- 0x00002E24 1AFFFFFD BNE 0x00002E20
现在,应该知道我要表达的意思了吧,如果引用的变量声明中没有使用volatile关键字修饰,即便定义这个变量的时候使用了volatile关键字修饰,MDK编译器照样优化掉它!
将timer.h中的声明更改为:
- extern unsigned int volatile unIdleCount;
- 122: unIdleCount=0;
- 123:
- 0x00002E10 E59F01D4 LDR R0,[PC,#0x01D4]
- 0x00002E14 E3A05000 MOV R5,#key1(0x00000000)
- 0x00002E18 E5805000 STR R5,[R0]
- 124: while(unIdleCount!=200); //延时2S钟
- 125:
- 0x00002E1C E5901000 LDR R1,[R0]
- 0x00002E20 E35100C8 CMP R1,#0x000000C8
- 0x00002E24 1AFFFFFC BNE 0x00002E1C
以这个为例子,一是说明关键字volatile,另外也提下这个有趣的编译器,不得不说,她好认真。再另外,我要买本编译原理的书看看了.