Re: [lwip-users] Re: LWIP 1.3.0 RC1 - Starting work with this release - QUESTIONS

[Jonathan Larmour]

Piero 74 wrote:
> No answers? :O(

http://lists.gnu.org/archive/html/lwip-users/2008-02/index.html
confirms that your mail never arrived.

> 2008/2/1, Piero 74 <address@hidden <mailto:address@hidden>>:
>
>     Hi all.
>
>     I'm starting work using lwip 1.3.0 rc1, but i want to clarify some
>     issues:
>
>     1. Can i consider 1.3.0 rc1 more stable than 1.2.0 (or... can i
>     suppose less bugs in 1.3.0. RC1)? or i have to wait final release?

Bugs have been fixed. Have more bugs been created? Who knows :-). If we 
knew, we'd fix them ;).

>     2. i wrote a new driver for my microcontroller emac. I'm integrating
>     it in the stack. After a discussion with other developer 
>     (Jonathan),  i'm thinking  to  call inside irq function
>     tcpip_input()  pbuf , because i can use a thread safety function for
>     mailbox inside irq (available in freertos). Is it possible to use
>     REFERENCE pbufs pointing to driver ram buffer instead copy from ?

Typically in such cases, the driver ram buffer is finite and small, in 
which case that would be a bad idea - you don't know how long it will be 
before that pbuf is freed. Even if your application consumes data quickly, 
there are some cases where it may be a while.

> i
>     have to use sequential api (socket or netconn), so, in the driver i
>     will have to know how packet pbuf could be released, to reuse ram in
>     the driver for other packet from Ethernet. Is there a callback
>     function which i can use? So ... in other word... if i allocate a
>     pbuf chain of pbufs from the pool INSIDE the driver, how i can know
>     WHEN this chain will deallocate?

There is no current way to do that. I have done something similar (for a 
slightly different reason) in my own driver by adding a hook to pbuf.c, 
but there's nothing official for now. It's something we're going to be 
looking at after 1.3.0.

>     3. in lwip 130rc1 i have to call tcpinit for all initializations,
>     passing callback function for init_done. where do i do netif
>     initialization?? before tcpinit call using netif_add OR after using
>     netifapi_netif_add??

To be safe, only use netif_add in the context of the tcpip thread (which 
the callback function is called from). Otherwise use netifapi_netif_api().

>     4. i want to understand how use dhcp... i have to set option and
>     call dhcp_start... and nothing else ? if i don't use dhcp, after the
>     netifapi_netif_add i have to call netif_setup, right?

Look at the ports in the contrib/ module. I don't know what option you 
think you need to set? (Unless you just mean LWIP_DHCP in lwipopts.h).

Be warned, you need to use netifapi_netif_set_up if it isn't in the tcpip 
thread init done callback function (instead of netif_set_up).

>     5. for security reason, i need that ALL threads in my application
>     doesn't block indefinitely, and signal a supervisor thread with
>     alive message. Tcp_ip thread block indefinitely? How i can call a
>     custom function every N ms inside Tcp_ip? i'm thinking to do some
>     check in sys_arch_timeout, because tcpip_thread call sys_mbox_fetch
>     and after this function, and inside i can know the owner thread
>     id... so, i can send keep alive message to supervisor... but this
>     idea works only if Tcp_ip thread doesn't block indefinitely. Can
>     anyone clarify me?

It can block indefinitely on sys_mbox_fetch(), but as it appears you have 
worked out, sys_mbox_fetch() uses the timeout mechanism so it would never 
block longer than that time. There should be nothing else the tcpip_thread 
blocks on (unless you have a bug :-)).

>     6. i need to do periodic operation, only for checking lan
>     connection, can i use sys_timeout()? in this way, lwip stack will do
>     this call for me, right?? 

You can use sys_timeout, or your own OS's timeouts, whichever. It hardly 
matters, although it's likely using your native API will be smaller and 
faster.

> OR, lwip stack has a callback function for
>     checking  link status? i didn't see it in ethernetif.c....

The driver can set the link up or down. lwIP does not poll the driver to 
determine link status. ethernetif.c doesn't implement everything that 
exists. It's up to you how to detect the link going up and down - some 
PHYs have an interrupt, some you may want to poll. In many cases, people 
don't care :).

You can also use LWIP_NETIF_LINK_CALLBACK in lwipopts.h to get a user 
callback.

Jifl
--
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["The best things in life aren't things."]------      Opinions==mine