基于DWC_ether_qos的以太网驱动开发-LWIP的定时器模块详解

描述

一. 前言

LWIP的定时器模块,实现了通用的软件定时器,用于内部的周期事件处理,比如arp,tcp的超时等,用户也可以使用。这一篇来分析该模块的实现。

二.代码分析

2.1源码

源码位于

timeouts.c

timeouts.h

会按照如下条件编译

#if LWIP_TIMERS && !LWIP_TIMERS_CUSTOM

即LWIP_TIMERS为1 ,LWIP_TIMERS_CUSTOM为0才会编译,也是默认配置。

2.2数据结构

定时器的核心数据结构是一个单向链表,链表的节点如下

struct sys_timeo {


struct sys_timeo *next;


u32_t time;


sys_timeout_handler h;


void *arg;


#if LWIP_DEBUG_TIMERNAMES


const char* handler_name;


#endif /* LWIP_DEBUG_TIMERNAMES */


};

Next构成单向链表

time为绝对时间,即当前绝对时间滞后该值则表示定时器超时需要执行回调函数h。

arg可以传入参数,

handler_name是debug打印信息用。

2.3超时比较算法

定时器使用的是绝对时间,即定时器的time和当前now时间比较,time<=now则表示定时器已经超时了需要处理,否则定时器还未到时间无需处理。

但是这里会有个问题,溢出的问题,time<=now就一定表示time的时刻提前于now吗,不一定,也可能是到了定时器值的最大值绕回了,

比如如果定时器的值是32位的,

now为0xFFFFFFFF,time为0x00000001,

time

也可能time滞后于now为2的时间 即(0x100000000-0xFFFFFFFF)+0x00000001.

我们更倾向于是后者,因为后者的时间差更小,更符合实际情况,因为我们定时时间一般都很小。

这里的实现是

#define LWIP_MAX_TIMEOUT 0x7fffffff

#define TIME_LESS_THAN(t, compare_to) ( (((u32_t)((t)-(compare_to))) > LWIP_MAX_TIMEOUT) ? 1 : 0 )

实际上用到的就是我们上面提到的思想,我们更倾向于时间差更小的为实际情况,

实际该算法还有专门的文章进行讨论,网上可以搜到。

即定义定时器最大范围的一半,比如32位最大范围是00xFFFFFFFF,共0x100000000的范围,其一半的范围是0x80000000,即00x7fffffff,作为基准,最大就只能定时器该时间,大于该时间认为不合理,实际是绕回反向的。

这里((u32_t)((t)-(compare_to)))按照无符号32位进行计算

如果t

如果t为1, compare_to为2则((u32_t)((t)-(compare_to)))结果为0xFFFFFFFF。

实际上就是0x100000000-0x02 + 0x01.

定时器

如果t>compare_to

t为2, compare_to为1

则((u32_t)((t)-(compare_to)))结果为0x1

定时器

该表达式即可以理解为t滞后compare_to的时间(未来时间),

更形象的理解是a-b即b需要追赶多少到a,即compare_to追赶到t需要多久,有可能绕回。

如果该滞后时间比较大,大于总时间的一半即0x7fffffff我们则认为,实际不是滞后而是超前。

因为倾向于时间间隔短的符合实际情况。

所以如果t比compare_to大的非常多,大于TIME_LESS_THAN,我们也认为t不是滞后compare_to而是提前于compare_to,只是是绕回了。

1.总结

我们可以用跑圈追赶的角度来理解,即t和compare_to在环形世界赛跑,某一刻我们并不知道谁跑在前,谁跑在后,因为有可能”套圈”, 于是我们有一条假设, t和compare_to跑的速度差异不是特别大(类似我们定时器的定时时间不是特别长),所以如果t追赶到compare_to的距离大于跑道的一半我们认为不合理,所以认为是compare_to追赶t。

所以该算法能工作的前提条件是定时时间不能大于LWIP_MAX_TIMEOUT。

当然去处理查询定时器超时的间隔也不能大于LWIP_MAX_TIMEOUT,否则由于”套多圈”无法区分。

2.4内建定时器

定义了一个数组

const struct lwip_cyclic_timer lwip_cyclic_timers[]

提供构建定时器的必要信息(注意不是定时器本身,而是提供定时器信息,sys_timeouts_init根据此创建定时器)

数组成员结构体如下

struct lwip_cyclic_timer {


u32_t interval_ms;


lwip_cyclic_timer_handler handler;


#if LWIP_DEBUG_TIMERNAMES


const char* handler_name;


#endif /* LWIP_DEBUG_TIMERNAMES */


};

interval_ms为定时器执行周期,上述定时器要求是绝对时间,为什么这里是间隔时间呢,因为now+间隔时间就是绝对时间了,初始化时会自动设置。

