lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] almost there.... need some assistance with callbacks...


From: Christiaan Simons
Subject: Re: [lwip-users] almost there.... need some assistance with callbacks... etc..
Date: Thu, 16 Sep 2004 11:45:10 +0200

On Thu, 2004-09-16 at 03:16, Eric Shufro wrote:
> How should the lwip dhcp timers and arp timer as well as others be
> initialized?
> 
> I understand from earlier postings that they cannot be called from different
> threads. So how is that done then? I cant suspend the tcpip thread for an
> OSTimeDelay() amount of time.... So any help there would be great.
> 

Many RTOSes (like uCOS) provide a way to call initialisation
code before any task switching (and interrupts) occurs.
(before OSStart())

If you keep all lwip code in one task there is no problem at all.

> Also, as far as Ethernet drivers go, when an interrupt occurs, the ISR
> should disable interrupts, post a semaphore and exit right? - the work
> should be done in a separate task?

The ISR should mask its own source only I guess.
Its a good idea to put all ethernet processing
in a task and pend for a small (and fast) interrupt handler.

Simply put _all_ lwip background functions like
the driver, arp / dhcp / tcp timers in one task,
and use a semaphore or mutex to give application
tasks access to the stack (PCB or other socket access).
You can unmask the ISR in this task after a succesfull
pend on the Ethernet semaphore.

> 
> So should I create a separate task in the OS that simply has a while loop to
> service the cs8900 interrupt service queue (ISQ) but pends for the semaphore
> before doing it, and when the interrupt occurs, wakes up due to the posted
> semaphore?

Beware! Handle the ISQ with care. Since you use an RTOS everything
should work just fine in this case. You should note that the
cs8900 can keep your task extremely busy on heavy network loads! 

> 
> Does that make any concurrency problems, since its yet another thread?

If you protect the lwip code with a semaphore or a mutex
it should work just fine. I would recommend the solution
above (one task for lwIP) for its simplicity.

Bye,

Christiaan Simons




The information contained in this communication is confidential and is intended 
solely for the use of the individual or entity to whom it is addressed. Axon 
Digital Design Group is neither liable for the proper nor for the complete 
transmission of the information contained in this communication nor for any 
delay in its receipt. Axon Digital Design Group does not guarantee that the 
integrity of this communication has been maintained nor that the communication 
is free of viruses, interceptions or interference. If you are not the intended 
recipient of this communication, you are hereby notified that reading, 
disseminating, distributing or copying this message is strictly prohibited. In 
that case please return the communication to the sender and delete and destroy 
all copies. In carrying out its engagements, Axon Digital Design Group applies 
general terms and conditions, which contain a clause that limits its liability. 
A copy of these terms and conditions is available on request free of charge.







reply via email to

[Prev in Thread] Current Thread [Next in Thread]