使用的开发板是 Spartan 3A DSP 1800A 软件环境: Xilinx EDK 10.1.03 在实现lab4中的LED排灯的顺序点亮显示的时候,C语言代码如下: #include "xparameters.h" #define LEDChan 1 main() 在没有加volatile声明的情况下,每次上板子测试发现8个LED始终全部点亮。使用debug调试时发现,程序中已经没有i这个变量了,说明i被编译器给优化了,随后在定义i的前面加上volatile的声明,再次编译下载到板子上,终于看到了排灯的闪烁。 同时在网上搜了一下,发现一篇很好的文章,介绍了编译器的优化以及一些解决方案,现转载如下 感谢原文作者walkie的帮助 原文地址: [FPGA博客大赛]中断控制器不要乱加--edk基础实验lab3的一些再思考 继续lab3的一些思考。早上回到office的时候,发现Kevin给我提了一个很好的建议,让gcc针对某一个特定的函数不优化,而不要整个程序都不优化。那么只要把延迟函数不优化就好了,如此说不定还可以完整的放到8kbyte的bram中。找了一些方法,比如Kevin提出使用void barrier(void)函数,来告诉gcc不要去优化某部分代码,自己也google了一下想看看它的用法是怎样的。后来Ricky提出了可以使用: #pragma OPTIMIZE OFF 来实现。我觉得都很好的。但是我突然想到这些实验是有solution,我真是笨死了。看看它本来是如此的不就好了呢? 特别的我仔细查看了它的工程结构,觉得很奇怪,因为它把整个程序都放到了bram里面,但是我用同样的代码,同样的编译条件在自己的工程中对它进行编译,得到的executable.elf却无法放进和它一样大的bram中。觉得很奇怪,让我非常纳闷。交换了代码文件,交互了存储地方,得到的结果都是它工程编译出来的和我工程编译出来的二进制不一样大小。 这是我得到的文件的大小 mb-size executable.elf 这是它的 mb-size executable.elf 想想所有的代码都是一样的,编译条件也是一样的。但是为什么出来的结果不一样呢?它的是0×1fae<0×1fff,正好可以放到那个8KByte的Bram中。而上面是0x 205e,超过了8K的大小。 于是使用mb-objdump命令,把elf文件里信息dump出来,看看是不是真的有什么不同。打开edk的shell终端 #mb-objdump -S executable.elf >info1.txt 得到了两个txt文档,分别是info1和info2。比较了两个txt文档,总算发现了罪魁祸首了。发现自己的elf文件生成的info2里有这个函数<XIntc_DeviceInterruptHandler>,原来是我的系统中比原来的系统xps_intc这个中断控制器,而 RS232跟它有关系,当向stdout输出字符的时候,会自动的调用一些中断函数,虽然这些函数在自己的c程序中都没有,但是其实都算在了定层的驱动中。去掉这个IP,去掉这个中断控制器,世界恢复了平静~现在可以init到bram种了,所以lab3也不用修改的。
真是一波牵出另一波~由于习惯问题,自己在添加ip的时候都会选择使用中断,不管当前项目用不用,也许以后debug的时候会用到。另外自己也会添加timer这个ip。现在真是被它害了一次~不过也更加了解了其中的含义了。恩。
----------------- 18:13 和Ricky讨论了一下,结果发现了一个更简单的方法来对付我这种情况 只要在在申明变量的时候加一个参数volatile就好了。 尝试了一下,将gcc的优化选项变成O2,结果真的这段代码没有被优化掉了。
这个世界真是太奇妙了~又学到了一些东西:)
google了一下volatile的作用,在嵌入式中重要用于: 比如要往某一地址送两指令:
int *ip =...; //设备地址 *ip = 1; //{dy}个指令 *ip = 2; //第二个指令 以上程序compiler可能做优化而成: int *ip = ...; *ip = 2; 结果{dy}个指令丢失。如果用volatile, compiler就不允许做任何的优化,从而保证程序的原意: volatile int *ip = ...; *ip = 1; *ip = 2; 即使你要compiler做优化,它也不会把两次付值语句间化为一。它只能做其它的优化。这对device driver程序员很有用。 如 volatile char a;
a=0; while(!a){ //do some things; } doother(); 如果没有 volatile doother()不会被执行 |