設置 | 登錄 | 註冊

作者共發了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許可協議進行許可。