|
From: | address@hidden |
Subject: | Re: [lwip-users] sys_arch.c timeout of zero problem |
Date: | Tue, 11 Aug 2009 19:29:39 +0200 |
User-agent: | Thunderbird 2.0.0.22 (Macintosh/20090605) |
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 thequeue wait. But I run into problems if the xQueueReceive timeout is 0. The TCPconnection 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 lwIPthread 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 address@hidden http://lists.nongnu.org/mailman/listinfo/lwip-users
[Prev in Thread] | Current Thread | [Next in Thread] |