EEPW论坛

问 我现在有两个程序需要合并，每个程序片内ram的使用都是160字节以上，毫无疑问，合起来ram肯定会爆。

希望各位给点建议，可以从哪些方面入手来减少ram的使用。如果把变量定义放到片外是否可行，有什么要注意的？

ps：我们使用77e58的片子。



另外，很纳闷，那个程序keil编译结果显示code超过32k，77e58code大小也只有32k，可是烧片子居然，没事，程序还照样跑。
看来77e58果然超强啊！ 答 1: 有问题的 答 2: 有什么问题的？ 答 3: 不妨试试有两个建议：一是重新优化你的代码；二是条件允许的话外扩SRAM。 答 4: 77e58片内有1280字节的RAM 答 5: 我想问的就是可以从哪些方面进行优化？
不知道通常可以从哪些方面进行优化啊，有哪些技巧的啊？ 答 6: 我早年使过7758，但是你最后描述的现象是绝对不可能的！我早年使过7758，但是你最后描述的现象是绝对不可能的！
那个时代使用7758仅仅因为她有2个串口！双dptr，片外ram多1千！ 答 7: 但是你最后描述的现象是绝对不可能的???是说这个绝对不可能吗？
另外，很纳闷，那个程序keil编译结果显示code超过32k，77e58code大小也只有32k，可是烧片子居然，没事，程序还照样跑。
看来77e58果然超强啊！


但是，很不好意思，我说的是事实，情况就是这样。 答 8: 不可能的?? 答 9: 不可能的??我认为你程序中超出32k的 代码 刚巧没有被调用，所以幸运的运行起来了，

存在隐患的。 答 10: 结果不可能，过程更蹊跷！首先编译器、链接器要报错，其次烧录器也要报错，否则若没人注意到这个情况，产品卖出去后出事，麻烦就大了。所以说“过程更蹊跷”！

工具软件必须有这种监测能力，否则不能实用！ 答 11: 扩啊.不能扩,压缩啊. 答 12: 不会是编译后输出的文件长度大于32K吧?你看到的是真实的代码长度吗? 答 13: 我也遇到类似的问题我也遇到类似的问题，我用的是AT89C51，最后提示rom=114，xdata=0，code=2410，
但是把code rom size编译模式改成compact或者large就没有问题了，但是我烧到单片机里面不能正确执行，不知道为什么？
我用的keilC
答 14: 两个问题1、keil编译结果的code是不是就是烧写代码所占空间？我编译结果的确code是超过32k的。
2、我说的跑起来了只是一些常用操作没问题，没有做全面测试，所以说“未烧进去的代码没被执行”也对。
3、“首先编译器、链接器要报错” ？
   keil没有报错，烧录软件也没有报错。 答 15: 同意leestrong我以前碰到过相同情况，不过超过32k的极少用到，因为是调试程序，产品成熟以后，连调试都不会用它 答 16: 呵呵32K实际是32*1024＝32768个字节，编译结果是以字节为单位的，可能是超过了32000，但还没有超过32768。 答 17: alphal不会是说编译出来的HEX文件超过32K了吧？ 答 18: 同一同一leestrong,平常人. 答 19: 用LPC2103,8k的ram,才两个美金。