handler是回调函数

handler_name是用于打印定时器的名字。

默认根据宏定义了一些内建的定时器

比如,使能了LWIP_ARP则使能该定时器,回调函数是etharp_tmr,间隔时间是1S。

用户可以配置这些宏来进行定时器的使能配置和周期配置。

#if LWIP_ARP

{ARP_TMR_INTERVAL, HANDLER(etharp_tmr)},

#endif /* LWIP_ARP */

#define ARP_TMR_INTERVAL 1000

初始化sys_timeouts_init时遍历lwip_cyclic_timers

通过sys_timeout->sys_timeout_abs动态创建定时器,定时器的绝对时间自动会在now基础上增加间隔(u32_t)(sys_now() + msecs);

这里i = (LWIP_TCP ? 1 : 0),如果有LWIP_TCP则从1开始, 0的TCP定时器单独处理,因为它不需要总是运行,没有tcp连接就不需要该定时器了,所以手动调用tcp_timer_needed()处理。

2.5接口代码

sys_timeouts_sleeptime

后面定时器轮询有分析,计算定时器链表中,头定时器,离当前时间的时间,

返回0表示头定时器已经超时需要处理,返回SYS_TIMEOUTS_SLEEPTIME_INFINITE表示没有定时器,其他值为头定时器离现在的时间间隔。因为定时器是按照时间从小到大排列,所以只需要判断头定时器即可。

sys_restart_timeouts

以定时器链表第一个定时器为基准设置为now绝对时间,后续的按照和第一个定时器的偏差设置。

在长时间没有调用sys_check_timeouts时,重新设置时基,来触发一次时间调度。

这样保证在长时间没有调用sys_check_timeouts的期间导致的定时器没有执行,这时能弥补下执行一次。

sys_check_timeouts

查询定时器,从链表头开始查询,如果超时时间到则执行对应的回调函数,并释放定时器。

因为已经排序不需要查询到末尾,查询到第一个为超时的定时器即可结束,因为后面的值更大肯定不会超时。

无OS时用户手动调用该函数

有OS时,tcpip线程自动调用。

注意定时器都是单次的,一次执行完后会删除,周期执行需要重新创建。

这里个人觉得每次都删除和释放不是很好,尤其是嵌入式平台,多了mem等操作一方面内存碎片的问题(如果使用内存池实现还好,如果共用堆管理则会有些影响,尤其堆本来就很小的资源受限平台),一方面效率降低。

sys_untimeout

从定时器链表删除一个定时器

sys_timeout->sys_timeout_abs

创建定时器,按照定时器值从小大到插入到链表

sys_timeouts_init

初始化内建定时器,前面已经分析过

lwip_cyclic_timer

内建定时器回调处理

由于定时器都是单次的,所以周期定时器需要重新创建定时器。

内建定时器时都是设置的该回调函数

sys_timeout(lwip_cyclic_timers[i].interval_ms, lwip_cyclic_timer, LWIP_CONST_CAST(void *, &lwip_cyclic_timers[i]));

通过参数再回调具体的不同的回调函数

const struct lwip_cyclic_timer *cyclic = (const struct lwip_cyclic_timer *)arg;


cyclic- >handler();

tcp_timer_needed/tcpip_tcp_timer

tcp定时器单独处理,创建一个tcp定时器

tcpip_tcp_timer会根据是否有tcp连接来确认是否需要重复定时器。

2.6定时器轮询

无OS时手动周期调用

sys_check_timeouts

有OS时在tcpip_thread线程中

TCPIP_MBOX_FETCH即tcpip_timeouts_mbox_fetch会自动调用

sys_check_timeouts。

我们来分析下tcpip_timeouts_mbox_fetch

首先sleeptime = sys_timeouts_sleeptime(); 获取最近一个将要超时的定时器到现在的时间间隔,这样mbox_fetch时就以该间隔时间作为超时时间sleeptime,这样如果在这个超时时间之前获取到了mbox则处理消息,下一个循环继续重复上述处理。否则等到超时再调用sys_check_timeouts();处理定时器。

sys_timeouts_sleeptime先要判断是否有定时器,如果next_timeout为空则说明没有定时器需要处理则超时时间sleeptime可以设置为无限大。

如果有定时器则只需要判断next_timeout头定时器得time与now比较即可,因为定时器是按照time从小到大排列的,所以最先超时得肯定是头定时器。如果next_timeout得time小于now,说明该定时器已经超时了设置为0,后面会马上调用sys_check_timeouts()处理。

否则计算next_timeout得time减去now为间隔时间。

也就是对应

if (sleeptime == SYS_TIMEOUTS_SLEEPTIME_INFINITE) {


  UNLOCK_TCPIP_CORE();


  sys_arch_mbox_fetch(mbox, msg, 0);


  LOCK_TCPIP_CORE();


  return;


} else if (sleeptime == 0) {


  sys_check_timeouts();


  /* We try again to fetch a message from the mbox. */


  goto again;


}

