Re: [lwip-users] Implementing sys_arch on lwip 1.3.2

[Luca Ottaviano]

On ven, 2011-05-20 at 12:07 +0200, Simon Goldschmidt wrote:
> > > From what I understand, you implemented your driver in the tcpip_thread
> > and are blocking on a semaphore. This is not a good idea.
> > 
> > The EMAC driver is plugged into the ethernet thread using
> > low_level_input() and sometimes it blocks waiting for input from the
> > hardware. Such blocks are not handled using sys_sem_wait().
> > The ethernet thread and the tcpip thread only communicate through
> > messages, don't they? In this case I don't think I'm ever blocking the
> > tcpip_thread.
> 
> OK, so if you are not blocking the tcpip_thread, timeouts should not be 
> affected.
> 
> Having your own ethernet thread, you may block on a semaphore as long as you 
> want: timeouts should not be handled from the ethernet thread, only from the 
> tcpip_thread (lwIP timeouts should only be used inside the tcpip_thread, if 
> you need timeouts in other threads, you have to implement them on your own!).
> 
> Then, once the ethernet thread has received a complete packet, pass it to the 
> tcpip_thread using tcpip_input(). 

Ah, maybe that's the misunderstanding; I'm initializing the interface
using:
netif_add(&netif, &ipaddr, &netmask, &gw, NULL, ethernetif_init, ip_input)

So my ethernet thread is calling ip_input() directly instead of
tcpip_input(). That would match what you're saying, since that call
passes messages to the tcpip thread, which in turn processes timeouts.
In my case, instead, calling ip_input() directly means that timeouts are
put in the ethernet thread context, so that's why I need to process
timeouts by hand.

I ran a quick test but the device doesn't even get a dhcp address; I'll
dive a bit more in the problem.

Thanks,
-- 
Luca Ottaviano - address@hidden
Develer S.r.l. - http://www.develer.com/
.hardware .software .innovation
Tel.: +39 055 3986627 - ext.: 218