各位大神：
    本人在STM32移植了UIP，UIP也可以实现client/server功能了，但是就是太慢，完成一次数据发送大概要180~360ms，满足不了我的需求。
    我的情况是STM32周期性接收485发送过来的数据（用中断处理），存在BUFFER[]数组里，然后通过网口（DM9000AEP）向PC发送BUFFER[]数组。
    其中，实测，485接收数据的时间要是26ms，周期是60ms，也就是STM32中间有34ms的非中断时间。
    而网口的最底层的发送函数实测用76us，相对34ms可忽略不计。由于用了UIP，UIP是用查询方式工作的，从实时性来说不是很好。我不知从接收完485的数据后（即非中断时间）STM32为什么还没向网口发送数据，而要等到180~360ms（最小180ms，最大360ms，中间有240ms，300ms的，都是60ms的倍数）之后才能向网口发数据。
     对了，我接收完一次485数据后会关中断，等到网口发送完这次数据后才再次开中断，从而保证这次接收到的数据的完整性。而主循环没有其他多余功能的函数，实测在无数据接收的情况下，完成一次while(1)循环6.2us。在网口有发送数据时完成一次循环也是6.2us，没变，这个没想明白为什么。
    目前我的需求是接收485的数据，用时26ms，然后立即通过网口向PC转发，用时<1ms，再算上UIP添加IP头的时间，最多10ms怎么都够了，总用时都不会超过40ms。而我的485数据周期是60ms，理论上速度是怎么都够的，可是实际就是网口转发数据是用时在180~360ms，不知为什么会用这么久。
    同时试过检测网口最底层的发送函数，200ms会发送一次数据，很规律。这跟网口转发数据时用时的180~360ms时间不一样，没明白。

    本人对UIP里面的运行机制还不是很熟悉。至于什么时候会调用UIP_AAPCALL()还不是很清楚，还有调用这个函数后，IP头是否已经处理好了…………。还有查询方式是否对需要外部触发（这里指接收完485数据后）的对时间要求有点严格的情况有什么影响，UIP是否有主动发送数据的机制（即485接收完数据，置一标志位，然后主循环通过检查这个标志位，从而判断是否立即发送数据）？
    测试过0.5s的定时器和10s的ARP定时器，都非常准确，更改过0.5s定时器，缩小10倍，即50ms，实际情况跟0.5s没区别，还是速度跟不上。
    试过在主循环检测标志位，然后直接调用UIP_APPCALL()，实际不行，PC端接收不到数据，应该是IP头的问题。
    还试过0.5s定时器的溢出处理函数，跟直接调用UIP_APPCALL()结果一样，没数据出来。

    程序就是速度问题，由于对UIP没有深入的了解，也没时间了解，现在不知怎么调试了，希望各位大神指点迷津。