Imagine your image data is 3MB. Would you expect lwIP to buffer that on
a 32KB microcontroller ? No, would you ?
Right, that is, light-weight IP.
The server will send bytes as it wants.
TCP will send bytes as it wants.
They will be put in IP and sent via Ethernet
Each frame gets IP extracted, gets TCP extracted, gets your callback
called. You get a pbuf.
You will get bytes as the combination of the server, TCP and the net
wills, plus, those bytes will be in a pbuf that can itself be a chain of
smaller pbufs, depending on the fragmentation of your memory.
You detect the connection has been closed.
You detect content-length has been transferred.
You are the client.
You extract data from your pbuf with pbuf_copy_partial() and copy it to
wherever you want.
Do you want all the data in a single pbuf ? Chain them ! The httpd
server is a nice example of how to do it. Basically: pbuf_cat(bigpbuf,
newpbuf); However, since pbufs can be themselves chain of pbufs, I
wouldn't do that...
If you need the whole image in one piece for processing or whatever, you
should copy each pbuf to your buffer with pbuf_copy_partial(). Even
though you can chain all pbufs and access them later with
pbuf_copy_partial(), I wouldn't dare to write an image processing
algorithm doing its job this way.
_______________________________________________
lwip-users mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/lwip-users
