刘程

楼主写的是精华啊，我电气出身都开始偏软了，纠结啊，现在搞软件上不去，搞硬件下不来、、、

hb1012

支持楼主学到东西了！条件编译+自注释

忘川

楼主很认真，也很有心，前途一定一片光明。

wranmaoyi

楼主是测控专业的吗？

辛昕

我大学时学的是 机械设计制造及其自动化

但机械方面的 我几乎等于没学。

辛昕

因为有计划去厦门旅游，请了两天的假，明天再上一天的班，就可以连着出外游玩三四天的样子。
这两天也不知怎么回事，工作整理程序有点心不在焉，总是觉得困和累。

晚上买了些零食和收拾了行李，也没做什么事。
除了和虚V界聊了一下他在玩的modbus和更长远的 飞行器 的玩意以外。

就是 整理了一下自己的思路。

如这个帖子所写的内容所表达的那样。
现阶段，我满脑子想的事情，都是 关于如何组织，展开一个完整的 项目程序。

应该说这个帖子写过的内容，大多数都是从最末端的 变量 函数 开始 写的。

从这点上，我倒是觉得，在这个帖子的组织思路上，我是 从下往上 的思维。
我从最末端的变量 和 函数 的角度，从 如何更好管理好它们，尽可能做到 方便管理，容易维护，更加清晰易懂 等方面出发，反过来，讨论 最初 宏观的 那些工作步骤 的意义 ，和 需要如何做（等同于给这些步骤指明了工作的原则和目的。）

并且不断地强调一个核心
功能至上，任何事情都是为功能服务。

包括 最后会提到的最开始的工作步骤：系统规划，实际上，规划也是 以功能为纲，没有它，我们规划啥都不知道。
而往后的步骤里，包括概要设计，和具体细化设计——通过 分模块，分各个具体的功能块，这里，我将会试图用一个功能框架图 来描述它，这是一个动态的，生长的不断往下嵌套的功能框架图。

它的生长本身也就是 从 系统规划 一步一步 往 概要设计，，具体细化设计 这些功能 的 进行过程。


事实上，尽管我非常强调 这个工作过程的不可或缺，但是，我从来没觉得必须按照一套多么完整的流程去进行。
比如循规蹈矩的，从 调查立项，到 系统规划，到概要设计，细化设计，分模块，具体实现，等步骤一步一步往下做。

它们有的可以简化，有的可以删除，甚至，步骤本身可以打算。

著名的数学家polya在他的一本书里，总结过 解决问题的几个基本步骤，但包括他本人都强调，事实上，这些步骤并不总是，而且是不可能一步一步往下走的，经常要往返进行——
往返设计，并在这个过程中，不断深入了解系统和任务本身，从而也在不断的往返中，找到更优的解决方案，这是一个优秀的设计所应具备的特征。

简单地说，关键是要管用，而不在于这套规范和流程本身有多么完整和规范。
所以，对我来说，关键是分清，在一个完整的项目进行过程中，到底哪些步骤是迫切需要的工作，为什么呢？

已经做过的项目，并且规模比较大，而且不宜讨论。
所以，我一直在打算，拿我现在自己在做的一个 stm8s项目作为一个具体例子来分析。

呵呵，睡了。
抛出问题，让各位久等了。

blue_bm

楼主很认真 看了很受用! 我是51初学者 刚刚入门 对于这些c语言方面的知识非常感兴趣 希望楼主多多提供这样的文章 谢谢

kxz

中国人的聪明才智令人震惊:

wateras1

呵呵，LZ说的很好，我一直觉得写驱动也应该按着软件工程的思想来弄，最好能自己试着去写份小型的固件库，用起来就轻松多了。

lothacking

lz果然是个高手，

melon_1

偶像

dreamerzhai

看着看着...还是有收获的

linuxer2011

楼主，说的确实是经验之谈，其实很多人在实践过程中会有许多心得体会，只是大多数人没人没有及时以文字的方式总结出来而已！

辛昕

嗯，但个人觉得总结是很重要的，只有总结了才会系统起来。

合工大测控

同问

辛昕

你好，我本科是 机械设计制造及其自动化 专业，有学习过相关基础课程。

但是我对 这一块很是陌生，更多精力和能力都在 编程 方面。

辛昕

具体的源码 和 完整的项目文件 在下面这个链接里。
https://bbs.eeworld.com.cn/thread-333201-1-1.html

目前更新到8.2号的释出版本，完整包含 gpio+timer+数码管显示，只能算是做好了一个基本的程序架子（具体下文会说）。

在这个贴子里，我将以它为例子（当然，总结时，我发现有些部分我还没做进去，比如 测试模块。）
说明，现在的我，会如何组织一个 项目工程 的 开发过程。

辛昕

我们反复强调，功能至上。
那么，对于一个 典型的 MCU项目，我们最先要考虑的事情，事实上，绝对不是什么什么 测试体系。

