[分享]高可靠性嵌入式系统固件设计策略阅读手记

不会游泳的鱼

早上阅有点闲暇，阅电子工程专辑的《高可靠性嵌入式系统固件设计策略》，觉得此文写的不错，记下阅读手记，备以后参考。
文：为原文内容节摘，有删选修改
鱼：个人记录

[鱼]固件设计领域对成本和开发时间的追求造成了固件编程存在很多不同于ＰＣ机主体下编程的限制。如有效利用有限ｃｏｄｅ空间，有效利用紧缺ＲＡＭ空间，如何在系统负载达到75%以上的时候还要维持实时事件响应等。所以此文从固件设计角度有些很有借鉴性的提议，可能并不适合PC平台的编程。但是PC平台的软件工程的书已经多如牛毛，而从硬件固件编程的文章可是不多，呵呵。

不会游泳的鱼

[文]一非正式调查，７０％固件编写者都持有电子工程学位，有助于理解复杂硬件同时存在软件构造上的先天不足。
[鱼]电子工程师和固件编写者普遍缺少软件工程基础，导致了大量的重复工作和低效劳动，占用大量的开发时间和资源，造成硬件设计领域整体的设计水平偏低和开发效率偏低。

不会游泳的鱼

论函数设计：
[文]也许如今最广为人知的却最少被采用的软件设计准则就是"保持函数短小精悍"。笔者讲座中进行了调查，问谁编程时候限制了函数长度，几乎无人举手。××× 笔者认为，如果函数超过50行即一页，就已经太长了。。。理解一个跨页的一个个的嵌套流程是非常困难的。
[鱼]以经验来看，50行指令已经可以完成固件中相当复杂的功能了。此文说法相当可行。看来虽然偶一页打印是110行，但是偶以后也要注意下长度问题了。呵呵！剥离成小函数有时候也很讨厌，就是有时候会遇到堆栈深度问题，有些固件硬件上限制了堆栈深度为8级，为中断和中断中的函数及高级中断留三级，空一级防止意外溢出，就只有四级可以供主程序用了。[撇嘴]这种情况就不适合用本例了！[汗]

不会游泳的鱼

[文]经验告诉我们，当你很难找到一个能够清楚表达函数意义的名字的时候，说明这个函数的功能已经太多了！

[鱼]呵呵，一个函数还是一个功能的好。。。


[文]我见过太多的这样的函数，它们利用多达50个参数来选择成打的交互模式，这样的函数几乎是不可能可靠工作的！

[鱼][汗]忽然想起刚开始搞设计的那段时间里，曾经为设计出一个有三个入口，四个出口，需要六个参数配置的复杂宏而洋洋得意！那个宏很好用，在数个不同位置都可以调用！。。。。。。就是就是每次我重新看那段代码时候，总是要汗上半个钟头，努力回想但是写程序的思路！！！[汗][汗][汗]
现在看，那个傻劲。。。。。。[奸笑][奸笑][奸笑]

不会游泳的鱼

[文]提倡OOP的人一直在倡导"封装、继承和多态"，尽管OOP不适用于所有应用，封装却可以说放四海而皆准。。。。
封装的意义在于将数据以及对其进行操作的代码捆绑进一个实体，就意味着其他代码都不能直接访问这些数据。

[鱼]想起以前同屋一到晚上睡觉时间就和我大谈OOP的时光，呵呵，这是我的催眠专用曲。[奸笑]
对于封装，对固件编程上的意义我认为相当大（PC编程这个已经成为一个标准了，就不比较了）。在有限固件资源的情况下，每一个byte的ram都是宝贵的，没有封装的时候，总是在手动分配空间，还老是要惦记着这块不能用，那块不好动，真一个资源都是全局的！汗！真是在充满控制的困意中能睡去。一句话，固件编程能不用汇编就不要用汇编，要用汇编的话就要参考C的空间分配和映射以及释放方式。

[文]如果你的设计对ROM限制非常严格，每个字节都要斟酌，那这种应用基本无法封装，但我们必需承认，这种应用的开发成本很可能高的惊人。
[鱼]说起成本，其实人工成本只是一小部分，最大的成本实际上是上市时间风险成本。所以当我们只准备用把小刀砍树的时候，就需要要平衡下这个收益比了。[大兵]

不会游泳的鱼

[文]封装的目标是可以重入的，高内聚性和低偶合性的。。。我们曾经读过这样的代码，一些看来简单的操作却和成打的模块纠缠不清，维护人员不得在成千上万条代码中跟踪变量和功能，而这肯定会把它他们逼疯。。。[大兵](早就疯了好多个了。。。[汗])


