文章目录
- 前言
- Performance
- Measurement Environment
- RAM and ROM Usage for OS Objects
- Single Core
- Multi Core
- Stack Usage
- Library Module Sizes
- Single Core
- Multi Core
- Execution Time
- Context Switching Time
- 总结
前言
前面一篇文章介绍了硬件的一些特性,本文为最后一节,主要介绍该OS port的性能
Performance
本章提供了RTA-OS内核的功能、性能和内存需求的详细信息。RTA-OS具有高度可扩展性。因此,当应用程序使用不同的特性集时,将获得不同的图形。本章给出的数字是基于以下配置的S32K ARMV7/GHS Port的代表:
- 系统中有32个任务task
- Standard build is used
- Stack monitoring is disabled
- Time monitoring is disabled
- 没有调用任何hooks
- 任务有唯一的优先级
- Tasks are not queued (i.e. tasks are BCC1 or ECC1)
- 所有任务在其入口函数中终止/等待
- 任务和isr不保存任何辅助寄存器(例如,浮点寄存器)
- 资源只能由任务共享
- 资源RES_SCHEDULER的生成被禁用
Measurement Environment
本章测量的硬件环境如下:
RAM and ROM Usage for OS Objects
每个操作系统对象都需要一些ROM和/或RAM。操作系统对象由RTAOSGen生成并放置在RTA-OS库中。主要是:
—Os_Cfg_Counters包括 counters, alarms and schedule tables。
—Os_Cfg包含大多数操作系统对象的数据
Single Core
下表给出了一个简单的单核配置中每个OS对象的ROM和/或RAM需求(以字节为单位)。请注意,对象大小将根据项目配置和编译器打包问题而变化
Multi Core
下表给出了一个简单的多核配置中每个OS对象的ROM和/或RAM需求(以字节为单位)。请注意,对象大小将根据项目配置和编译器打包问题而变化。
Stack Usage
RTA-OS中每个Task/ISR使用的堆栈量等于Task/ISR主体中使用的堆栈量加上RTA-OS保存的上下文。RTA-OS保存的运行时上下文的大小取决于Task/ISR类型和确切的系统配置。获得Task/ISR堆栈使用的正确值的唯一可靠方法是调用Os_GetStackUsage() API函数。
请注意,由于RTA-OS使用单堆栈体系结构,所有任务的运行时上下文驻留在同一堆栈上,并在任务终止时恢复。
因此,互斥任务(例如,共享内部资源的任务)的运行时上下文被有效地覆盖。这意味着worst cases下的堆栈使用率可以显著小于系统中每个对象worst cases的总和。RTA-OS工具会自动为您计算worst cases下堆栈的总使用量,并将其作为配置报告的一部分呈现
需要配置stack usage,实际生成的txt基本没啥用
Library Module Sizes
Single Core
RTA-OS内核是需求链接的。这意味着每个API调用都被放置到一个单独的可链接模块中。下表列出了标准状态下简单单核配置的每个API模块的节大小(以字节为单位)
单核的中断向量使用链接段为:os_vectors
Multi Core
RTA-OS内核是需求链接的。这意味着每个API调用都被放置到一个单独的可链接模块中。下表列出了标准状态下简单多核配置的每个API模块的节大小(以字节为单位)
双核的中断向量使用链接段为:os_vectors_0和os_vectors_1
Execution Time
下表给出了CPU周期内的执行时间,即处理器程序计数器的刻度。这些数字通常与CPU的时钟频率无关。要在CPU周期和SI时间单位之间进行转换,可以使用以下公式:
Time in microseconds = Time in cycles / CPU Clock rate in MHz
例如,需要50个CPU周期的操作将是:stopwatch
—在20MHz = 50/20 = 2.5µs
—在80MHz = 50/80 = 0.625µs
—在150MHz = 50/150 = 0.333µs
尽管使用stopwatch以与CPU时钟相同的速率来测量执行时间,但这在目标硬件上并不总是可行的。
如果stopwatch运行速度比CPU时钟慢,那么当RTA-OS读取stopwatch时,由于CPU时钟和stopwatch之间的分辨率差异,读取的时间可能小于实际经过的时间(用户指南提供了关于执行时间测量不确定性问题的进一步详细信息)
Context Switching Time
任务切换时间是指前一个任务的最后一条指令与下一个任务的第一条指令之间的时间。切换时间取决于切换上下文(例如ActivateTask()和ChainTask())。
中断延迟是中断请求被目标硬件识别到执行用户提供的处理程序函数的第一条指令之间的时间:
对于1类isr,这是硬件识别中断所需的时间。
对于第2类ISR,这是硬件识别中断所需的时间加上RTA-OS设置ISR运行的上下文所需的时间。
上述时间基于240M CPU Clock
由上表可知,E,F,J,K花费时间较长(主要是WaitEvent和SetEvent及二类中断切换),常规的task任务切换花费时间较短。
总结
OS中还有很多需要学习的地方,比如alarm,核间通讯的实现,任务的上下文切换等。。。