从最务实的角度出发，我们首先要考虑的是，这样一个赤裸裸（裸机）的东西，如果我们不首先构建点什么，那我们见到的将只是一个 黑乎乎 的芯片或者一个乱七八糟的开发板，除此以外，我们别无所得。

所以，对于一个典型的MCU项目，首要的第一步是， 构建一个最基本的平台——或者说，最小系统。

这个最小系统 和 一般意义上的 最小系统稍微有点点增加：
一般说的 最小系统 说的是 能让 芯片正常工作 的 最小外围电路构成。也就是说，这种意义上的最小系统，往往就是 外部供电电源电路，加上 外部晶振电路——甚至不需要，现在大多数 芯片内部有振荡源，然后，它就能正常运转了。

这就是 最小系统。
但这样的最小系统对我们是没意义的。
你说它正常运行了，谁能证明？
振荡脚上的电位差？还有什么？

事实上，我们最需要的是 确切可见可触 的 效果现象。所以，我们说的 最小系统 指的是，至少包含LED 的 外围线路。

不知道你们的习惯如何，一个新的MCU拿到手，我一般首要考虑的就是，先把gpio/IO的 读写 验证完，其次再一点一点往下走，增加 定时器 这个基本的应用，然后，我就可以认为自己已经能够用上 这个芯片了。

简而言之，一个典型MCU项目首先需要的功能，就是通过最简单，最直接的gpio向世界证实了它的确是可操作的。
（然后是定时器，还要是定时器中断，因为这个东西太重要了，程序的组织，分时处理的最简单实现，都离不开它。）

辛昕

从现在起，明确一个观点（尽管这个stm8s，不好意思，我也没这样做，但我会马上补充进去）
任何时候，在构建相应功能和编写相应模块，函数之际，就要考虑其测试用例。

测试用例是用来干嘛的呢？

从字面意思来看，它是用来 证明 我们的程序 没有什么问题，并且的确实现了我们预期的功能 的辅助部分。

但实际上，按照《软件测试的艺术》 这本书的观点，我认为以下这种说法 更有可取之处：
因为软件从来就不存在“完美的，正确的”，它总是或多或少有问题——就像一个追求完美成癖的人来说，也是从客观实际来说，这个世界上没有隐患，没有bug的程序时根本不存在，这不是苛刻，实际上它是一种宽容：所以，我们也没强求你提供一个这样的”完美“程序啊。

所以，我们要实现的更实际的目标应该是：
1.尽可能找出并以妥当的方式处理，消除程序存在的问题和隐患；
2.证明你的程序只是做了”要做的事“，而没有做”你不要做的事“——简而言之，这个世界上最错误的一个观点之一就是 ”做了没用的事，又有什么害呢？“

不过，上面说的这些，也许更多的是用于 发现 和 调试 程序中的bug——我的意思，是 程序编写中的具体逻辑，实现方式时遇到的问题，这个问题，我们暂时还谈不到——正如我的stm8s项目，目前也没具体做到那个位置。

这个阶段——我现在等同于 实现了 我上一个帖子所描述的 那个 面对一个MCU项目，首要要实现的功能（它们基本是硬件层次的）。
这个阶段我们需要测试吗？如果需要，那我们要测试什么？我们要怎么测试？

当我写下这个问题时也一时愣住了，但我马上就找到了答案，答案其实很简单：
你实现了什么功能，你就要为什么功能 添加 测试用例，以证实你的实现的确管用，并且没有引入什么错误。

在这方面，我想说一下，这种底层非常简单的功能实现方面的测试用例的构筑基本原则：

第一，首先我们要分析一下，我们所构筑的底层功能里，都有什么依赖关系——
简单地说，我们用LED亮灭，本身就是为了证实gpio的确可以为我们所操作——而这也经常被用来证实一个自己焊接的最小系统板，的确在正常运行；
所以，在我们实现底层的简单功能时，实际上也存在彼此 依赖关系，比如你要通过LED的闪烁频率去证实你定时长度的设置有效，那么，实际上，你还需要首先证明gpio工作正常。

所以，现在我们分析的结果是，gpio是最基本也是最首要测试并且保证的功能。

这个实际上非常简单，电路上，只要焊接一个LED即可，最简单的实现方法，是LED接IO口，外部上拉一个电阻到电源。

实际上，除了LED，我们还可以用其他方式证实，比如说，假如我们的系统中规划要使用到数码管，那么，我们也可以通过数码管证实gpio的工作状况。

但这正是我们接下来要说明的 原则之一：
用 最直接，最简单的独立，不依赖其他实现的方式去证实你要证实的东西。
比如说gpio是否如你所愿写高写低，请为我提供一个比起外接LED还要更直接的方式？
我相信你找不到，除非你喜欢用表笔去测量。

而它也不需要依赖任何其他，它仅仅只是通过相应的IO寄存器写操作。

但如果是数码管就不同了，这里涉及译码，以及动态显示或者静态显示的其他细节——如果你用它去证实gpio，那就太累了，因为你要首先保证这套数码管驱动程序本身的确可行的。

xkc6659

MARK，，好帖，好好学习