RE: [lwip-users] Installed the new version, since all thechangesand turned on the ASSERT debug

[Joolz [RSD]]

-----Original Message-----
From: Kieran Mansley [mailto:address@hidden 
Sent: 20 March 2007 14:20
To: Mailing list for lwIP users
Subject: RE: [lwip-users] Installed the new version, since all
thechangesand turned on the ASSERT debug

On Tue, 2007-03-20 at 13:44 +0000, Joolz [RSD] wrote:
>  
> -----Original Message-----
> From: Kieran Mansley [mailto:address@hidden
> Sent: 20 March 2007 13:18
> To: Mailing list for lwIP users
> Subject: Re: [lwip-users] Installed the new version, since all the 
> changesand turned on the ASSERT debug
> 
> On Tue, 2007-03-20 at 11:22 +0000, Joolz [RSD] wrote:
> > My code now stops with the following message.
> > 
> > Asserion p->flags==PBUF_FLAG_RAM || p->flags==PBUF_FLAG_POOL failed 
> > at
> 
> > line 487 in lwip2/src/core/pbuf.c
> > 
> > Now in my code what I do is the following
> > 
> > ...
> > Struct pbuf *data;
> > Unsigned char *tempBuffer;
> > 
> >     data = pbuf_alloc( PBUF_RAW, PAYLOAD_SIZE, PBUF_ROM);
> >     tempBuffer = pvMalloc( PAYLOAD_SIZE); // Allocate my buffer from
> my
> > memory
> > 
> > Now further in the code I need to fill a buffer from a circular 
> > buffer
> 
> > and if the data does not wrap around I do the following
> > 
> >     data->payload = currentBufferAddress;
> >     udp_send( outUdp, data);
> > 
> > If the buffer will wrap around I copy the two parts into the temp 
> > buffer allocated at the start
> >     memcpy( tempBuffer, curren....
> >     memcpy( tempBuffer+whatsLeft, ....
> >     data->payload = tempBuffer;
> >     udp_send( outUdp, data);
> 
> As an aside you could avoid this copy by just calling udp_send twice, 
> once for each fragment.
> 
> > So what is the best way because I don't want to copy the data when I

> > do not need to.
> 
> >>The problem is that lwIP needs to stick a UDP and IP header on the
> front of the pbuf payload, and for a ROM type of pbuf it can't do 
> this, as it has no
> >>knowledge of what is in memory before the pointer provided.  In your
> case for example, there is a good chance that it would overwrite 
> another packet if it
> >>tried to use that space.
> 
> >>If you could arrange for there to be space in front of each fragment
> you pass to udp_send() to store the pbuf structure, ethernet, IP and 
> UDP headers, then
> >>you could create your own PBUF_RAM pbuf rather than allocate a
> PBUF_ROM pbuf and set the payload as you do above.  Then it should all

> work fine.
> >>However, if you're transferring from a circular buffer then you'll
> have a problem doing that I think, and so you're probably going to 
> have to take the hit of a
> >>copy.
> >>
> >>Kieran
> 
> I tried the 2 * udp_sends and some receiver boxes don't like it, they 
> seem to need the the buffer being sent at the correct size (7*188).

Of course - I forget that UDP has that property of single send/recv per
packet.

> So I can build a buffer and copy the from the circular buffer every 
> time, ive got no dma so it would be a software copy. SLOW
> 
> My circular buffer is 512K so if I can do it the same way I would only

> have to copy 1 out of every 400 buffers, that's a large saving in 
> cycles.

>>You can do it the same way, but only if you control whatever puts data
into the circular buffer.  If you can modify that to leave gaps (that
will later be used 
>> for the network headers) between the fragments then you can just cast
each region of the circular buffer to a "struct pbuf", fix up the
entries in this new 
>> pbuf structure, and send it.  You'll need a little bit of protection
to prevent bits of the circular buffer being reused before they've
actually reached the network 
>>(but you need that in your current scheme).
>>
>>I wonder if there's another way: do we allow different types of pbufs
to be chained together?  If so, you could have a pbuf RAM pbuf that you
create using 
>>pbuf_alloc that is used for the headers, and then chain on your ROM
payload pbuf.  Might work.  Not sure.  Worth a look.
>>
>>Kieran 

Cant do anything about the circular buffer as its hardware controlled
and all I get back is the read/write pointers.

I think if I can make a chain with the last one the PBUF_ROM type would
work well.

Tried this

...
struct pbuf             *data;
struct pbuf             *aaaa;

        data = pbuf_alloc( PBUF_RAW, 0, PBUF_RAM);
        aaaa = pbuf_alloc( PBUF_RAW, PAYLOAD_SIZE, PBUF_ROM);
        aaaa->payload = pvMalloc( PAYLOAD_SIZE);
        pbuf_chain( data, aaaa);
        outUdp = udp_new();
        outAddr.addr = htonl( e2Prom.channelSettings.ipAddress);
        udp_bind( outUdp, IP_ADDR_ANY, e2Prom.ethernetSettings.port);
        udp_connect( outUdp, &outAddr, e2Prom.channelSettings.port);
        udp_send( outUdp, data);

Does not work, different error in pbuf.c line 490

Is it possible for one of you pbuf gurus to add in to the pbuf_header
code that sees that the header is a ROM and chains a new pbuf before.