发布: 2010-3-30 09:02 | 作者: cat_li | 来源: 电子爱好者社区
碰到一哥们号称挺NB的嵌入软件工程师,看了他的代码后就欧拉,事情是在一个只有4K代码的单片机接2个DS18B20测温传感器,都知道DS18B20输出数据只要乘以0.0625就是测量的温度值,这哥们说程序空间怎么也不够,实际上程序只有简单的采集两个DS18B20的数据转换成温度值,之后在1602液晶上显示,挺简单个程序,怎么也想不通为什么程序空间不够。只读了一下代码发现程序就没动脑子,真的用浮点库把DS18B20数据直接乘以0.0625了,那程序不超才怪呢,稍微动动脑子也会知道0.0625不就是1/16吗,把DS18B20的数据直接右移4位不就是了(当然要注意符号),这右移程序可十分简单还省空间,问题很好解决,空间自然也就够了。
现在想来嵌入处理器确实是进步了,程序空间是越来越大,数据RAM空间也越来越大,导致很多人在写程序的时候真的是什么都不顾,借着C语言的灵活性真是纵横驰骋,压根也不讲个程序效率和可靠性。正如前些日子见到一孩子用ARM cortex-m3处理器给人接活写个便携表的1024点FFT算法,本身12位的AD系统,这小家伙直接到网上下载了浮点的FFT算法代码就给人加上了,结果整个程序死慢死慢的,人家用户可不买单啊,这时要动动脑子把数据直接变成乘以某个数变成整数后用定点FFT处理,之后再把数据除一下不就行了。速度自然也快了,而且也能省下空间。实际当中我们做嵌入软件很多时候犯懒都忽视程序执行效率问题,是都能实现功能,但有时候就是没法谈性能。我几次碰到这样的工程师,直接把传感器的信号放大后进嵌入处理器的AD,也不看看AD数据是否稳定有效,直接就进行FFT运算,那FFT结果真是热闹,不难看出混叠很严重,于是又机械地在FFT基础上再去衍生算法,系统程序越做越大,速度越做越慢。实际上也很简单的事,在传感器放大信号进AD之前来一级抗混叠滤波基本也就解决了,大有所谓嵌入软件高手的概念是程序几乎是万能,实在解决不了就换大程序空间更高速的处理器,整个恶性循环。
经常听说现在流行低碳族,我想出 {MOD}的嵌入软件工程师最容易成为低碳一族,只要让代码高效那处理器频率自然可以灵活降下来,自然耗电也就少了,二氧化碳排放也就少了。想想目前到处都是嵌入处理器,代码条数看来也别有效果。
友情提示: 此问题已得到解决,问题已经关闭,关闭后问题禁止继续编辑,回答。
然后调用,每次都是一排程序(八行)。
(0003) const unsigned char tabled[]=
(0004) {0xC0,0xF9,0xA4,0xB0,0x99,0x92,0x82,0xF8,0x80,0x90,0xbf,0xff,0xff,0xff,0xff,0xff};
(0005) //0,1,2,3,4,5,6,7,8,9,-, , , , , ;"depcgbfa"共阳
(0006)
(0007) void main(void)
(0008) {
(0009) unsigned char x;
(0010)
(0011) x=5;
_main:
x --> R16
00044 E005 LDI R16,5
(0012)
(0013) PORTB=tabled[x];
00045 E080 LDI R24,0
00046 E091 LDI R25,1
00047 2FE0 MOV R30,R16
00048 27FF CLR R31
00049 0FE8 ADD R30,R24
0004A 1FF9 ADC R31,R25
0004B 8020 LD R2,Z
0004C B825 OUT 0x05,R2
(0014) PORTC=tabled[x+1];
0004D E081 LDI R24,1
0004E E091 LDI R25,1
0004F 2FE0 MOV R30,R16
00050 27FF CLR R31
00051 0FE8 ADD R30,R24
00052 1FF9 ADC R31,R25
00053 8020 LD R2,Z
00054 B828 OUT 0x08,R2
(0015)
(0016) while(1);
FILE: <library>
00055 CFFF RJMP 0x0055
00056 9508 RET
一周热门 更多>