单片机下载

2076421855

Keil C是非常优秀的C51编译器，可能是最好的C51编译器，提供各种优化模式，对变量的优化和地址安排做得非常好。这是用C语言写代码的好处之一，如果用汇编写，得费一大番功夫给各个变量安排内存物理地址，还得时刻记住哪些地址的内存单元是已经分配了，新增加的变量就不能占用那些已经分配了的单元，以免产生内存交叠冲突和溢出。我一直非常信赖Keil
C51的编译结果，在我的印象里，它对内存的分配是完美的，只要代码用它编译时没有报告任何warning和error，代码运行时不可能内存冲突或溢出的现象。
但，今天发生的事情证明我错了。
手头上有个产品的代码，代码量很大。程序跑起来的效果不大好，因此打算把代码优化一下。代码量越大，通常可优化的地方也越多。对8051来说，访问芯片内部的data区（0~7FH）内存速度是最快的，直接访问，一条指令就能读写，而idata区（80H~FFH）虽然还是内存区，但由于地址分配上跟特殊寄存器SFR重合，只能间接地址访问，两条指令才能读写，速度稍慢点，而外存xdata区（0~7FFFH）必须使用DPTR指针才能访问，速度是最慢的。很明显，优化的原则就是尽量把频繁读写的变量优先安排在data区，然后是idata区，最后才是xdata区。
当我做完变量手工优化工作后，把编译模式设为SMALL，这样C51编译器会自动把那些我没手工指定存放区的变量优先安排进data区，如果超出有效地址范围，它会报错，因此我大可以放心。按下rebuild
all按钮后，编译器提示：
Program Size: data=236.2 xdata=19321
code=43372
"ipphone_main" - 0 Error(s),
0Warning(s).
编译器提示的data区包括了idata在内，按以往的经验来看，data区有256个byte，程序才使用了236.2个，还剩下19个，没有溢出，而xdata有32k，现在才使用了19k，远没有溢出，编译结果一切很正常。
把代码烧录进芯片跑起来后，结果出人意料，从现象来看，上电约1秒后就自动重启，重启后过1秒又重启，非常有规律的重启。
我没有怀疑是编译器的原因，当时第一念头是怀疑是看门狗，代码里上电后就打开了看门狗，可能某些子程序代码执行时间过长，看门狗复位了，于是在有

冰薄荷

Keil C是非常优秀的C51编译器