rubenswerk wrote:So I remembered Mabl's hint and I'm thinking of switching to the netconn API. After reading the lwip wiki I'm still not sure if the way I use the raw API is forbidden in an OS environment. However, I think it's worth a try to use the recommended netconn API.
That's a wonderful idea I'd bet your problems will disappear. If you are still not convinced, look at the Raw api documentation http://git.savannah.gnu.org/cgit/lwip.git/tree/doc/rawapi.txt
rubenswerk wrote:1. instead of using the raw API UDP callback function, create a new thread with an endless loop, waiting for UDP packets using netconn_recv(conn,&buf);
Correct. I think there is something like netconn_new_with callback. I've once tried to get it working with TCP for true full-dublex communication (which does not work if you use blocking, since each netconn may only be used from the same thread *argh* - I hate lwip )
rubenswerk wrote:2. the lwip_thread from the ehernet demo remains unchanged
rubenswerk wrote:3. what should be the netconn thread priority in comparison to the lwip_thread?
Hmm not sure. The netconn thread should not be able to starve the lwip_thread by sending. On the other hand, while receiving, the netconn thread should not be starved... I think I have it running at same prio - but i guess this might increase latency under high traffic?
rubenswerk wrote:4. will there be increased latency compared to a callback function? netconn_recv is a blocking function, which needs to be notified by the lwip kernel. I know it's possible to define a callback also for netconn, but I couldn't find examples for that and I think a thread is the better design choice if the performance/latency is similar.
I'd not worry about the blocking calls. But make sure you do not want to send while you block. There lie dragons here.
rubenswerk wrote:5. should the netconn setup (netconn_new, netconn_bind) be done in the main function before starting the netconn thread? Functions like netif_add are not thread safe. However, I hope that all netconn_xxx functions ARE thread safe.
Just do it in the netconn thread before the endless loop.