昨天搞了一下午的程序，一头雾水，没点思路，今天在软件孙大神的帮助下终于解决这个问题，
是这样的嵌入式设备要和手机做链接，但是为了方便所以把固定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);
此乃罪魁祸首！ 实在是忽略了呀！实时系统！一点想不到就不行啊！坑爹！
|
QQ好友和群
QQ空间
腾讯微博
腾讯朋友
收藏
淘帖
顶
踩
