[lwip-users] Re: [lwip] porting lwIP for CS8900A with UcosII

[AMARESH]

hi,

sorry attchement was accidental..

and hey the latest posting is very much informative and ellaborate .. thanks
and
request your contribution in coming days

btw have u made any design document or so.. for this LWIP.. I am making one
now so that I can comprehend the details from a perspective.. but its
consuming time and very much eager to proceed further

TIA

Amaresh Ballolli,

----- Original Message -----
From: "Adam Dunkels" <address@hidden>
To: <address@hidden>
Sent: Monday, October 15, 2001 8:25 PM
Subject: Re: [lwip] porting lwIP for CS8900A with UcosII


> On Monday 15 October 2001 13:26, you wrote:
> >>   I am investigating the needs for running the lwIP TCP/IP stack with
the
> >> CS8900A driver and the OS ucosii. I know that lwIP has been used with
the
> >> CS8900A Ethernet driver. If I can have information about this port ?.
About
> >> UCOSII, I have to complete the generic interface function (sys_arch.c)
but
> >> I am not sure about the functionnality for certain function. I have
> >> problems downloading the thesis (PDF) ....
> >
> > I cant help u much in your first question
> > however I am attaching the PDF file which I had downloaded from SICS..
>
> Ouch! Please don't post such big attachments to the list - there may be
those
> who read the list over a slow modem connection. That attachment could very
> well take a few minutes to download on a slow modem.
>
> As for the original question, I have been adding some stuff that has been
> laying around for a while to the main lwIP code tree. This includes a BSD
> socket library and a CS8900A driver. The driver has been run under RTXC on
a
> Mitsubishi M16c CPU. When I have verified that the CS8900A driver works, I
> plan to release a 0.4.2 version that includes not only this driver and the
> BSD socket library, but also a few bugfixes, ARP support and the Ethernet
> driver skeleton that was announced on saturday.
>
> Ideally, when porting lwIP only the OS emulation layer (sys_arch.c) and
the
> include files under arch/<arch>/include/arch has to be changed. The OS
> emulation layer is fairly complex and I have plans to modify the design
for
> the 0.5 version in order to provide for easier portability.
>
> The OS emulation layer supports the following functionality:
>
> * semaphores
> * mailboxes
> * time-outs
>
> Semaphores are (at least) binary semaphores thet support four operations:
> sys_sem_new(), sys_sem_free(), sys_sem_signal(), and sys_sem_wait().
> Mailboxes are messages queues that transfers a pointer to a message
between
> threads. Mailboxes support four operations: sys_mbox_new(),
sys_mbox_free(),
> sys_mbox_post(), and sys_mbox_fetch(). If a message is posted to a mailbox
> that alread contains a message, the second message is queued.
>
> 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 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.
>
> Even though time-outs are measured in microseconds, in the current lwIP
code
> it is not terribly important that they occur at the very right time.
> Currently, time-outs are used only by the TCP code.
>
> 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.
>
> 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.
>
> /adam
> --
> Adam Dunkels <address@hidden>
> http://www.sics.se/~adam
> [This message was sent through the lwip discussion list.]

[This message was sent through the lwip discussion list.]