設置 | 登錄 | 註冊

目前共有5篇帖子。

本来dhcp_fine_tmr函数该500毫秒就执行一次的

1樓 巨大八爪鱼 2017-4-5 20:16

然而sys_check_timeouts函数却一直没有自动调用dhcp_fine_tmr
非要等到周期为1分钟的dhcp_coarse_tmr函数执行了之后才开始执行dhcp_fine_tmr函数

导致DHCP迟迟不能分配到IP地址

开机后要经过一两分钟才能获得IP地址

2樓 巨大八爪鱼 2017-4-5 20:17
从下面的串口输出结果可以看到,dhcp_fine_tmr函数的执行频率非常低!
DHCP分配状态码: 6
dhcp_fine_tmr执行了!
dhcp_fine_tmr执行了!
dhcp_fine_tmr执行了!
dhcp_fine_tmr执行了!
dhcp_fine_tmr执行了!
DHCP分配状态码: 1
DHCP分配状态码: 8
dhcp_fine_tmr执行了!
dhcp_fine_tmr执行了!
DHCP分配晒Γ?
IP地址: 192.168.1.116
子网掩码: 255.255.255.0
网关: 192.168.1.1
DNS服务器: 192.168.1.1
Not in cache! err=-5
DNS Found IP: 106.186.126.193
dhcp_fine_tmr执行了!
dhcp_fine_tmr执行了!
dhcp_fine_tmr执行了!
dhcp_fine_tmr执行了!
dhcp_fine_tmr执行了!
dhcp_fine_tmr执行了!
3樓 巨大八爪鱼 2017-4-5 20:58
在主循环里面加延时,延时100ms,问题就解决了。
sys_check_timeouts函数的执行频率不能太高!
4樓 巨大八爪鱼 2017-4-5 22:47

【解决方案】
// ★sys_check_timeouts函数千万不能调用的太频繁, 否则会出错!(后果就是开机后要等1~2分钟DHCP才能分配到IP地址)
if ((uint16_t)(TIM1->CNT - last_check) >= 200) // 如果距离上次检测超过200*0.5ms=100ms
{
    last_check = TIM1->CNT;
    sys_check_timeouts(); // 则再检测一次
    // 当TIM1->CNT < last_check时也能正常判断, 因为两者都是无符号数
    // 比如12-9985的结果是55563, 这相当于计算65536+(12-9985)
}

5樓 巨大八爪鱼 2024-2-29 07:04
以上结论均是错误的。真正的原因是,sys_now函数的实现有问题,后调用的返回值比先调用的返回值还小,解决了这个问题,sys_check_timeouts就能直接放在while (1)里面了。
楼上说的此函数不能调用得太频繁,恰好是因为避开了后调用值比先调用值小的情况,所以才不会出问题,并没有找出根本原因。

內容轉換:

回覆帖子
內容:
用戶名: 您目前是匿名發表。
驗證碼:
看不清?換一張
©2010-2025 Purasbar Ver3.0 [手機版] [桌面版]
除非另有聲明,本站採用知識共享署名-相同方式共享 3.0 Unported許可協議進行許可。