《嵌入式软件的时间分析》读书活动：4 第四章读书笔记-软件时间理论

hehung

《嵌入式软件的时间分析》读书活动：4 第四章读书笔记-软件时间理论 [复制链接]

第四章讲解的是软件时间相关的一些定义，理论。

章节如下：

第4章 软件时间理论 53
4.1 时间参数 53
- 4.1.1 RTOS 调度（OSEK、AUTOSAR CP 等）时间参数 53
- 4.1.2 与 POSIX相关的时间参数 58
4.2 统计参数 58
- 4.2.1 小值和值 59
- 4.2.2 平均值 59
- 4.2.3 直方图 60
- 4.2.4 非定期事件的发生模式 60
4.3 CPU负载 61
- 4.3.1 定义 62
- 4.3.2 选择观测范围 64
- 4.3.3 扩增的 CPU 负载 65
- 4.3.4 使用后台任务时的 CPU 负载 66
4.4 总线负载 67
4.5 逻辑执行时间 67
4.6 总结 68

1. 时间相关参数

该章节讲解了一些时间分析相关的参数，使用了一些缩写词来标记不同的时间参数，并对这些时间参数做了详细的解释（page 54）：

CET：Core Execution Time，即核心执行时间。
DT：Delta Time，指一个(周期)实例开始到下一次开始的间隔时间，即连续两次开始同一个任务所间隔的时间差。（实际周期）。
PER：PERiod，周期。指连续两次激活相同任务的时间差。（期望周期）。
JIT：JITter，抖动(更准确地说是周期性抖动)。描述实际周期时间与期望周期时间之间的偏差。
J：Absolute Jitter，绝对抖动。指事件的标准时间与实际时间的关系。
RT：Response Time，响应时间。调度理论中最重要的时间参数，它指示了从需要执行任务或中断的时间到完成执行任务所经过的时间。
DL：DeadLine，截止时间。指允许的最大响应时间。截至时间是一个规范，无法测量。
GET：Gross Execution Time，总执行时间，即总运行时间。指从任务开始执行到终止执行的时间差，或是从中断、Runnable、函数或代码片段开始执行到结束执行的时间差。
IPT：Initial Pending Time，初始挂起时间，即初始延迟。是任务等待开始的时间，即从激活到开始执行的时间差，或者是从中断进入挂起状态到ISR开始执行的时间差。
ST：Slack Time，间隔空闲时间。指所观测对象的一个实例结束到下一个实例开始所间隔的时间。
NST：Net Slack Time，净间隔空闲时间。用间隔空闲时间减去间隔空闲时间段内属于更高优先级任务或中断的所有CET，即可计算得出净间隔空闲时间。
PRE：PREemption Time，抢占时间，即中断时间。中断时间并不重要，它反映了相应实例执行期间的所有中断和抢占的时间总和。
NPR：Number of PRemptions，抢占次数，即中断次数。中断次数可以针对任务、中断、Runnatle、函数或代码片段的单个实例，也可以指特定时间段内所有中断的总和。

2. 统计参数

时间测量的重点在于确定最小值、最大值和平均值。

对于特定的数据量，最小值和最大值都比较容易确定，大量多次统计就可以确定最小值和最大值。

平均值就是所有时间值的非加权算数平均值。书中也提到了平均值计算虽然简单，但是如果确定计算哪个范围内的平均值就是一个值得讨论的问题了。

3. CPU负载

CPU是会一直处于工作状态的，即使不需要执行代码，CPU也会一直执行机器指令。CPU负载是不计算空闲代码的，空代码是没有功能的代码。

单一CPU和观测期t1内的CPU负载可以用时间t2(CPU花在功能代码而非空闲代码士的时间)除以现测期t1的持续时间计算得出，即t2/t1，计算值范围为0~1，通常用百分比表示。

CPU负载的计算虽然很简单，但是如何选取观测期间却是很难回答的。书中列举了监控周期选择不合适会导致的一些问题：

使用超周期（各任务周期的最小公倍数）时，系统某一点局部过载，但是总体CPU暂用率还是可能会比较低，不能监控到局部过载的问题；
使用最长任务的周期时，也会有上述情况；
周期太小则会在过载部分为100%，但是其他部分很小，导致CPU负载率在0~100%来回跳转；

所以一般而言，观测周期应该尽可能长吗，但是不能太长。还需要结合实际情况来确定

4. 通信总线负载

通信总线的负载计算方式和CPU负载的计算方式是一样的。总线在传输数据的时候则表示总线处于忙状态，没发送报文的时候就是空闲状态。

5. 逻辑执行时间

逻辑执行时间(LogicalExecution Time LET)是一种解耦功能与通信概念，目的是使嵌入式软件(尤其是在多核应用中)具有确定性，从而更加稳定、安全且易于分析。

多核通信的时候一般都是：任务在开始时会接收数据，然后处理该数据，并在终止之前输出数据。这样的结构会带来一个问题，即数据发送时间很大程度上取决于任务的执行时间，如果任务结束时间早，则数据早发送，结束时间晚，则数据晚发送。

下面就是作者提到的逻辑执行的时间范式：

使用逻辑执行时间范式，接收和传输时间在一定程度上与任务的执行时间解耦。接收和发送均在任务执行期间的固定时间进行。这种范式下，任务执行的时间长短都不会影响定义好的“通信模式”。但如果执行时间过长到了发送时间还没有执行完成，则可能会发生错误处理。

见下图：任务执行完成并不会立刻发送数据，而是等到了设定的时间才会发送。

总结

本章介绍了很多与时间相关的参数，后面的很多章节都会涉及这些时间参数。还介绍了CPU负载的计算方法以及逻辑执行时间的通信和任务调度解耦的方法等。

学了本章的收获还是挺大的，虽然一些知识之前有了解过，但是还没有这么系统的学习过，而且作者还使用具体的示例讲解了可能得问题和解决方法，对后续的时间分析很有帮助。

秦天qintian0303

如果任何一个嵌入式系统都通过这个理论去分析，能带来什么好处啊

hehung

秦天qintian0303 发表于 2024-7-7 08:29 如果任何一个嵌入式系统都通过这个理论去分析，能带来什么好处啊

这个章节讲解的理论是关于时间的，通过这个理论可以统计出软件中各个环节暂用的时间长短，然后针对长时间的任务或者片段做优化，可以帮助快速定位耗时任务。嵌入式软件一般最关注最大CPU占用率分，析出来可以知道CPU最大占用率是多少，能不能cover住最坏情况的的功能处理，这些都可以帮助定位出时间消耗最大的部分，便于后期做定向优化