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

[Luca Ottaviano]

On ven, 2011-05-20 at 10:59 +0200, Simon Goldschmidt wrote:
> Luca Ottaviano <address@hidden> wrote:
> > Hi,
> > I'm having a few issues in porting lwip 1.3.2 on BeRTOS
> > (www.bertos.org).
> 
> If you're doing a new port, I *stronlgy* suggest to use 1.4.0, not 1.3.2, 
> which is outdated.

Yes, I've seen there are a lot of fixes and new features and it's on our
todo list. However the project started a while ago and now I'd like to
finish it as soon as possible.

> > I have implemented my EMAC driver and the low_level_input() functions.
> > I've used BeRTOS facilities to implement the EMAC driver; however,
> > whenever I wait inside the driver timeouts are not processed and so TCP
> > does not retransmit lost packets.
> > 
> > From what I can understand, timeouts are handled only in sys_sem_wait()
> > or sys_mbox_fetch() calls: when a process is going to block on a
> > condition, it starts to process timeouts; if there are none, the process
> > really blocks. Is it correct?
> 
> That's not really true any more (there may still be bugs in 1.3.2 regarding 
> this, I don't remember right now).
> 
> The fixed version of this is that for NO_SYS==0, timeouts are only processed 
> while the tcpip_thread() function waits for a new message, nowhere else!
> 
> 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.
-- 
Luca Ottaviano - address@hidden
Develer S.r.l. - http://www.develer.com/
.hardware .software .innovation
Tel.: +39 055 3986627 - ext.: 218