昨天搞了一下午的程序,一頭霧水,沒點思路,今天在軟件孫大神的幫助下終于解決這個問題,
是這樣的嵌入式設備要和手機做鏈接,但是為了方便所以把固定IP改成DHCP方式,然后流程是這樣的,第一步嵌入式設備上點想DHCP服務器獲取IP地址,然后得到IP地址后啟動UDP廣播,向這個號段內的指定端口廣播一幀數據,手機也在這個網段內,所以收到回復,我獨立開辟一個UDP接受線程接受來自手機端的數據,一旦受到數據立馬開始向這個IP的指定端口做TCP鏈接,完事之后線程掛起開始運行TCP客戶端線程,如果在此時手機主動關閉TCP鏈接,那么嵌入式設備要可以重新發起這個過程,昨天的現象是,A,第一次可以聯機成功,一旦TCP釋放之后無法聯接,UDP所有的廣播都是正常的,然后用網絡調試助手流程都通,沒有一點問題,手機軟件方面也是所有問題都通,一旦和嵌入式設備鏈接就不行,原來是這樣的:
只說主要的,其他線程不予考慮。。
系統初始化的時候創建了2個主線程,一個用來初始化網口和上層棧,一個用來接收UDP數據,即A線程B線程,A線程優先級最搞,B線程次之, 然后A線程初始化完畢之后啟動DHCP,得到IP地址就開始向此號段盡享廣播,就是在這個廣播中出錯了,在廣播完畢之后我進行了線程睡眠,正事這個線程睡眠使得系統掛起這個線程,但是此時這個UDP端口沒有注銷,然后轉而執行B線程,創建好了UDP另一個端口,就在此時A線程睡眠完畢,毫不猶豫的搶了B線程的CPU時間片,導致B線程還沒有完全的執行完畢,就被搶走了,如果此時來一個UDP包從手機發來就會導致UDP線程收不到,因為此時CPU正在A線程處執行關閉端口程序呢,UDP收不到就導致TCP無法啟動,那么為什么用網絡調試助手可以呢?因為網絡調試助手是手動的,非常慢,等你發的時候A線程早已經結束了關閉端口命令,而且B線程也得到了足夠的時間執行也堵塞在一個郵箱上,所以再來UDP數據是可以收到的,反之,手機回復速度小于線程睡眠時間,導致A線程搶占B線程,以至于有此事,去掉這個縣城睡眠,等待A線程老老實實執行完畢,就好了!哈哈!
sendto(sock, send_data, strlen(send_data), 0,
(struct sockaddr *)&server_addr, sizeof(struct
sockaddr));
thread_delay(50);
close(sock);
此乃罪魁禍首! 實在是忽略了呀!實時系統!一點想不到就不行啊!坑爹!
|