|
N年前，匠人曾经在“侃单片机”论坛里发起过一次关于软件抗干扰的讨论。其实，当时的讨论基本上已经达到了软件所能做的一切范畴。但是随后，讨论的方向逐渐转向了“软件抗干扰是否有实际意义”上去了。虽然匠人坚持认为软件在抗干扰方面可以有所作为。但是，来自反面的意见，也让匠人深思了许久。
世纪轮回。这次，由emailli网友发起的“建议做为2008年1月的专题----软件抗干扰的方法研究 ”，又把当年的讨论场景再现。别具意味的是，对软件抗干扰本身的置疑也被再次提出。
从某种意义上来说，随着单片机硬件抗干扰性能的越来越完善。软件在此方面的用武之地，似乎确实在萎缩。试问又有几个单片机程序中应用到了软件陷阱呢？比例恐怕很小吧。
然而，匠人最近有事没事，经常喜欢在同事面前卖弄这个词——“鲁棒性”。
鲁棒性
robust
[rEJ5bQst]
adj.
强壮的；健壮的
His robust strength was a counterpoise to the disease.
他身体强壮抵住了这疾病。
粗野的，不文雅的（玩笑）
鲁棒是Robust的音译，也就是健壮和强壮的意思。
鲁棒性（robustness）就是系统的健壮性。它是在异常和危险情况下系统生存的关键。比如说，计算机软件在输入错误、磁盘故障、网络过载或有意攻击情况下，能否不死机、不崩溃，就是该软件的鲁棒性。所谓“鲁棒性”，是指控制系统在一定（结构，大小）的参数摄动下，维持某些性能的特性。根据对性能的不同定义，可分为稳定鲁棒性和性能鲁棒性。以闭环系统的鲁棒性作为目标设计得到的固定控制器称为鲁棒控制器。
什么叫“鲁棒性”呢？按匠人的理解，就是，你的程序是否把所有的因素（包括异常因素）都考虑进去了，并且对可能的异常因素采取的规避、补救措施。比如：
1、我们要让一个变量做递增运算，每次+1，达到某一个阀值时清零。那么你在做阀值判断时，是判“等于”，还是判“大于等于”？（正确答案：判“大于等于”）
2、我们要根据一个变量去查表，或散转，假设这个变量正常范围=0~7。那么你有没有考虑过，如果该值大于7后，程序该怎么办？ （答案：先屏蔽（剔除）无效值，再去查表，或散转）
3、我们要让某个IO口输出“高电平”去驱动外部电路（比如说，继电器）。那么你是否只输出一次“1”就认为完事了？（答案：开辟输出缓存，定期刷新输出口）
4、串口接收数据，假设收到“0X00”时执行动作A，收到“0X01”时执行动作B。那么，你有没有考虑过，如果收到的是其他数据，该怎么办？（答案：参考第2例）
这样的例子不胜枚举，每一个细节中都存在陷阱。如果在程序设计中予以考虑，则可以规避；否则，很难说你的程序运行过程中会发生什么事情。
因此，一个好的程序，定义应该如此：“在正常情况下，可以得到正常的结果；在异常情况下，可以得到意料中的结果。”
而不是：“在正常情况下，可以得到正常的结果；在异常情况下，得到不可意料的结果。”
匠人的一些同事（新手）往往会跟匠人来犯犟。强调曰：“我的程序没有BUG啊，是输入不正常导致的。”，云云。确实，这些细节上的疏忽，不能称为BUG。我们只能称之为“鲁棒性”差！
再扩展开来看，在整个系统中，不光是软件需要考虑“鲁棒性”，硬件也同样需要考虑。
举个例子：假设系统工作电压为5V，那么当电压低于5V时，会发生什么事情？考虑过吗？OK，你说你有复位电路，电压跌落时会复位。那么匠人再问：电压快速跌落时可以复位，但如果电压缓慢下降，你的复位电路还能正常工作吗？或者，电压波动时，又会如何？
这样的细节还有很多，贯穿在整个设计过程中。对于有准备的人来说，只要事先预想到了并采取规避措施，都不是问题。对于没有准备的人来说，调试将是一场艰苦的跋涉。因为前进的道路上，“坑”太多了，指不定在哪里跌倒。
以上，为匠人信口开河。欢迎探讨。 | 
《匠人手记》推荐网上购书渠道： 
社区动态：《匠人手记》义拍活动，得款直接捐献灾区
