On Sat, Mar 30, 2024 at 1:07 PM Simon Goldschmidt via lwip-users < lwip-users@nongnu.org> wrote:
> 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
_______________________________________________ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
