STM32+UIP速度问题

2019-07-14 23:20发布

各位大神:
    本人在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没有深入的了解,也没时间了解,现在不知怎么调试了,希望各位大神指点迷津。
友情提示: 此问题已得到解决,问题已经关闭,关闭后问题禁止继续编辑,回答。