操作系统和uip协议栈的接口

    这其实也是水到渠成的事，因为UIP协议栈是不需要操作系统支持的，也就是说他可以裸奔，可以覆盖在系统上面，怎么样裁减都是可以的，然而，lwip却不行，第一LWIP的所有数据区都要先分先用，也就是说要给LWIP提供动态分配内存的所有接口和封装函数，第二，LWIP是消息机制，如果裸奔就需要用户构建一套消息机制，然而娱乐操作系统这一切就变得似乎简单了，线程间的通信都可以依靠操作系统提供的时间接口，UIP就不同了，他不需要动态分配内存，他的缓存是静态的，所以搞起来就一点要考虑，那么就是把消息机制融合到UIP和OS之间的接口中就可以了，我只这样搞的，
1：建立三个线程，最高优先级的处理IP数据报文，次高优先级的作为轮训底层驱动的接口使用，肩带这轮训ARP映射表和维护连接，最低优先级无事可做，所以就肩带的做个定时器用吧，他更新ARP的轮训时间值，这样就完整了！我测试结果还是很好的，但是这样的系统绝对比不上裸奔来的实时，哈哈这个很可笑，是啊操作系统不是万能的，他需要时间调度，需要时间去传递接收，需要时间压栈出栈，这都是CPU的时间！但是总体来说，操作系统使下层和上层之间的应用变得 简单明了，所以，如果你的内存足够大，那么兄弟上系统吧，当然再完美的东西也有缺憾，UIP的UDP功能很是牵强啊！功能也比LWIP弱很多，所以，总得找机会吧LWIP搞搞，继续吧，谁知道呢？

本人于下午一下午时间移植了一个UIP，修改后，好用了，由于内存不足，所以吧内部的静态存储区改成100个字节，这样对于ram的消耗会大大的降低，满足我的硬件系统要求，我运行试过了，我的RAM只有4096程序我正好控制在4016字节，正好可以跑起来，ICMP报文正常，TCP连接正常，数据也是正确的！哈哈，好高兴！下一步芯片来了之后，开始加入操作系统，那就是小菜一碟了！嘿嘿
oid tcp_wangjunwei_appcall()//我自己的TCP端口
{
   if (uip_closed())
{
// USART_OUT(USART1,"uip_closed!\r\n");
  closed();
}
  if (uip_connected())
{
  
struct tcp_demo_appstate *s = (struct tcp_demo_appstate *)&uip_conn->appstate;
s->state = STATE_CMD;              //指令状态
s->textlen = 0;
s->textptr = "连接到王均伟的TCP端口上，哈哈哈！扫噶！";
s->textlen = strlen((char *)s->textptr);
   senddata();
  
}
if (uip_acked())
{
  acked();
}

   if (uip_rexmit() || uip_newdata() || uip_acked() || uip_connected() || uip_poll())
{
  struct tcp_demo_appstate *s = (struct tcp_demo_appstate *)&uip_conn->appstate;
    s->textptr = uip_appdata;    /* 向客户端发送收到的数据 */
   s->textlen = uip_len;
  senddata();
}




}

  昨天开始搞LWIP的移植，但是不会走怎么跑啊？所以一直在看源码，终于今晚上突破了LWIP和系统的接口问题，我看着是这样的：
首先操作系统创建两个线程，两个线程里面设置连个堵塞邮箱，一个线程专门接收数据，一个线程专门发送数据，当外部的网络驱动芯片接收到数据包，那么他就发送一个指针到邮箱中，这时候操作系统轮训到这个邮箱中的数据，就进入处理，其实他也没处理，他就是把这个得到的指针放到LWIP栈中去了，让LWIP的内核处理，另一条是发送，当LWIP要发送数据，就向发送邮箱发送一条邮箱指针，然后被挂起的发送线程被激活，调用底层发送程序发送出去 ，发送完毕马上挂起再次等待下一次的数据发送，所以这样就找到了数据收发的接口，这个显然是操作系统和LWIP和底层硬件之间的数据交换，也就是说LWIP确实是建立在操作系统之上的！他无权操作底层硬件，要通过操作系统的这两个堵塞线程来实现数据的收发！哎呀，这才是万里冰山的一个小脚，还有很多问题没有解决！比如数据怎么被放到地层中的？地层中的数据怎么何时被放到数据结构中？这就写LWIP分装的都非常的严实，以至于找到他的驱动很难很难！继续加油吧！