只为uC而生，uS成长历程8

辛昕

只为uC而生，uS成长历程8 [复制链接]

7 的进程有点快，显得过于跳跃。

我不应该用 贴上代码 来结束，显得莫名其妙。
我应该接着话题，解释 超时判断机制。

今晚开始的比较晚。
不知道能写多少。

laoguo

辛苦辛苦，，我先睡。

辛昕

超时判断的思路很简单。

它是基于一种非常合理的解释。
因为当通信方发来一组数据串的时候，数据应该一个接一个接踵而来，每个字节之间的时间间距不应该过长。
否则就认为这组数据应该作废。

我们考察一下这种假设是否合理：
永远要记住，在实现程序以前，一定要考虑你是基于对实际应用情况做了什么假设，这种假设是否合理，这十分重要，因为它关系到最后你的程序
在实际的环境中的适应性和稳定性（也就是所谓的鲁棒性性，我们不说洋话）。

1.我们脑子里首先会想到非常理想的情况。对方发来一组数据，直到发完最后一个才继续执行其他任务。
在这种情况下，很自然，接收方也应该连续收到一串数据，没给数据之间的时间间隔只与波特率有关系，举个例子。
9600bps时，大概是1200 byte 一秒，那么我们可以简算，每个字节的发送时间不超过1ms。

但这只是最单纯的最理想的情况，实质上，接收方和发送方都可能有变化的情况。
       比方说，我们都知道，单片机程序基本上不会是只在main函数（或称为 主线程）里运行，它总有个什么定时器中断，串口中断，一般来说，至少都有定时中断。

       我们不能对其中断离开CPU（也就是离开串口发送进程）的情况做任何假设——我们只能考虑最差的情况，很有可能，它离开以后被阻塞在某个任务里，或者因为中断服务程序执行时间过长，这些完全都有可能。
        所以，我们从接收方可以观察到发送数据之间是有停顿的，而不会是均匀的不到一毫秒的间距；
        所以，显然，这个假设时间不能只以发送的波特率来假设。
        我见过一种假设：
        它认为，间距时间一般可以取1位到两位的传输时间——显然，这种假设就是忽略了这种情况，是不可取得。实质上，我们应该设置的更长；

        3.另一种情况，是接收方的情况，从机方同样有多个线程抢夺CPU的可能。虽然我们一般会使接收在中断方式下完成。然而问题是，定时器中断一般仍然是必不可少。
        所以——你不会有机会永远设置串口中断优先级最高——而且实际上这是非常不合适的，因为串口的实时性要求远比很多任务低。所以，从接收方来说，同样有机会延误处理接收到的数据，不管是main主线程里查询接收还是串口接收中断方式。

        以上假设虽然不是十分完整，但基本可以概括了选取延迟时间的理由。

        所以，我们得到的第一个假设就是：
我们认为在正常情况下，一串完整的数据串，每个字节之间的间隔时间应该是有限的，只是这个时间的确定不应该只考虑理想情况下的传输速率。
然而前面也说过，限于实际情况，也许每个字节之间的时间间隔会非常长也可能非常短，这取决于程序的均匀性。
实质上我们不会获得很好的均匀程度，甚至是非常恶劣。
但我们不能对其给予厚望，我们只能防范它，或者对它作出限制，避免它破坏我们的程序。

这个时候，我们要约定一个处理方式，当我设置了一个合理的最大时间间隔以后，假如我出现在这个时间间隔以后再收到的数据，我不再认为是同一个串，而认为是第二串。
那么，假设，假设我们就是遇到了最恶劣的情况，两个数据被分开了我们该怎么办呢？
实质上我们无需作过多处理，因为这样一个数据意味着程序已经有了某些不对劲的行为，我们完全可以忽略这两组数据。
偶尔的错误必须得到容许。
因为我们的数据串分析模块会做接下来的事情，假如我没有收到一条完整的指令，那我就直接忽略好了，这并没有什么了不得。

在实际中，我们往往采用根据实际情况先粗略假设，然后微调，最终确定。

[ 本帖最后由 辛昕 于 2013-8-6 22:28 编辑 ]

247153481

插一下

辛昕

上面我们已经详细解释了这种思路。
现在我们来考虑我们要怎么实现这种机制。

