Rya*_*yan 3 embedded real-time
我认为这是"vi vs. emacs"类型的问题之一,但无论如何我都会问,因为我想听听别人的意见.
通常在嵌入式系统中,微控制器具有硬件定时器外围设备,其为软件定时器子系统提供定时基础.该子系统允许开发人员创建任意数量(受系统资源约束)的定时器数量,这些定时器可用于生成和管理系统中的事件.通常管理软件定时器的方式是硬件定时器设置为以固定间隔生成(或者有时仅在下一个活动定时器到期时生成).在中断处理程序中,调用回调函数来执行特定于该计时器的操作.与往常一样,这些回调例程应该非常短,因为它们在中断上下文中运行.
假设我创建了一个每1ms触发一次的计时器,其回调例程需要100us来执行,这是系统中唯一感兴趣的事情.定时器子系统应该何时安排下一次处理此软件定时器？它应该是中断发生后的1ms还是回调完成后的1ms？
为了让事情更有趣,比如硬件开发人员说,在某些操作模式下,CPU速度需要降低到最大值的20%才能节省电量.现在回调例程需要500us而不是100us,但计时器的间隔仍然是1ms.假设在此待机模式下,回调中增加的延迟对系统没有负面影响.同样,计时器子系统何时应该安排下一次处理此软件时间？T + 1ms或T + 500us + 1ms？
或者也许在这两种情况下它应该分开差异并安排在T +(execution_time/2)+ 1ms？
在实时操作系统中,定时器和延迟都与系统节拍同步,因此如果事件处理少于一个定时器节拍,并且在定时器节拍边界上启动,则使用定时器或延迟之间将没有调度差异.
另一方面,如果处理超过一个滴答,则需要定时器事件以确保确定性的无抖动定时.
在大多数情况下,确定性是重要的或必不可少的,并使系统行为更具可预测性.如果时间从处理结束开始递增,则处理的可变性(静态 - 通过代码更改或通过差异执行路径的运行时)可能导致变量行为和未经测试的极端情况,这些情况难以调试或可能导致系统失败.