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

原创嵌入式Lee 2023-09-15 17:50

精密双向电流传感放大器，提供精准测量 【有奖调研】泰克入门级示波器用户调研

一. 前言

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 时间0xFFFFFFFE 即(0xFFFFFFFF-0x00000001)

也可能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位最大范围是0~0xFFFFFFFF，共0x100000000的范围，其一半的范围是0x80000000，即0~0x7fffffff，作为基准，最大就只能定时器该时间，大于该时间认为不合理，实际是绕回反向的。

这里((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

三.总结

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

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

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

登录阅读全文



免责声明：该内容由专栏作者授权发布或作者转载，目的在于传递更多信息，并不代表本网赞同其观点，本站亦不保证或承诺内容真实性等。若内容或图片侵犯您的权益，请及时联系本站删除。侵权投诉联系： nick.zong@aspencore.com！

嵌入式Lee

进入专栏