原创 一个有关0.0625℃的运算想到的问题

   
       碰到一哥们号称挺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之前来一级抗混叠滤波基本也就解决了，大有所谓嵌入软件高手的概念是程序几乎是万能，实在解决不了就换大程序空间更高速的处理器，整个恶性循环。
    经常听说现在流行低碳族，我想出色的嵌入软件工程师最容易成为低碳一族，只要让代码高效那处理器频率自然可以灵活降下来，自然耗电也就少了，二氧化碳排放也就少了。想想目前到处都是嵌入处理器，代码条数看来也别有效果。