“绝对过载”是指一个事件的处理时间越过了其截止期。
“事件突发”是指一个事件产生时，CPU还没有完成上一个相同类型的事件处理。
“相对过载”是指当出现了“事件突发”时，虽然没有造成“绝对过载”，但由于CPU正忙于处理以前的事件，而致使当前产生的事件不能被“立即”处理的情况。
为了避免 “绝对过载”的情况发生，在系统设计时，我们需要按顺序确定以下条件或设计参数：
1、事件的种类。
2、事件发生的间隔时间。
3、事件截止期。
4、事件处理时间。
事件的种类，可以分析系统中的输入输出设备而得知。对这些输入输出设备进行定量分析，确定出各个设备所产生的事件的种类.
而事件的间隔时间，要根据系统运行时，输入输出设备的负载情况进行定量分析，负载情况，是设计需求书里必须给出的详细指标，如果通信速率，采样速率等等。一般来说，负载越重，事件产生的频率就越高，间隔时间相应就越短。
确定某个事件的截止期，基本按下面两个规则，取其小值：
1、设计需求规定的，或公认的响应时间。
2、该事件产生的平均间隔时间。
响应时间，这里并不是指事件的开始处理时间。而是指事件处理，到达了某个阶段的时间，按设计的处理逻辑，需要在这个时间内，对该事件作出一个响应，通常是输出信息到输出设备。
例如：一个按键的事件处理逻辑，整个时间可能比较长，如果等到全部完成后，才给用户响应信息，就很不友好。
而比较好的处理方法是，先在输出设备上显示“处理中，请等候”之类的信息，然后再处理事件，当处理完成后，告诉用户处理结果。
在这里，我们需要澄清一些概念，大家都知道，所谓“事件处理”，必须得到处理结果的，这个结果会体现在对“输出设备”的操作上。
一个事件的处理，在很多实际系统中，并不是全部处理完成后，才操作输出设备。
而是根据处理需要，可能会在处理过程中的不同时点，对输出设备进行多次操作，并且也有可能需要对多个输出设备进行操作。
-------------------------举例，图一 ----------------------------------------------
这是一个事件处理的过程示例。
事件产生后，可能会依次访问多个设备，但每一次访问，都应该有自己的内部截止期。
实际上，事件处理过程中，还会有更加复杂的情况。例如，处理过程中访问了UART，那么UART设备又可能产生新的事件。那么一个事件的处理过程，就有可能需要分解为多个事件的分步处理。
实际规划设计一个比较实用的系统，并不是那么简单的事。我们以前的系统设计，不清楚的地方，或者有意无意忽略的地方，实在太多了。
事件产生的平均间隔时间，对确定截止期，也是一个重要的参考，某些事件，比较有规律，最长的间隔时间，与最短的间隔时间，相差不是特别大。
当然，确定不会产生事件的时间段，需要从计算中排除。
某些输入输出设备，在系统整个运行过程中，并不总是工作的。
例如，UART发送部分，当CPU因有信息需要输出，而访问这个设备时，它才会产生相应的事件。
对于这样的情况（最长的间隔时间，与最短的间隔时间，相差不是特别大），使用平均间隔，作为截止期的计算条件之一，是比较合适的。
但那些其它事件，它们产生的间隔时间差别特别大，而且间隔时间的分布，也没有什么规律，以至于平均间隔的说法，变得毫无意义。
那么，对于这样的情况，最安全的设计，就只能以事件的最小间隔时间，作为事件截止期的计算条件了。
事件的处理时间，基本上由事件的截止期而定，这只是系统中的一种事件类型，一般来说，系统中还会有其它的事件类型，所以还必须以一个比较典型的时间段为单位，把系统中所有事件的处理时间加起来。
如果所有事件的处理时间之和，大于了这个时间段，那么就意味着系统整体性过载。
那么就需要把各个事件的处理时间按比例缩短，并按常规，适当保留一些时间余量，以应付一些意外的情况。
到此，系统设计需要的各种条件和参数，基本已确定了，下面我们应该怎么做呢？
对于程序设计阶段来说，最重要的参数就是：事件处理时间。
我们需要根据这个参数，适当的处理逻辑和算法，并且选择合适的CPU。实际上，很多时候大家是先确定CPU的吧？我并不是说这就不合适。选用什么CPU，有很多其它的原因。简单的项目，没什么大的问题。复杂的项目，还是建议大家做一下系统分析，主要是对整个系统的负载，有一个不说很精确，但至少要大概了解。实际上，因为技术不到位，而失败的项目，也不少。
有时候，用户的有些需求，是非常不合理的，但可能他自己都不清楚这些需求到底是干啥的。如果你在系统分析时，发现为了实现某些不合理需求，而可能导致费用大增，或开发时间延长，那么你可以试着与用户沟通一下，了解他真实的想法。这样做，有可能从非技术方面，解决你的难题。这些，都是项目设计可能涉及的功课。 |
楼主
标题置顶
标题高亮