如果没有定时器sleeptime == SYS_TIMEOUTS_SLEEPTIME_INFINITE则 sys_arch_mbox_fetch(mbox, msg, 0); 参数0表示无限超时时间。

直到获取到消息才会return,否则就一直在此等待。

这里个人觉得有个BUG,如果刚开始没有定时器,且此时没有消息,则在此之后新创建的定时器将得不到处理,因为一直在这里等待消息了,虽然一开始基本都会有定时器所以不会进到这里,但是逻辑上来说还是不严谨。虽然这里无限等待可以有利于效率,因为没有消息该线程就不执行了,但是个人觉得设置一个固定的超时间隔可能更安全,这样保证该线程不会卡死在这里,超过时间没有消息也跳过重新执行,这样保证新创建的定时器能执行,最大误差就是该设置的固定间隔。这个间隔可以根据允许误差和效率均衡考虑设置,这样也不至于影响效率,也能保证定时器始终能执行。

sleeptime已经有定时器超时了sleeptime == 0则马上调用sys_check_timeouts()处理。因为没有消息所以goto again;重复,无需return。

如果sleeptime不是0也不是无限大,则按需设置超时时间

res = sys_arch_mbox_fetch(mbox, msg, sleeptime);

如果res返回超时则调用sys_check_timeouts处理定时器,goto again;重复上述过程,因为没有消息所以无需return。有消息则return到上一层去处理消息。

2.7DEBUG

lwipopts.h中定义LWIP_DEBUG_TIMERNAMES宏使能相关debug代码,

否则根据LWIP_DEBUG决定

如果定义了LWIP_DEBUG则LWIP_DEBUG_TIMERNAMES为SYS_DEBUG,否则为0。

SYS_DEBUG默认为LWIP_DBG_OFF,可以该为LWIP_DBG_ON

#ifndef LWIP_DEBUG_TIMERNAMES


#ifdef LWIP_DEBUG


#define LWIP_DEBUG_TIMERNAMES SYS_DEBUG


#else /* LWIP_DEBUG */


#define LWIP_DEBUG_TIMERNAMES 0


#endif /* LWIP_DEBUG*/


#endif

以上使能相关调试代码之后,还需要lwipopts.h中使能

TIMERS_DEBUG

按如下配置使能

#define TIMERS_DEBUG LWIP_DBG_ON


#define LWIP_DEBUG_TIMERNAMES 1

当然也要使能DEBUG

#define LWIP_DEBUG 1

和LWIP_PLATFORM_DIAG打印的接口宏。

此时可以看到打印信息如下,可以通过打印确定定时是否正确,定时器是否工作

sct calling h=ip_reass_tmr t=0 arg=0x2001548c


tcpip: ip_reass_tmr()


sys_timeout: 0x28213e48 abs_time=6223 handler=ip_reass_tmr arg=0x2001548c


sct calling h=etharp_tmr t=0 arg=0x20015498


tcpip: etharp_tmr()


sys_timeout: 0x28213e68 abs_time=6224 handler=etharp_tmr arg=0x20015498


sct calling h=ip_reass_tmr t=0 arg=0x2001548c


tcpip: ip_reass_tmr()


sys_timeout: 0x28213e48 abs_time=7223 handler=ip_reass_tmr arg=0x2001548c


sct calling h=etharp_tmr t=0 arg=0x20015498


tcpip: etharp_tmr()


sys_timeout: 0x28213e68 abs_time=7224 handler=etharp_tmr arg=0x20015498


sct calling h=ip_reass_tmr t=0 arg=0x2001548c


tcpip: ip_reass_tmr()


sys_timeout: 0x28213e48 abs_time=8223 handler=ip_reass_tmr arg=0x2001548c


sct calling h=ip_reass_tmr t=0 arg=0x2001548c


tcpip: ip_reass_tmr()


sys_timeout: 0x28213e48 abs_time=16223 handler=ip_reass_tmr arg=0x2001548c


sct calling h=etharp_tmr t=0 arg=0x20015498


tcpip: etharp_tmr()


sys_timeout: 0x28213e68 abs_time=16224 handler=etharp_tmr arg=0x20015498

三.总结

重点理解定时器的超时判断算法,

注意定时器是单次的每次超时处理完都会删除,需要重新创建,这个需要注意,并且注意频繁的创建和删除对堆管理的影响。

了解内建定时器的定时周期的配置,以及定时器的调试方法。

审核编辑 黄宇

打开APP阅读更多精彩内容
声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉

全部0条评论

快来发表一下你的评论吧 !

×
20
完善资料,
赚取积分