Amena El Homsi wrote: > What I know is PBUF_ROM doesn't mean the actual ROM (stable for very long) > but it > means that the data is immutable and it is located in memory which is not > managed > by the pbuf system. Am I wrong?
Yes, you are wrong. ROM means stable for very long, not const :-) ROM really means stable for long. E.g. when sending via tcp_write with the nocopy flag, ROM means the data is stable until all retransmissions are done. This can be up to some minutes or hours, depending on the connection. TCP has the sent callback to tell the application when it is done, but ARP does not have this. As such, when queueing for ARP, we can prevent copying, but you'd never know when the frame has actually been sent. In this respect, I would be OK with the chang in ARP output, but that won't help you much as your usage of PBUF_ROM seems wrong. > so I have to add some instructions inside the LwIP code, right? You can always change lwIP code, but in my opinion, it's always better to work together to get things "mainlined". We'd have to change the queue handling in etharp_query() to change this. Regarding your original problem: why don't you put (some of) the memp pools into the frame memory? Simon _______________________________________________ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users