地址：https://www.eefocus.com/luo_xinli/blog/15-09/319270_5342c.html
很早在一本介绍编程入门的书上介绍了一公式：程序=数据+函数。看了也就看了，我并没有太多的关注这个问题。因为当时刚刚开始学习入门，周围的还没有高手来指教。问题也就过去了很多年。我很诧异我的那几年是怎么过来的。现在想起来，得益于单片机的flash比较小，程序的逻辑也很简单，在一片不大水泽中，如果水不太深、淤泥不太多。多栽几个跟头是能走到对岸的。 不过出来混，早晚是要还的。让我不得不再次面对这个公式的事情发生了。朋友要设计一个变压器工作温度、环境湿度、输入输出功率检测保护装置。这个项目是我和另外一个工程师合作的，我们根据项目的功能要求进行程序模块的划分、功能的描述。已经基本实现的方法。为了能快速的进行后期工作，同时确定了配置参数、测量参数（模拟量、数字量）等。为了简化程序的设计我们采用101报文规格。 在开始工作后，我发现了一个问题，101规范的报文是以连续的地址来管理配置参数和运行参数的。这个和以前自定义的报文形式有根本的区别。报文中没有区别的关键字。以前我使用程序架构弱点太明显，就是各个功能函数间关联性太强。如果需要更改一个功能，有可能涉及另外的功能。应用层与硬件层划分不是很清楚，事情变得特别麻烦。 你遇到的问题，往往不是你第一个人遇到的问题，前辈往往已经无数次经历过，并且有了很好的验证方法。很快有人帮我解决了这个问题，李同事告诉我“将变量类型统一化处理，内部地址与协议说明文件中对齐，可一劳永易的解决问题，先处理与硬件相关的函数，并且归一化处理，将对硬件的操作，变为对变量处理。参照一下含有总线的其他芯片的说明书，将你单片机面向用户设计成一个标准芯片”。 我当时到没有完全理解李同事的至理明言。但是有一点是肯定的。将所有变量数据类型统一化处理，并且将地址与协议说明文件对齐后。通讯协议就变得非常简单，我使用了几行代码完成通讯模块。想到以前在这里我要花费大量的代码，一切变得十分美好起来。 在以后时间里，我依旧使用这种程序的框架，我也确实对“程序=数据+函数”有了一点点体会。在处理完硬件层以后，编写程序完全成了逻辑处理问题。处理输入的依据是数据，输出的依据任然是数据。系统的扩展性、维护性都可以提高很多。 书本的有些东西描述非常简单，但是有心得以后又是那么不简单，而且非常不容易做得完美。
| 
/3 
发表于 2015-9-24 19:21:45
沉默卡
照妖镜
