[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] Problem with CS8900 driver

From: address@hidden
Subject: Re: [lwip-users] Problem with CS8900 driver
Date: Wed, 13 Jan 2010 16:31:18 +0100
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; de; rv: Gecko/20091204 Thunderbird/3.0

Bernhard 'Gustl' Bauer wrote:

I'm using LWIP 1.3.0 with the modified CS8900 driver coming with contrib.
First of all, I think the one in CVS might be outdated since it is not maintained any more (which is why it has been moved to the 'old' subdirectory). Please have a look at the driver linked on http://lwip.wikia.com/wiki/Available_device_drivers (submitted by an lwIP user), as that might be better.
The transfer from CS8900 to RAM buffer is done by DMA and works fine so
far. Then cs8900_input() does a pbuf_alloc() and copies 1 packet from
DMA buffer to pbuf.

But what if pbuf_alloc() fails? If I drop this packet I might get
problems with HTTP handshake. If I try again next time cs8900_service()
is called I will run into the same problem. Neither cs8900_input() nor
cs8900if_input() does anything without pbuf. There must be a pbuf_free
before a pbuf_alloc is successful.

How do I do this the right way?
If you are running out of pbufs, the packet will be dropped. Since HTTP uses TCP, it will eventually be retransmitted. If, at that point, you are still out of pbufs, chances are that you configured the number of pbufs too low.

Generally, PBUF_POOL pbufs shall only be used for RX while TX uses _REF, _ROM or _RAM pbufs. Incoming pbufs are only buffer a) by your application or b) by the TCP_QUEUE_OOSEQ code.

If you disable TCP_QUEUE_OOSEQ, the only reason pbuf_alloc(PBUF_POOL) fails in the driver is that packets are coming in faster than your device can handle them.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]