RTT时钟管理篇——软硬定时器理解(二)

野火RTT第22章软件定时器
2018年12月29日
10:48

打开软件定时器的宏才能用软件定时器线程、才能使用软件定时器。否则还是硬件定时器(在systic中断中管理超时函数)。
有两个定时器列表:一个硬件定时器链表、一个是软件定时器链表。

问题1:软件定时器的上下文是线程——啥意思?硬件定时器的上下文是中断。为何称为软件定时器?

问题1解答:明白了,软件定时器原来是另外开辟了个线程来专门管理软件定时器的,优先级默认4,所以说软件定时器的上下文是线程——可不么?它就在线程里面的,它就是个线程。在这个线程里各查询软件定时器是否到期,和那个系统定时器(线程的阻塞延时就是挂在系统定时器的链表下,升序排列)一样的方法,升序排列。软件定时器是挂在软件定时器的链表上的,在软件定时器线程中进行查询。

问题2:为啥有软件定时器?

问题2解答:因为硬件定时器资源限制,数量不满足客户需求。

问题3:32位的无符号变量作为系统节拍计数器,有没有考虑翻转?

问题3解答:这个没问题的,到最后了FFFF FFFF再+1就变成0了,不耽误的,比如当前tick值为FFFF FFF0 有个软件定时器要延迟20个tick,20的十六进制是14,那么值就变成,FFFF FFF0+14=4,不耽误呀,不影响呀,当前计数值tick会继续加加加,直到翻0继续加达到4,就能达到20的延时值了呀,所以不用担心!至于为何要用32为变量,是因为可以扩大一次性输入的延时值。假如是8位的,你最大255,你说我要延时300怎么办?直接超了,如果此时tick值为0,你延时300,一加等于45,那tick值到45时就达到延时的执行延时了,这就不对了嘛!而32位的一次性延时尺度可以达到49天的时间,已经很长了。

问题4:软件定时器没有硬件定时器准,怎么理解?

问题4解答:因为软件定时器是个线程,所有软件定时器超时管理在这个线程中实现,而所有线程是有优先级,如果有更高优先级占用CPU使用权,那么就会影响软件定时器的精度。换句话说,当软件定时器管理这个线程唤醒了,但是不一定立马运行,所以这个不精准。而硬件定时器是在中断里实现管理的,那肯定比软件定时器在线程里管理更准确。

问题5:我在想不能用systick的中断或其他中断来执行硬定时器么?

问题5解答:定时器分为软件定时器和硬件定时器,可以选择在systick中断中实现定时器超时函数的管理(也是回调函数),这就是硬件定时器超时函数管理。也可以选择线程中实现软件定时器超时函数管理。

问题6:定时为何要限制到32位变量的一半呢?另外用当前值-超时时间<32位无符号变量值的一半来判断是否超值,什么意思?

问题6解答:这个需要自己大脑动态想一下,或者自己计算下就出来了。大脑动态想一下,比如当当前tick值为0时,延时值设置要小于最大值的一半(此时这就是超时值),那么当tick值减去这个超时值时,其值大于最大值的一半。因为是无符号值,0-1变成最大值了呀0xFFFF FFFF,那么因为延时值不能<最大值一半,所以没有超时时其值是大于最大值一半的。当超时了,tick值减去超时值肯定小于最大值一半。而且基本上很快执行超时函数把这个值更新掉了。由下图可知,就算当前32位tick变量值要溢出了,加上延时值后的超时值已经溢出了,但是因为是无符号的32位变量,溢出就是翻0向上计数呀,这样的话依然不影响超时判断,超时判断公式依然成立,每次systick定时器中断判断:当前值-超时值<32位值的一半,若满足,则说明超时了,否则没超时。所以在systick中断中无符号计数变量不需要对它溢出处理,溢出也是对的,丝毫不影响定时器超时判断。

问题7:硬件定时器不是管理线程的么?还能管理超时函数?

问题7解答:你搞胡涂了,所有线程都内置它自己的定时器,所有线程创建的时把它们内置的定时器的超时函数都指向了同一个超时函数:恢复线程、执行调度。而你另外创建的创建的定时器不是线程内置的定时器,两码事用户创建的定时器的超时函数是指向用户自己定义的超时函数,所以这是两码事:一个是线程的内置定时器的超时函数,一个是用户开辟的新的定时器的超时函数。当用硬件定时器(systick)就是和线程用的是同一个定时器列表时,用户开的定时器和线程的定时器花在同一个定时器链表上——系统定时器链表(硬件定时器链表)。当开启软件定时器时,用户自己定义的定时器是挂在软件定时器链表上的,而线程内置的定时器链表挂在硬件定时器上的。

软件定时器资源占用:1,一条队列资源2,一个线程资源

硬件定时器因为是在中断中执行,所以对超时函数有很强的限制:1.时间不能太久2,不能有挂起、等待操作3.不能申请动态内存、释放动态内存