首先，我们需要 定时，用它来判断 字节和字节之间是否超时。
其次，我们需要一个缓冲，来暂存接收到的数据。

这两点几乎毋庸置疑。
关键是如何把它们组成一个有机的整体。
在这种情况下，我们还是老方法：自上而下，从如何调用开始考虑，并设计好函数接口，然后再去考虑如何调用。

最简单的方法就是以一个我们熟悉，具体的通信过程来考虑。
比如我们最为熟悉的串口。
然后我们再在它的基础上，从个别到一般引申开来。

我们回忆我们平时是怎么写串口接收函数的。
1.我们首先 初始化串口模式，允许接受；
2.然后我们 用一个数组（缓冲）去依次存放从SBUF（51为例）收到的数据；
3.最后接收完毕，我们通过数组取出数据去处理；

第一步，初始化，总是在函数开始执行的时候调用，这个没有疑问；
第二步，我们知道这个过程是在 串口接收中断里完成的——事实上，接收中断里基本也就只做了这件事。
至于执行的时间，自然也就是接收中断发生的时候。也就是我们收到一个数据的时候。
第三步，这也是核心和新鲜的部分了。

从前面的分析中我们知道。
实现的方法是 以一个定时器（此定时器非彼定时器，这个定时器不是一个硬件中断，而是一个变量。）
以一个定时器来判断字节与字节之间是否超时；

从此处，我们知道这个定时器需要做三件事：
1.在没有接收到下一个字节的时候不断地累加；
2.在新接收到一个字节的时候 清零；
3.不断地被判断，是否超时；

辛昕

接着上面提到的 超时计时器要做的三件事。

1.新数据到来之间，不断累加。
   这里只有一个问题：
   在哪里累加？
   也许习惯性地，你会非常自然地想到。既然是定时器，肯定是要放在 定时器中断 里啊。
   为什么呢？
    因为这样准时啊？
    为什么要准时？
    ——说实话，但我问自己问到这里的时候，我都被问倒了。

    然而，几经思考（当然是以前），我找到了一个更加完整更加确切的理由：
    1.放在定时器中断里，实际上并不是为了追求准时——我们说过，串口接收是一个实时性，精确性要求不高很一般的任务。
    2.确切的说，放在中断里的目的是为了让这个定时器判断的更加均匀。
     换个角度来说，假如我们放在main主线程里，或其他更加重要的或者确切需要用到的线程里的话。
     会出现什么情况？
     main函数总是不断变化的，随着越来越多的函数被调用，任务被执行。这个main的循环周期不断变化，也许三天前我们的循环周期是1ms,结果，现在就变成了3ms
     当然，我们说了，重点不在于精确性，重点在于 均匀性和稳定性。
     如果有一天我们的循环周期变成了30ms.那么，这个时候我们要判断一组数据串接收完毕就至少要30ms.
      而这显然并不合理。但我们没有办法把这个时间设置的更低，仅仅是因为main的循环周期就有30ms......

      此外，对于我们调定的时间，我们在程序开发的过程里，必然少不了要根据main循环周期的变化而调整这个延迟数值。
      这就带来了风险和麻烦。

      因此，我们一般把定时器放在定时中断里累加。
      也因此，这个定时器必须具有静态特性，也就是说，它必须永远保持存储的值。

      这里要先提一点：
      任何时候，我们讨论一个方法的时候，会最终选择一个最恰当的方案，但这并不代表其他方案就永远不能被选中。
       因为，后面在考虑到如何调用这个超时机制的时候，我意识到，因为这个要放在定时器中断里的 计时器，使得我们的用户接口略显复杂。
       于是这个时候我们会认为，对于一些程序任务稀少，简单的，实时性要求不高的系统，我们完全可以不把定时器放到一个均匀的定时中断里去。
       当然，这是后话，这里提一下就可以。

       我只是想让你知道。
       我们曾经有过不止一个选择。而我们除了选择放在中断里还有另外一个或者几个其他方案备用。它们在某些时候也许会很方便，不要忘了他们，以便你需要的时候可以灵活选择。

辛昕

插就插呀，为何好像很生气的样子捏~~~

辛昕

247153481

,,,楼主好厉害。。。辛苦了。向楼主好好学习

cat3902982

我也支持下楼主！