本帖最后由 sedatefire 于 2012-6-10 10:02 编辑
/***********************************************************************************
* Filename: 一线研发之声：嵌入式C编程经验 之 你库了吗
* Author：SedateFire
* E-mail:SedateFire@126.com
* Version：1.001
* Create Date: 2012-06-09
* Modify Date: 2012-06-10
* key: 库 优点 缺点 设计规范
* 本文首发： 21IC论坛--新手园地版块
***********************************************************************************/
库，这可是大杀器!!!
一个的设备程序如果完美库化，它意味着
1.所有工程师在移植或创建该设备驱动时，花费的代价超小。
2.随着使用者的增多，它饱经考验，不断趋于稳定，变为当之无愧的公共代码。
3.库对外的接口(函数名及其参数声明)是不变的，当所有常用设备都实现库化时，它带来另外一个好处，应用层的移植、创建、修改维护的时间耗费也会剧烈减少。应用层的跨平台无缝移植不是传说，当它所依赖的所有外围设备通通在不同平台库化的时候，应用层的实现，就像在写java代码一样。
4.库意味这公司核心代码的安全，库代码只掌握在核心工程师手里，应用层的程序即使丢失也是无碍。
5.新人对于这些基于库案子更快上手，一来有库帮助文档的说明，二来不必也无法关心底层细节，专注于应用开发。
6.提供给客户二次开发，你可以把硬件和外设驱动的库交给客户，让其二次开发。
7.通信协议的库化，将使通信系统类的产品更加安全，至少不会被离职的工程师破坏，比如RFID的扣款充值。
8. ......
怎么样，它使老板心动，工程师百味杂陈。
当然，有些工程师会想到，库可以使他脱离繁琐的底层驱动工作，进行更高层次的工作。
库的创建要想搞得好，有以下几个条件
1.提供给客户的只有.h档和.lib档
2.所有.h档中没有define，编译条件对于.lib档来说只是一个笑话。
3.所有.h档中没有extern变量，如果有，这意味着系统只能创建一个这种设备。比如蜂鸣器驱动，如果extern变量，就意味着整个系统只允许一个蜂鸣器。
4.完善而详细的使用帮助文档。可参考keil的hlp文档格式。
5.简单的使用该.h档的demo程序让人参考。
6.“动态链接”库代码，简言之，没用到的接口函数代码不会被链接器搞到最终的二进制档中。
7.还有一点，尽量的平台无关性，它不依赖于任何寄存器或者其他和平台相关的东西。
要达到上述的目的，通常会使库有如下特点。
1.结构体指针
2.大量的回调函数指针。
3.丰富的接口。
4.库源码的.c档将按接口函数拆分成更多的.c档，这为了实现链接时代码空间最小化。
库的缺点也是有的
1.它会使设备速度变慢一些，多了几层间接取址的消耗。但对于32位机，对于它带来的便利，还是可接受的。
2.它会使code空间消耗相对更大一些，但请相信我，对于一整个中大型系统而言，它会使代码量不升反降，因为大系统中有非常多的重复冗余代码。这方面我个人的经验，降的不是一般的多，简直到了一个难以置信的程度。
早期的8位机，51平台上其实不能很好地实现完美的库，至少是不能实现一个跨机型的底层设备驱动库。近年来随着32位机的兴起，库渐渐地受到越来越多工程师的青睐。这里面最本质的原因在于，51架构的栈是静态编译的，局部变量和传参的栈也是静态的，函数无法重入。而多数的32位机都是压栈传参的方式。当然，51速度慢也是重要的原因之一。
如果有熟悉面向对象语言或者linux驱动的朋友，你大概就明白一个好的库是什么样子的了。库就像似面向对象中的类，至于linux底层驱动的代码，那就是函数指针和结构体指针的世界。C的精华在指针，在里面得到完美的诠释。
说了这么多，突然感到一阵的苦恼，我的幽默呢，我的浅显易懂式文风呢，还是说这个主题难以驾驭。但也觉得可喜可贺啊，我想要在新书中讲明这个专题，得耗费很多笔墨呢。需要逐渐式的详实的代码实例讲解啊。一来高兴书的页数无忧，二来担忧不小心违反了公司的知识产权。矛盾啊
|
楼主
标题置顶
标题高亮
