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

[AMARESH]

hi all,

At present I am trying to compile Lwip 0.4.1 from UcosII,

My purpose is to

1. Make a stack for 8051 based microcontrollers  and drive a CS8900A
ethernet controller

2. Then integrate the 8051 and CS8900A in to a single bundle..

Is there anybody who is doing any thiing similar .. if so please share some
of your thought ..to help me out

Cheers to all


Amaresh Ballolli,
Project Leader
Radiant Infosystems (P). Ltd.,
Bangalore-560070
INDIA
+91-80-6763316,7702 Ext: 120
----- 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.]