在开始正题以前.......先让我们小小水一把。
我们知道你可能遇到了一个会让你崩溃的问题，但是，当你突然冒出来大叫道：大神（也有人不分性别乱叫大婶来着~）啊，救命啊，我的万年历没法调时间——
说真的，这种时候我们也崩溃了：
我鬼知道你是12864显示有问题呢？还是你的按键反应太迟钝，或者是你的时间调整子函数写错了呢？
然后这个时候你很兴奋得贴出来一大段代码，这个时候基本上没崩溃的也崩溃了.......
我们知道你可能会以为，这个棘手的问题，我们只要花点时间就能手到擒来（说真的，我有时觉得挺自豪，为什么在别人眼里我这么牛叉）。相信我，我们真的知道，因为我们也有过那样的日子，迷信所谓的高手。
有时候，如果我们闲的无聊，费点劲，帮你搞定应该没问题，我只是在想难道你就不怕，哪天我们不在线，或者，哪天我们都在加班的时候，你该怎么办？
提问题的艺术，真的是一门艺术，这门艺术几乎不比 软件这门艺术 要简单。
在技术论坛里，qq群里混迹有些年月了，这种突然冒出来的小盆友非常多，最近就有两个，恰好遇上偶在手忙脚乱的收拾行李准备搬家，于是，我突然觉得这些“浑小子”真的很可恶。
然后想起来，好吧，我试着写这样一个帖子吧。
他和你知道的那个大名鼎鼎的 提问题的艺术 几乎无关。
嗯，我只能说这么多。
提问题以前先知道自己都干了什么
就拿那个 万年历不能调时间 为例子。
这不是个比喻，是个真事。
当那个家伙说出那个问题时，我的第一反应的确就是哪三个可能。
于是我问他，你的程序怎么写的？
——这个问题一般来说都会是一个 杀手锏——因为一旦我问出这个问题，基本上一般求教的人不是跑了就是开始恼火的说我只是想知道为什么不能调时间.......
他大爷的，我还想知道他怎么冒出来的呢。
这些小盆友当中其实也不乏很努力学习的好孩子，并不是每个人都随随便便在网上搞来一段代码然后就想都不想直接烧进片子里，然后就跑过来问问题的。
而那样的程序，一般又是写的极其混乱，模块化之类的话题就免谈了，最该死的是，到处出现的while啦，随随便便就是用 软件延时了........
这样的程序，能调出来用，那一定要去买六合彩。
回到正题，提问题，首先要搞清楚，自己到底做了什么事情。
这是提问题的起点。
针对上述这个例子而言，如果你就是随便搞来的一个例程——这也很正常，通过例程入手，这也是我的惯用路数，但是前提是我一定会先搞清楚这个例程都干了什么，至于怎么干的还可以押后再说。
我理解例程的方法是重构源码——当然，这需要一定的经验，时间 和 足够的C语言基础。
假设你没有，不要紧，但是，请你一定要中文写清楚，到底这个程序做了什么事情。
这不是写给我看的，是写给你自己看的。
有了它，你才能知道具体做了什么——连做了什么都不知道，你就更别指望去搞清楚到底是怎么做的。
是的，知道自己都干了些什么，是提问题的起点。
知道了自己干了什么以后，要提出值得怀疑之处
这里有一个前提，你要学习相关软硬件驱动的基本知识。
别被这句话吓着。
比方说，你要做一个四位数码管显示，那么，你至少要知道以下几点：
1.多位数码管显示，除了你IO口多的没地方用以外，一般都是用动态扫描。
啊？什么叫动态扫描？百度去，如果你这个时候问出这个问题，最好的结果也是被无视——有人觉得这是做技术的臭毛病。
也许算是吧，就当我们没有为你着想，我们为自己着想，花时间去解释教科书都已经有的内容，我们真心会觉得那是一种作孽，浪费时间。
2.动态扫描下，相当于PWM方式点亮LED，这个时候亮度取决于点亮和熄灭的时间比（也就是占空比），类似的，假如你的扫描周期太长，引起闪烁是必须的；
好了，如果你懂得了这些，最后你还要知道，所谓的 扫描，所谓的驱动，其实在单片机而言，是什么动作？
好吧这个问题我直接告诉你答案，其实就是,,,,io口写零写一。
那么接下来，回到你所写明白的 例程都干了什么，然后根据你看到的不对劲，提出你的怀疑。
是不是IO口扫描太慢，所以闪烁了？
是不是占空比太低了，所以亮度很低？
.......诸如此类。
如果这时候你再来问我们，我们就会教你怎么测试，去消除你的怀疑。
京公网安备 11010802033920号
