Netconn has more overhead than the RAW API. In scenarios where the eth
pipe is faster than the micro, this extra overhead means extra latency
and so less thruput.
However, 2 seconds rtt is, how can I say it, a bit way too much ?
Having "problems" with more than 128 bytes per message is another
indication that something in your port, or your netconn application, is
not correct. If you suspect that netconn_write() takes too long, why
don't you move a pin and time it ?
Perhaps you've found the priority bug again ? Try searching the list, or
perhaps the task is scheduled too spaced apart ?
Your driver might be OK, and the port, since the RAW API apps seem to
work OK, or it could just be that you think they run OK and they don't.
A TCP echo can run smoothly on a really broken port, I've seen that, try
something more real like a web server, for 1.4.1 it is in the contrib
tree. Furthermore, if you will use an example, throw away vendor demos
and get it off the contrib tree. For 2.0.0 the server is an app in the
main tree.
PS: people is not struggling with lwIP and LPCs, they are struggling
with ports and drivers not following lwIP guidelines.
_______________________________________________
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