软件定时器因为是在线程中执行,所以要求就比较宽泛一点:1.时间也要短2,不允许有阻塞挂起、死循环3,不能影响其他超时函数的下一次回调。也就是时间短的标准。其他的定时器的定时到了你这还没运行完,那别的超时函数就没用了完蛋了!

使用硬件定时器,在时基更新的时候,查询的定时器包含线程的内置定时器和用户定义的定时器,它们都挂在硬件定时器列表上(系统定时器列表),而且特点是:所有线程的内置定时器的回调函数都是一个函数,而用户自定义的定时器的回调函数由用户自定义。

在每次系统滴答中断进行线程恢复和调度是通过调用线程内置的定时器的超时函数实现的。抛开一切不说,滴答中断里是查询定时器,有超时的定时器就调用其超时函数,当这个定时器是线程内置的定时器,它这个超时函数就是恢复线程和执行调度。如果这个定时器是用户自己开的硬件定时器时,其调用的超时函数就是用户自己写的。

这就是定时器的巨大作用了,这是定时器和线程、用户自定义相结合的结果。

<think>好的,我现在需要帮助用户理解DRX、HARQ和RTT定时器在LTE和5G中的相关概念及配置参数的作用。首先,我应该从DRX开始,因为用户提到了DRX机制,并且引用了相关的资料。DRX即非连续接收,主要用于节省UE的功耗。用户提供的引用[2]提到“Opportunity for DRX”是睡眠时间,UE在这段时间不监控PDCCH。我需要解释DRX的基本工作原理,包括激活期和睡眠期的切换,以及相关的定时器参数,比如onDurationTimer和drx-InactivityTimer。 接下来是HARQ RTT定时器,用户特别提到了引用[1],其中说明了HARQ RTT Timer的作用是UE在等待下行重传数据前需要等待的最少子帧数。这个定时器的作用是防止UE过早地启动重传定时器,从而节省电量。需要说明在LTE和5G中这个定时器的配置差异,比如LTE通常是8ms,而5G可能根据子载波间隔调整。 然后是drx-RetransmissionTimer,当HARQ RTT Timer超时后,这个定时器启动,用于监控可能的PDCCH重传调度。需要提到这个定时器的配置参数以及在不同场景下的作用。 用户还提到配置参数在LTE和5G中的区别,我需要对比两者的不同,比如5G的参数可能更灵活,支持不同的子载波间隔,而LTE则较为固定。同时,用户可能关心这些参数如何影响网络性能和UE的省电效果,需要结合引用中的信息,比如引用[3]和[4]提到的BSR和SR机制,说明DRX与其他机制的协同工作。 最后,生成相关问题时要覆盖DRX的工作原理、定时器协同、配置差异以及优化方法,确保问题能够引导用户进一步深入学习。需要确保回答结构清晰,分点解释,并正确引用提供的资料。</think>### DRX、HARQ RTT定时器配置及作用详解 #### 1. **DRX(非连续接收)机制** - **核心作用**:通过周期性地关闭UE的射频接收电路,减少功耗。在“DRX睡眠期”内,UE不监听PDCCH信道;在“激活期”内,UE需监控PDCCH以接收调度信息[^2]。 - **关键参数**: - **`onDurationTimer`**:定义每个DRX周期内UE必须保持唤醒的最小时间,用于检测是否有新数据调度。 - **`drx-InactivityTimer`**:若在激活期内收到新数据,则启动此定时器,延长UE的唤醒时间以等待后续数据。 - **`drx-RetransmissionTimer`**:专门用于监控重传数据的调度窗口(后文详述)。 #### 2. **HARQ RTT定时器** - **作用**:定义UE在收到下行数据后,需等待的最短时间才能接收对应的重传数据。其目的是避免UE过早启动`drx-RetransmissionTimer`,从而减少无效监听[^1]。 - **LTE与5G配置差异**: - **LTE**:固定为8个子帧(对应HARQ往返时延)。 - **5G**:支持灵活配置,例如根据子载波间隔(SCS)调整。若SCS=15kHz,典型值为10~16个符号(取决于网络配置)。 #### 3. **drx-RetransmissionTimer** - **触发条件**:当`HARQ RTT Timer`超时后启动。 - **功能**:在DRX激活期内监控PDCCH,等待基站调度重传数据。若超时仍未收到,则放弃本次重传。 #### 4. **LTE与5G参数对比** | 参数 | LTE配置示例 | 5G配置示例 | |-----------------------|---------------------|----------------------------| | HARQ RTT Timer | 8子帧 | 符号数(如12符号) | | drx-RetransmissionTimer | 4~8子帧 | 灵活符号/时隙 | | DRX周期 | 10~2560ms | 支持更短周期(如10ms以下) | #### 5. **与其他机制的协同** - **与BSR/SR的关系**:在DRX激活期内,若UE有上行数据(如触发BSR),需优先发送调度请求(SR)以获取资源[^3][^4]。 - **与HARQ进程的关联**:每个HARQ进程独立管理重传,需与DRX定时器同步以避免冲突。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值