lwIP should not have any problems with a timeout of zero. However,
converting timeout valus inside the function sys_arch_mbox_fetch() (like
you did) is not supported and will confuse the stack. This is because of
the way the stack handles timers: it keeps the time until the next timer
expires (in miliseconds) and substracts the time sys_arch_mbox_fetch()
needed from that time. When zero, the timeout gets called.
There are two possibilities here:
a) the function returns a valid mbox message, in this case it shall
return the time (in miliseconds) it needed until the message was
received, zero if received immediately or
b) the function returns SYS_ARCH_TIMEOUT if timeout is !=0 and no
message has been received in that time; in this case the time needed is
supposed to be the value of timeout passed to the function.
Now you can easily see that returning SYS_ARCH_TIMEOUT after 0
miliseconds instead of 10 miliseconds will lead to problems as the stack
thinks 10 ms have passed but in reality, 0 ms have passed. Because of
that, timers get called much too frequently and this may lead to
detecting connection errors where there aren't any.
If you are using lwIP 1.3.0 or newer (CVS), to achieve what you want,
have a look into the netconn_recv() function: when you have
LWIP_SO_RCVTIMEO defined to 1, sys_arch_mbox_fetch() gets called with a
timeout defined in the netconn (conn->recv_timeout), an int which you
can set to whatever you want, e.g. set it to -1 and let
sys_arch_mbox_fetch() return immediately if timeout is -1.
If you are using lwIP 1.2.0 or before, I don't know a decent solution.
BTW: The above timeout implementation is not ideal and subject to change
in lwIP 1.4.0. With the intended solution (having a function like
get_time()), your approach would have worked ;-)
Simon
David Shmelzer wrote:
My application requires that netconn_recv() be non-blocking and to
return immediately of there is no message waiting.
So I modified sys_arch.c to convert small timeout values to zero for the
queue wait.
But I run into problems if the xQueueReceive timeout is 0. The TCP
connection closes after ~5 netconn_recv calls. Everything works fine if
the xQueueReceive blocks for at least 1 tick.
Does the lwIP architecture REQUIRE that netconn_recv allow the lwIP
thread to run?
Is there a reason that it was designed such that a timeout of 0 means
wait forever instead of peek?
Here's my modification to sys_arch.c:
u32_t sys_arch_mbox_fetch(sys_mbox_t mbox, void **msg, u32_t timeout)
{
...
if ( timeout != 0 )
{
timeout >>= 2; <<<<<---- added this line which converts
timeout in ms to ticks
if ( pdTRUE == xQueueReceive( mbox, &(*msg), timeout ) )
...
Thanks
-Dave
_______________________________________________
lwip-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/lwip-users
