yaoyong

辛哥，我今天想了很久，你看我这样理解行不：
既然显示程序和扫描程序在主程序的While(1)中，那么如果是
按照我的写法，

1. while(1)
   
2. {
   
3.        DigitalDisplay();
   
4.        KeyBoardScan();
   
5. }

复制代码

那么，如果程序停在扫描函数中，由于显示程序在前面，所以相当于
一直扫描，只是后面的扫描占用时间长，前面的短，以至于前面的看不到了；
那么把他们的顺序换一下呢？会不会由于键盘扫描在上而已至于不进入
显示程序这样就不显示数了呢？结果还是一样的，就是因为这while(1)了
它相当于在下面写了无数次里面的子程序，反正就在他们之间折腾来折腾
去所以结果一样。

辛昕

实际上，线程这个概念，我觉得，并不一定要有那么高级的实现才能叫线程，它只是一个概念。
就好比，不是说高级西餐馆的牛扒才好吃，其实，自己买来做的也可能很好吃。

辛昕

好吧，楼主我这回好好看了你的程序，首先，我一直误解了你的实现方法，想当然了。

你这种显示扫描函数，不管程序怎么卡住，显示都不会消失，只不过会停在卡死之前最后一次显示到的数字

辛昕

不对，我说错了，还是会的。
等我再看看你的测试，初步断定是，逻辑上有问题，实际上没卡死。

有个建议，先不说你死循环的方式不好，你这个程序写的太乱了，该子程序的地方不子程序，导致一堆重复，还冗余，像那两个switch，，，
本来没多复杂的逻辑，非得我一条一条看，，，

辛昕

先不看仿真那个，又涉及其他硬件，可能有其他逻辑错误，不谈了，测试的第一原则是单一，不要依赖太多其他其他逻辑，混淆实际要测试的东西，我只说你的按键部分。

这个测试结果恰好验证了我刚才的想法，
你的显示实际上没卡住，只是显示了最新结果，我不知道你的原始意图是不是这样，在我看来它可能正好是你最初的设想。
你的想法很有道理，你用死循环等待松手，按着不放会导致卡，按道理会出现无显示，显然不是。

你的主循环已经足够单纯，所以，第一怀疑的地方是，实际上你的死循环没有卡住。

这就是要分析的地方

辛昕

我又看了一遍扫描按键部分，确实，是不会卡死的。
这点运气成了你的噩梦，说噩梦因为你纠结了很久。
说运气，你真的运气，明明写错了程序，却没卡死。

这个读键扫描的检测松手的地方是错误的。
单按键没问题，那是因为你只考虑了单按键写的那个while条件，多按键时就错了。
另外，这个判断过程写的太混乱了，
调试它想必非常痛苦，我建议你重新全面考虑再重新设计一个新的扫描函数，再来对比也许更容易看出问题。

辛昕

我知道你的按键是用 p3口连的，低四位写扫描，高四位读状态。
从你设计的三个按键测试动作看得出你考虑问题还算比较全面，考虑到了单键，多键，还考虑到了多键的不同操作组合，非常好！很棒的测试意识！
现在你不要急着测试程序，现在纸上画好这八条线，然后按照你的那三个测试方法，考虑在那样的情况下，你条件里那个temp的分别什么值。
考虑时要完整考虑四条扫描线都写过一条为零的情况哦，，

辛昕

总是不小心话就说多了，又看了看程序，关于单键多键的说法忘了。我说的是不对的，看程序不够认真。

我看了看，你这个程序在什么都一条扫描线上四个按键没按时，应该就是卡死的。

我没打算帮你自己排查一遍判断逻辑，但显然是有问题的逻辑，你再好好理一下吧，按我上一条回复的建议。

yaoyong

首先谢谢辛哥的耐心和认真，真么晚了还抽时间看我的程序

yaoyong

关于矩阵键盘的扫描程序大部分都是用的这种，如果重新写
那也可能是换汤不换药，因为我对这个程序就知道这一种算
法。
至于简化，可能就是把对每行判断的那几条语句作为子函数，
分别调用咯，我个人觉得这也没什么高明的地方。呵呵

yaoyong

原帖由 辛昕 于 2013-4-2 23:39 发表
总是不小心话就说多了，又看了看程序，关于单键多键的说法忘了。我说的是不对的，看程序不够认真。

我看了看，你这个程序在什么都一条扫描线上四个按键没按时，应该就是卡死的。

我没打算帮你自己排查一遍判断 ...

这句话我想应该是这个意思:
在什么都（一条扫描线上四个按键）没按下时，应该就是卡死的。
对于任何一条扫描线，当我在该扫描线的四个按键上什么都没按下时，程序直接进入下一扫描线，
不会停在while循环当中
在每个行扫描过程中，前两个while可以用if语句代替，最后的松手检测必须用while；
对于测试1：正如你在23楼说的，不管怎么卡住，显示都不会消失
测试2：先松开的按键先退出循环，然后停留在当前没有放开的那个按键松手检测上
所以松手后必然显示后送的那个按键，但在没松时一直显示最初停留在数码管上最末位的数字

yaoyong

不好意思写错了，因该是DB7

247153481

在keil中生成mof文件，然后加载到protues中，可以单个语句来仿真，好像还可以查看寄存器的状态，你先试试看。

辛昕

也是，先看问题出在哪先

辛昕

俺觉得，你这个读键函数，只写错了一个地方，就是 等待松手哪里。

条件写反了，应该是等于而非不等于。

当然，如果考虑多键的不同时间松手检测的话，你可能不能只用temp，而要再动动脑筋。

yaoyong

这个没弄过，最多只在仿真时用单步执行的按键，关键也不知如何操作

yaoyong

好吧！不再纠结这个问题了，反正就这样吧！
首先，按你的说法，把把对temp值得测试改为等于
就相当于去除松手检测，这回是真的卡死了，按啥都没反应了；
直接进入死循环；
但是在同时如果把while部分改成if的话现实的情况又会不一样
那样的话在按下瞬间数码管值就改变，只不过前面的数码管比
之前一个显示得更亮一些前面讨论的那个程序是松手后数据才
改变，按下和按下以前都显示上一次的数据

yaoyong

手机像素差，就不传效果了，看懂了就行
呵呵

辛昕

你这话我就听不懂了，，，什么叫改成等于就去除了松手检测，，那就是真正的松手检测，，，，
别的没听懂，，
while改成if就对了，就是不能死循环，if就是对的。
反正一直在更大的循环里，其实效果一样，不过这样就不会卡死在一个地方了，比如你最除想的松手检测。

你这反应，我看程序还有问题，慢慢调
这过程一定很纠结，但做通了，就过关了

辛昕

亮了就对了。
亮了意味着程序更多的时间正常地分配在数码管显示上。
这个事情呢，告诉我们两件事，现在知道while等待有多恶劣了吧，把程序卡的死死的。
另一个事情，有时其实是程序写的不对，却认为是硬件问题，这种不科学的心态很正常，我也有过。
类似的心态还有，主频不够高，做不了这个事情。
时序太严格了，非汇编写不可，诸如此类。