at the moment, an old problem came up again: one of my boards sometimes crashes when using my UDP communication. In the past, it was always the same board (I have 3 in total), and it took lots of communication cycles until it crashed. Now, another board (which was running with the same software just fine until now) crashes in the moment when I send the first UDP packet to my receive callback function. However, pings are replied just fine.
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.
Can you give me some architectural hints about that?
This is how I would try:
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);
2. the lwip_thread from the ehernet demo remains unchanged
3. what should be the netconn thread priority in comparison to the lwip_thread?
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.
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.
Is this the correct approach?