[lwip-users] RE: Re: Driver interface related question

[Taranowski, Thomas (SWCOE)]

You want the SYS_LIGHTWEIGHT_PROT defined to 1 for your system.

I'm not sure what method is currently being advocated for posting the
received packet to the mailbox, so I'll defer on that count.  My current
OS is a hard real-time system that allows me to perform blocking actions
(e.g. post to a mailbox, or wait on a semaphore) in interrupt handlers
in a safe way, so I haven't wrestled with that problem, yet.

> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden
On
> Behalf Of KATZIR SHAY
> Sent: Friday, October 19, 2007 7:41 AM
> To: address@hidden
> Subject: RE: Re: Driver interface related question
> 
> 
> Hello,
> 
> I'm using the 1.2.0 version of lwip without cvs changes.
> I ported the package by creating the sys_arch functions as requested,
but
> didn't use the SYS_LIGHTWEIGHT_PROT.
> 
> As i wrote in my previous e-mail, i have a multithread system and i
use
> interrupt for receiveing packets. I read in previous disscussions (bug
in
> PBUF) that it is unsafe to use the pbuf from the interrupt, but i have
no
> choice and i'm trying to get it to work.
> after failing to manage without SYS_LIGHTWEIGHT_PROT (the program got
> stuck quickly) i wrote the sys_protect funcs, and changed the macro to
one
> but it got worse, and kept giving debug messages of "out of memory" on
> memp "TCP_MSG" and pbufs.
> 
> can anyone explain me which method should i use for using this package
in
> a multithreaded system? and how can i use the receiving interrupt to
enter
> a packet to the tcpip mailbox, without blocking the interrupt.
> 
> thanks,
> shai
> 
> 
> Subject: Re: [lwip-users] Driver interface related question
> To: "Mailing list for lwIP users" <address@hidden>
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Driver interface related question----- Original Message -----
>   From: KATZIR SHAY
>   To: address@hidden
>   Sent: Wednesday, October 17, 2007 11:43 AM
>   Subject: [lwip-users] Driver interface related question
> 
> 
>   Hi,
> 
>   In order to write an interface for my ethernet driver,
>   I used the ethernetif.c and etharp.c, given in the lwip package.
> 
>   1. because my driver api function for Send, writes the data
immediately
> to the register, I had to send the Packet in one buffer, and not each
pbuf
> in the chain separately. Therefore, I created in low_level_output a
new
> pbuf which collects the pbufs in the chain into single pbuf chain, and
> then send to the driver the new pbuf, and release him by pbuf_free.
> 
>   Can it cause any problem? Can it encounter a separate call for
> pbuf_free()?
> 
> No, I don't think
> 
>   2. After managing to create the driver interface, and to port the
lwip
> into my system by writing sys_arch of my own. It can now communicate
with
> other computers, but
>      after running for few seconds, it get stuck in an endless loop,
> usually in the mbox_fetch of the tcpip_thread, even though the driver
> keeps on getting packets.
> 
>      I made a lot of tests, and in each test it got stuck in a
different
> phase of the program.
> 
> Most of time, it's a port problem. What lwIP release do you use?
> 
>      I believe it enters some sort of race condition.
>     My main worry is about the interrupt of the driver which handles
the
> receive.
>     This Interrupt calls the callback function - 'ethernetif' and pass
the
> data to him. When the Packet enters the function, it gets processed as
an
> IP Packet or an ARP Packet. In both cases, the function uses
semaphores
> (memp sem and pbuf_pool_free sem), which can easily create a block to
the
> program (because those sems are occupied by the application or the
tcpip
> thread) .
>   Is there a way of handling the input packet without using any
> semaphores? What is the common implementation for the input callback
of
> the driver?
> 
> Take a look to http://lists.nongnu.org/archive/html/lwip-users/2007-
> 09/msg00097.html, there is some informations from Jonathan about a
Zero
> Copy Ethernet interface. Perhaps it can give you some ideas?
> 
>   Can you see any other solution for my problem?
> 
>   Thanks,
> 
>   Shai.
> 
>