HiIf can help, i attached my sys_arch for freertos running above lpc2366 microcontroller.
Bye Piero 2008/9/8 [EMAIL PROTECTED] <[EMAIL PROTECTED]> > Nick Thomas wrote: > >> Nick, could you tell us which version of lwIP you are using? I think I >>> remember the calls to sys_mbox_fetch in api_lib.c being changed to >>> sys_arch_mbox_fetch in 1.3.0, so you might be using an old, pre-1.3.0 >>> version? >>> >>> >> Hi, this is a version for OS20, for ST chips. I don't know what version it >> is - I just inheritted it. >> >> > Too bad. But if you want to use it in a production environment, I'd > strongly suggest to update to the latest version possible! (which currently > would be 1.3.0, unless you want to use CVS head). > >> As to the actual problem: your port must have something seriously messed >>> up: I could imagine either sys_arch_timeouts() returning the same struct >>> sys_timeouts* for all tasks (which is an error!) or your system time >>> (used in sys_arch_mbox_fetch) is somehow calculated wrong... (the return >>> value of sys_arch_mbox_fetch should indicate how long you have been >>> waiting). I suspect the first, though. >>> >>> >> >> I think the first, I found this sys_arch.c: >> [...] >> This looks like the smoking gun. >> >> > Yep, defenitley wrong :-) > >> Looks like I have quite a lot of work to do :( >> >> > Not at all that much: if you want, you can copy the code from CVS: the > win32 port does just the same - it has an array of task structs; each entry > holds the thread ID (or handle or whatever you can use to detect the > currently running thread). You then loop through this array until the ID > matches and return the struct sys_timeouts of the matching array entry: take > a look at > http://cvs.savannah.gnu.org/viewvc/contrib/ports/win32/sys_arch.c?revision=1.8&root=lwip&view=markup > >> However, the 'fix' you suggested is NOT a good solution since this could >>> lead to a deadlock: image one thread is waiting on the receive-mbox of a >>> netconn (which waits forever): tcpip_thread would block forever and >>> couldn't process new packets! You really should check the two things >>> described above! >>> >>> >> I didn't sugggest a 'fix' fix at all. >> > Sorry, just quoting your mail: > > So, this fix causes more problems than it fixes! > > Just so you know: apart from calling raw API functions, this is one of the > things users/porters do wrong most often (even though it is documented :) > > Simon > > > > _______________________________________________ > lwip-users mailing list > [email protected] > http://lists.nongnu.org/mailman/listinfo/lwip-users >
sys_arch.c
Description: Binary data
_______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
