Re: [lwip-users] LWIP Raw API receive issue

[M S ARUL]

Hello Sergio,

    Sorry for the delay. 

    Yes the issue is with the pbuf chain. It is resolved now as I copy the data from single pbuf at a time then moving on to the next pbuf to copy and so on. 

    Thanks a lot for all your inputs and the time.

Best Regards,

ARUL PRAKASH M

On Sat, Jan 13, 2018 at 3:19 AM, Sergio R. Caprile <address@hidden> wrote:

>> You are _SENDING_ 512 but you are receiving "upto" 200, what does that mean ???
> That means p->tot_len is 512 or the exact no of bytes I have
> transmitted.

When receiving an Ethernet frame, the driver allocs from a memory pool (PBUF_POOL) and it might be a chain of blocks of memory
When sending via TCP, it allocs from a different memory pool (unless you instruct to not copy and reference the source, it will alloc from PBUF_RAM) and although this might change in the future, it is a contiguous block of memory.
And you don't handle pbufs when sending via TCP, which you do on reception.

>>They might be chained, you can't memcpy(somewhere, p, p->tot_len), you
>>need to go pbuf by pbuf copying p->len and checking p->next until you
>>extract tot_len bytes; or just use the pbuf handling functions like
>>pbuf_copy_partial()
> This could be the reason, I need to check this. As I'm on vacation
> I'll check and follow up with this thread on Wednesday.

I think so.
Enjoy!

>>Unless you have DMA which you did not say
> Yes DMA is used. I'm using SAMA5D35 processor. I have created buffers
> and the locations of the buffer is stored in buffer descriptor and the
> location of that descriptor is stored in the DMA Queue pointer.

OK, I can't help in here, make sure your DMA controller does not interfere with lwIP and you don't have concurrency issues.
If this is zero-copy, you'd better double check.

_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users