[鱼]青菜萝卜，拿来就吃。。。绝对无公害，保证无虫虫，拉肚包索赔。（卖的好贵的。。。）[吐舌]

不会游泳的鱼

谈及消除冗余

[文]研究发现，包含那些不会造成程序缺陷的无害冗余的代码发现硬错误的可能性也比不含的高出50％。原因，哈哈，冗余代码的出现说明当时设计人员思路不清！！！

[鱼]这个论据很新颖呀！[奸笑]不过有点道理，文中写了4种冗余代码的定义，让偶对冗余代码有了准确的概念认识。看来以后编译的警告信息都要处理了。。。[吐舌]

不会游泳的鱼

减少实时代码

[文]实时代码不但容易出错、编写成本高，而且调试成本可能更加高！！！如果整个程序处处都渗透着时间问题，那会令每个字都变得难以调试！

[鱼]曾经看过一个家伙的一个有近千行的键盘中断处理程序，什么都在里面做了！甚至还有等待，汗！！！不知道那个程序怎么跑起来的，中断累加问题如何处理。呵呵！那是高人。一只觉得若中断处理时间占到了最小时间片50％以上，都是危险的，非实时数据，最好还是设个标志位，到主程序中唤醒一个模块去处理吧。

不会游泳的鱼

[文]请大家记住以下几个在安排开发时间表上的经验：一个系统负荷达到90%的系统开发时间是负荷为70％系统的两倍。系统负荷增加到95％时候，开发时间将增大到三倍！实时系统开发成本是十分昂贵的，高负荷的实时项目更是如此。

[鱼]极是，在系统开发时，系统负荷在70％以下的系统是比较稳定可靠和易开发的！不能老是打咏春嘛。开发初期就应该定下这个指标，不然走到后面死火了就冤大了。。。[汗]

不会游泳的鱼

[文]重构，即重新编写劣质代码的重要性。
理顺并维护编写恶劣的代码模块比维护一段简单漂亮的代码模块要昂贵的多。
狂热的重构追求者要求重新编写所有可以改善的代码也是没有必要的。我们的工作是要用一种可以盈利的方式创造能够成功的产品。所以追求完美的目标不应该凌驾于其他考虑之上。
但是，作为专业人员，应该可以判断是否代码需要重构。
热力学第二定理中闭合系统中无序发展和嫡的关系同样适用于软件重构。每次维护而不重构增加了系统的嫡的同时提高了维护代价。
[鱼]又是一个开发和维护成本的问题。

不会游泳的鱼

[文]遵循代码编写标准并借助检查工具，检查工具寻找缺陷比人工调试大约便宜20倍。

[鱼]这个在PC平台的编程中被广泛提及，标准化推广的非常好。但在固件平台编程上好像还是蛮荒时代，基本的规则很多还得自己定义和摸索。唯一能够借鉴的就是C的风格的应用了。从版本管理到小的文件命名到缩进格式，这些小小的细节可能让不少非科班软件出生的电子工程师们吃过无数的暗亏。[汗]

不会游泳的鱼

[鱼]同时文章提及了固件的调试方法时指出了现在调试方法的落后性。的确，经验上看，所知道的调试工具里面大多数就只是涉及到寄存器级检查调试。很多调试需要自己写探针程序调试。可能是我没有接触过高级的调试仿真工具吧，但偶觉得更加大的可能是因为固件仿真调试工具和硬件相关性太强，不是一个广泛标准的平台，限制它的深入发展！在执行速度越来越快，频率越来越高的今天，若发现一个随机错误你要解决它，那真的是一件惨事呀！

该帖由: 不会游泳的鱼修改，时间 2004-3-15 下午1:30

不会游泳的鱼

[后记][微笑]算来也有一段时间不用动手写代码了。
但当年做程序时的种种趣事都还记忆尤新。呵呵。

BOSS

鱼写嵌入系统是16位的么，当年弄八位机的时候只知道有汇编，没有什么函数。一个程序有2千多行，编译后在烧结进去。
在学校时更离谱，2百多行程序对着编码表翻译成16进制代码敲进去。哈哈

不会游泳的鱼

最初由BOSS发表
鱼写嵌入系统是16位的么，当年弄八位机的时候只知道有汇编，没有什么函数。一个程序有2千多行，编译后在烧结进去。
在学校时更离谱，2百多行程序对着编码表翻译成16进制代码敲进去。哈哈

八位的居多[奸笑]，现在工作上已经不搞了，平时是自己的爱好玩玩。。。[吐舌]