I guess this is typical for mdns. However, this is at least partly a
known issue in the mdns code, which allocates too much on the stack
(where it should rather do static-, pool- or heap-allocations).
Ah. That explains that. I actually do not know how to contribute patches to a non-github git repository, but this type of thing seems fixable. Is there a contributing guide for lwip?
> - Is there a good list anywhere of other "dangerous" (i.e. silently
> corrupt your memory if set wrong) options?
Non that I know of, but there should be no silent memory corruption
other than stack overflow - and I strongly suggest to implement a
runtime check against stack overflow: things can always go wrong!
Yes, that is how I discovered the source of the issue. I am enjoying using FreeRTOS on this basis alone -- that there are such runtime checks that seem to work pretty well by default.
> Any other tips for a newb? One thing I also can't seem to find much good
> information on is the pros and cons of using the raw APIs, netconn, or
> socket. I noticed that the apps seem to use netconn so that's what I'm
> starting with.
No, most apps should be using the raw API. Apps using netconn are not
seen too often. The raw API is the smallest and has best performance, at
the cost of requiring the user to think of programs much like a state
machine (in contrast to multithreading used for netconn or sockets).
My mistake. I'm not sure what I was looking at that made me think this. For less demanding uses of lwip on relatively unconstrained hardware like the Pico, I presume netconn is acceptable at least, or you wouldn't have it in lwip. Is that correct? Or is it a newb trap to use netconn at all?
-- James