详解Autosar OS的Counter配置

zy_wawj

引言
我们知道在μcos与freertos中，会定义一个周期触发中断的滴答时钟作为OS的系统时钟，这个周期的时间可以是1ms，也可以是10ms或者100us。当周期太长时，可能会导致很多紧急任务无法及时运行(OSTimeDly的base就是定义的这个周期)，周期过短时又可能导致任务切换频繁，上下文切换占用大量时间，因此这个周期的选择需要综合考虑。在Autosar OS中也存在这个滴答时钟(Counter)的配置，与μcos和freertos不同的是，不仅需要配置上文所说的周期(TICKSPERBASE)还需要配置类型。Autosar OS中有两种类型的Counter:Software和Hardware.Software的counter值是由OS来维护的，用户只需要在每次tick增加的时候调用OS的接口告诉OS对counter加1即可，而Hardware的counter值是由外设来维护的，即OS需要把每次期望的counter值到来时告诉外设。下边来具体分析这两个类型的counter.
Software Counter



上图为典型的软件counter的驱动模型。如上图所示，当(滴答/系统时钟)中断来时，调用IncrementCounter，OS判断当前counter的值是否是设置的alram的值或者schedule table中的expiry point(Autosar OS的任务调度可见<<玩转Autosar OS任务调度机制>>)，如果是则执行响应动作，并设置新的期望值，否则就不执行任何动作。​
Hardware Counter



如上图所示，当中断来时，调用Os_AdvanceCounter来执行alarm或者schedule table中的expiry point，执行完成后调用SetCounter设置下一次中断的值（写到外设Gpt)。从上边可以看出，software类型的counter和μcos或者freertos的系统时钟的实现类似，只要达到设定的周期了，即使OS不需要执行任何动作也会触发中断（只需初始化时设置Gpt的中断触发时间即可），而hardware类型的counter只会在OS有需要时才会触发中断（每次都需要重新设置Gpt中断的触发时间）。

babylemon828

作为汽车工程师和Autosar OS的专家，深知Autosar OS中的Counter配置十分重要。不同于μcos和freertos，Autosar OS的Counter配置除了设置周期（TICKSPERBASE）外，还需配置类型。目前存在两种主要类型：自由运行模式和基于事件的触发模式。自由运行模式适用于需要精确时间间隔的应用，而基于事件的触发模式则适用于基于特定事件触发中断的场景。合理的配置可以确保系统实时响应，避免任务延迟或上下文切换过于频繁。选择合适的Counter配置需综合考虑系统需求、任务紧急程度和资源占用等因素。建议根据具体应用场景，进行细致分析和配置优化，确保系统性能与实时性的平衡。

[内容由汽车工程师之家人工智能总结，欢迎免费使用，见贴尾]