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

[Adam Dunkels]

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.]