[lwip-users] Re: another reentrancy question

[shogun]

>
>Message: 3
>Date: Wed, 24 Nov 2010 22:00:51 +0100
>From: "address@hidden" <address@hidden>
>Subject: Re: [lwip-users] Re: another reentrancy question
>To: Mailing list for lwIP users <address@hidden>
>Message-ID: <address@hidden>
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>shogun wrote:
>> Can someone help me understand this better?  I understand that I
shouldn't
>> send and receive from both main and an interrupt at the same time since
the
>> stack is not reentrant.  I want to ask some questions to help me
understand
>> this better, not that this is the way I want to implement the application
>> but I want to better understand this and what I should and shouldn't do.
>> If I am not running an RTOS and I want to run two sockets
>
>Are you sure you mean sockets here? Because at leat the socket API 
>included in the lwIP sources dos not work wihout an OS. In that case, 
>you can only use the raw API.
>

You are correct, I am using the RAW API and when I said "socket", I was
referring to two "sockets" on two different 
ports I used to send and receive data and commands.  Each "socket" is a
listener and will accept connections to send and receive data.

>> for both sending
>> and receiving, can this be done reliably if I use mutual exclusion on all
>> sends and receives?
>
>The general idea of running lwIP wihtout an OS is to do all lwIP-related 
>processing in a main loop (non-ISR context) and to use the ISR only to 
>allocate a pbuf (PBUF_POOL may be allocated from ISR while PBUF_RAM is 
>not supported there!) and copy the received data from the MAC to that 
>pbuf. Then put the received pbuf on a list that you check (and thus 
>process) in the main loop (i.e. non-ISR context). That's the default way 
>to use lwIP without an OS.

Is there a simple example of this somewhere I can look at? I understand
without an OS the sends should only be done in main but I'm still not really
clear on what to do in the callback.   Should the receive callback just
communicate to main via a global / pointer (possibly a 32 bit pointer to the
p->payload in the callback) and the main will see this non null pointer and
get the data then do the following two lines in main then the main can clear
the 32 bit pointer indicating data is processed?

tcp_recved(pcb, p->tot_len);            
pbuf_free(p); 

some sudo code below

globals
char *data[numBufs];

The callback:
static err_t recv_callback (void *arg, struct tcp_pcb *pcb, struct pbuf *p,
err_t err )
{
        char *rq;
        if(p != NULL)
        { 
                Data[free] = p; //free is the next free buffer
                tcp_recved(pcb, data[x] ->tot_len);  //perhaps this goes
here and not main?
                
        }
}

Main:
...

For(x=0; x<numBufs; x++)
{
        If(data[x] != 0)
        {
                Get data, copy to buffer
                tcp_recved(pcb, data[x] ->tot_len);             
                pbuf_free(data[x]);
        }
}
...


>
>If you follow this design, there's nothing more special to watch out for.
>
>Using a global lock does *not* work because you cannot delay an ISR 
>context to let the main loop run first. OK, you *can* achieve locking 
>out RX ISRs when entering the stack by disabling RX interrupts, but 
>that's more tricky and not guaranteed to achieve higher throughput.
>
>Simon
>
>
>
>************
>

I do plan to add an OS to the design but I just wanted to get a better
understanding of this first.  I have the document rawapi.txt that mostly
covers the raw api.  Is there any more documentation on the socket API you
can point me to?   I have looked around on
http://savannah.nongnu.org/projects/lwip/ but haven't found more on the
socket API documentation.

Thanks again for all your help!
DB