本帖最后由 sedatefire 于 2012-1-13 23:16 编辑
/**************************************************************************************
* Filename:一线研发之声:嵌入式C编程经验 之 请写可移植性高的模块
* Author:SedateFire E-mail:SedateFire@126.com
* Version:1.000 Time: 2012-01-05
* key: 嵌入式 可移植性 模块化 依赖
**************************************************************************************/
我想你或许有这样的经验,你要实现的一个模块同事已经实现了。老板发话说:你复用他的代码啊,半天给我搞定。于是你拷过来编译一下,几乎是必然的,会有error有warning,一看,哇,原来依赖了这么多外部的东东。于是你开始着手修改它,如果模块小,自然三两下搞定。如果是个大的模块要复用,一下弹出几百个编译错误报警,我想你边修改心里也边骂娘。
我*,这个蜂鸣器控制函数为何要去判断当前在作什么应用?!
我*,这么多缺失的include文件,没有拷过来吗?
我*,这个函数是什么东东,注释明显对不上,还判断赋值了一堆全局变量。
我*,这个if处理了,那else呢,哪里去了?这是什么跟什么啊。
我*,通通删掉干掉,自己加班偷偷重写好了。
什么!老板在催了,我*靠靠啊…
想必你有共鸣了......
那么如何实现可移植性高的代码呢,我就先写几点吧,有些晚了,准备睡觉了
1.擅用define。请把“裸露”的常量,用短小又信息准确的宏定义起来,务必全大写。常量的宏定义要大写,我会在后期关于代码规范的主题**分析。请把设备驱动的io,用define定义分离出来。当然,还有许多妙用,宏定义简直是移植旅行必备佳品。待我后期再整理下思路吧。
2.抽像出平台依赖严重的代码。比如访问一个特定mcu寄存器,开关中断,清狗指令,中断写法等等。
3.如果可以,我希望你的.c档中包含的.h档尽可能的少。这样在移植的时候,你只要看包含了那些.h档,你就知道该模块大概依赖了其他哪些模块。我知道,大多数的程序员都喜欢在.c档的文件头仅有一个
#include "includes.h"
而在includes.h 中包罗万象,这是原罪!当然,要一个萝卜一个坑地梳理清楚.c与.h档的关系,需要长期的工作经验,尤其在编译条件错综复杂时,操作起来的确痛苦且容易出错,但其实这已经预示了你系统架构的某种不合理。
如果没有足够的经验,那么我建议你,先在设备层的.c档尽量包含尽可能少的.h档。然后把设备层的.h档放在includes.h中,给应用层使用。
3. 打造自定义库,这个准备设专题讲解。
4. 通信数据统一是大端的,内部应用代码统一用数值说话,和大小端无关,不要乱糟糟的一片胡写蛮缠。少用union,发送数据时统一用单字节移位发出去,接收时用移位收进来。牺牲了效率,但提高了可移植性。在51中也许不大现实,但在未来M3的大趋势下,效率是可以牺牲的。
5.欲知后事如何,请听下回分解.... |