[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lwip-users] Re: [lwip] porting lwIP for CS8900A with UcosII
From: |
Adam Dunkels |
Subject: |
[lwip-users] Re: [lwip] porting lwIP for CS8900A with UcosII |
Date: |
Wed, 08 Jan 2003 22:53:37 -0000 |
On Tuesday 16 October 2001 17:13, you wrote:
> > Time-outs are functions that are called after a specified amount of time.
> > The time-out functions must not be executed concurrently with the thread
> > which sets the time-out, not can they be called in an interrupt context.
> > There are a couple of ways to implement time-outs and I know of two
> > different approaches.
> >
> > In my lwIP ports (unix and RTXC), time-outs are processes in the
> > sys_mbox_fetch() and sys_sem_wait() functions, since threads can be
> > suspended in those functions. Internally, those functions wait either
> > until the semaphore/mailbox allows the thread to unblock, or until the
> > next time-out should happen. If the thread unblocks because a time-out is
> > scheduled to occur, the corresponding time-out function is called.
>
> If we add a new entry timeout (handled by most of OSes) in the
> sys_mbox_fetch() and sys_sem_wait() functions and the corresponding
> handler(eg : tcp_timer_coarse ) in case of Timeout event, does it works ?
> How do we know the handler to call ?
Time-outs are thread specific. I.e., one thread cannot set a time-out in
another thread. Therefore, no new timeout entries can be set while a thread
is blocked. Time-outs can be set during execution of another time-out
function - when the time-out function returns, the OS emulation layer should
reschedule the time-outs before blocking the thread.
> > If the thread was unblocked because of a message arriving on the mailbox,
> > or because the semaphore was signalled, the time the thread was waiting
> > is subtracted from the time to the next time-out.
>
> Does it mean that if we wait for message arriving on the mailbox for 400 ms
> and the timeout is defined for 500ms, next time we wait that mailbox, the
> timeout will be of 100ms ?
Yes. This must all be implemented in the OS emulation layer (i.e., by you
:-). In the current sources, this is done in the Unix OS emulation layer
(src/arch/unix/sys.c) but not in the RTXC port (src/arch/rtxc/sys_arch.c).
For the Unix port, I used a utlility module called dlist.c that implements a
data structure known as a delta list. Look in the files src/arch/unix/dlist.c
and src/arch/unix/include/arch/dlist.h.
> > The other approach taken to the implementation of time-outs is the one
> > taken by Hongsong Li in his lwIP port to uC/OS 1.09; instead of
> > processing time-outs within the sys_mbox_fetch() and sys_sem_wait()
> > functions, he has a separate thread that schedules the time-outs and at
> > the right time send a message to the mailbox in the lwIP main loop in
> > api/tcpip.c. When this message is received, the time-out function is
> > called within the TCP/IP thread.
>
> This means that in this thread, the time-out function can be called if the
> mailbox is not received on time ? If yes, which one tcp_timer_coarse or
> tcp_timer_fine ?
I'm not quite sure what you mean. Basically, he added another case statement
to the switch in the function tcpip_thread() in the file src/api/tcpip.c.
This case processed a time-out when a special message was posted to the
mailbox from a scheduler thread.
> > For the 0.5 version of lwIP, the time-out scheduling (which is the most
> > complex part of the OS emulation layer) will be moved out of the sys_arch
> > file and into a generic implementation. The sys_sem_wait and
> > sys_mbox_fetch functions will be redesigned so that they take an extra
> > argument which is the maximum time to wait before unblocking and
> > returning to the caller. This will map nicely onto many OSes and will
> > make it easier to port lwIP to other platforms.
>
> I am not that familiar with TCP/IP but I tried to understand this logic ...
> It seems easier to start reprogramming those 2 functions with Timeout
> functionality included but I am not sure of the load of work, and the
> consequence on lwIP code ?
It depends on the kind of support the underlying OS has (in this case,
uC/OS). Look at the Unix OS emulation layer in src/arch/unix/sys.c, that
should give you an idea of the amount of work needed. (The function called
"cond_wait()" contains the time-out scheduling.) Much of the code in the Unix
port can probably be reused.
Hope that clarifies things a bit.
/adam
--
Adam Dunkels <address@hidden>
http://www.sics.se/~adam
[This message was sent through the lwip discussion list.]
- [lwip-users] Re: [lwip] porting lwIP for CS8900A with UcosII, Adam Dunkels, 2003/01/08
- [lwip-users] Re: [lwip] porting lwIP for CS8900A with UcosII, AMARESH, 2003/01/08
- [lwip-users] Re: [lwip] porting lwIP for CS8900A with UcosII, AMARESH, 2003/01/08
- [lwip-users] Re: [lwip] porting lwIP for CS8900A with UcosII, Adam Dunkels, 2003/01/08
- [lwip-users] Re: [lwip] porting lwIP for CS8900A with UcosII, Wolfgang Mües, 2003/01/08
- [lwip-users] Re: [lwip] porting lwIP for CS8900A with UcosII,
Adam Dunkels <=
- [lwip-users] Re: [lwip] porting lwIP for CS8900A with UcosII, Eric Miniere, 2003/01/08
- [lwip-users] Re: [lwip] porting lwIP for CS8900A with UcosII, Wing Kent Kwan, 2003/01/08
- [lwip-users] Re: [lwip] porting lwIP for CS8900A with UcosII, AMARESH, 2003/01/08
- [lwip-users] Re: [lwip] porting lwIP for CS8900A with UcosII, Wing Kent Kwan, 2003/01/09
- [lwip-users] Re: [lwip] porting lwIP for CS8900A with UcosII, Adam Dunkels, 2003/01/09