IP Stack is a bit of an understatement. It comes with enough to be a HTTP client, a HTTP server or a MQTT client - and that is the way I've seen it used in practice.
It is more like the busybox of embedded networking, but with a much more convenient license.
We used LwIP for a project some years ago, and found a very nice way to do system testing.
The project involved multiple microcontrollers communicating over an internal LAN. They used a small embedded kernel named MicroCOS, with LwIP as the IP stack.
We had cross-platform build tools set up, so we could build our stand-alone microprocessor applications either for native execution or with gcc, compiling to x64 code and executable on developer boxes. In the latter case, we implemented the lowest level link-layer part of LwIP using a mock, that used standard TCP/IP! We wrote a small TCP server and would spool up the micro-controller applications, which would then talk to each other on the developer machines as though they were running inside the actual system.
This setup worked really well, and we used it for years during the development effort for the project.
For those looking for options like LwIP, consider NetXDuo [1] and its counterparts ThreadX, FileX, LevelX, and UsbX (I use TinyUSB instead).
It has been one of the top commercial RTOS network stacks for, I think, 20 years. It moved hands a couple of times and now is supported by the Eclipse Foundation and is MIT-licensed. I'd use it over LwIP.
It’s very neat that ThreadX and friends are MIT licensed now. I used ThreadX and NetX a bunch before the acquisition and open sourcing, and generally enjoyed using them. TX has a tight API / system design and implementation that makes it really nice to use.
I remember running into some obscure bugs with the NetX BSD socket layer that we ended up fixing in-house. It’s been way too long to dig up the specifics, but it’s great that fixes can now be upstreamed more easily.
> I remember running into some obscure bugs with the NetX BSD socket layer that we ended up fixing in-house. It’s been way too long to dig up the specifics, but it’s great that fixes can now be upstreamed more easily.
Unfortunately, it doesn't seem they have a process for that yet. But I'm sure that will improve. Or the community could take over. It would be nice to get a silicon vendor to pick this up to build a larger community around it.
> I remember running into some obscure bugs with the NetX BSD socket layer that we ended up fixing in-house. It’s been way too long to dig up the specifics, but it’s great that fixes can now be upstreamed more easily.
Yeah, I always had the impression their translation layers were afterthoughts. Never used the BSD one though.
What is nongnu.org and how does it relate to gnu.org?
EDIT: I found an answer[0].
StevePerkins on May 22, 2016 | unvote | next [–]
http://savannah.gnu.org is a hosting site for "official" GNU software (i.e. sponsored by the Free Software Foundation).
http://savannah.nongnu.org is a hosting site for "community" projects that are not sponsored by the FSF.
I guess it's the most used TCP/IP stack in resource constrained devices. But it seemed that for long, there's no competent alternative to it. https://github.com/FreeRTOS/FreeRTOS-Plus-TCP looks like a promising one.
It'd be interesting to see a breakdown of IP stacks for MCUs, their performance, how many security issues, etc.
NetX, Zephyr, LwIP, and SmolTCP all sort of fit in this realm these days it seems like. Probably others too... but yeah hard to discern the differences at a high level without digging in.
The quality usually depends on the vendor adapting it to their silicon.
If you look at ST and their STM32 the lwip integration is extremely bug ridden. Just read all the articles in their forum from "Piranha". I also struggled with extremely hard to debug bugs coming from their adaption layers.
I really like LWIP because it lets you use the same block of memory allocated by the Ethernet MAC DMA for the lifetime of the packet. You can really optimize the memory “pools” for your use case to reduce the number of memcpys.
I've run it on a Cortex M4 with a built-in Ethernet MAC peripheral. It was shockingly simple to integrate... basically just needed to set up a receive ISR that handed packets to the LwIP stack and a transmit function that the LwIP stack could call to send packets.
I have run it on a few hundred systems with Cortex R5 (used in a production context so demonstrated to be stable over tens of thousands of hours).
At that time there was a reference port for the Hercules development board available on-line. It was mostly working straight out of the box. I just had to fix a few issues with the Halcogen generated files (since then, TI has fixed the bugs), configure the lwIP options (to have DHCP and only use UDP). Since then (7 years ago), I have not touched the code once.
Depends on the microcontroller and the rest of your stack but it should be fairly straight forward.
Feed received frames from your MAC into the appropriate receive function in a netif, and link the output function pointer to something that sends frames to your MAC.
Examples for STM32 parts are so prevalent on the web that ChatGPT or Copilot can probably get you working source in 30 seconds.
I've seen their implementation. It was horrible. We eventually took the project away from them and had the local team work on it.
Also a fun story: they didn't use version control at all. When we eventually forced them to use git, they put the whole codebase in a .zip file and committed that.
I've worked with offshore companies that are similarly as bad, but then again there have been some that have been excellent. In your case, I don't know how they lasted 6 months if they're not committing to git etc, if that's the standard. They should be brought into the daily standups as 6 months to wait for some delivery seems a bit waterfally (apologies if this is a mischaracterisation).
> They should be brought into the daily standups as 6 months to wait for some delivery seems a bit waterfally (apologies if this is a mischaracterisation).
At least it it a clear mischaracterisation of waterfall:
LwIP is part of Espressif's ESP-IDF framework, for the popular ESP32 devices. I've been working with LwIP for years on this platform, and while it does work, it still takes up more memory than I'd like it to. Thankfully we now have ESP32 devices with 2MB of RAM.
Yes, it's impressive. I had to write one in assembly years ago. However, could only do UDP unfortunately as I didn't have enough memory for code and TCP buffers in 64kB.
I first heard about LwIP when I worked with the ESP32. Espressiv seems to maintain its own fork with some ESP-specific patches: https://github.com/espressif/esp-lwip
nongnu.org is also run by the same people as gnu.org, but hosts software which isn't currently officially part of the gnu project.
Basically, it's an area for software that is aligned with the GNU philosophy, might one day become part of the GNU project, but isn't officially currently part of the GNU project.
What’s the news value of this? LWIP is the most popular embedded network stack and has been around for ages. It also is awful to use and riddled with undocumented issues (in my experience, anyway)
In my experience, it is a breeze to use. ~10 years ago, we managed to significantly cut down the cost of IP cameras by using lwIP with NuttX which allowed us to use a cheaper microcontroller instead of a more expensive chip that could run Linux.
Plugging in a new TCP congestion control scheme was also straightforward.
the stack itself is extremely solid and works perfectly with reasonable performance. the codebase is extremely stable and has not had major changes, nor significant bugs in ages.
the biggest problem with lwip is the documentation. you have doxygen API docs that tell you exactly what the interfaces are (and not much more than the reading the header filed does), you have a few pages of "how to ..." and higher level background. but often it's slightly bit rotted, subtly hasn't kept up with design changes. so it's difficult to learn - you effectively have to thoroughly read the code to get the big picture. and if you make a mistake in handling your application callbacks, you can easily leak buffers or create other problems. it's not "awful to use", it's actually very simple - once you understand it, which is seriously hampered by truly lacking documentation.
the second issue is that the SoC vendors inevitably pay some overseas contractor to do the port and MAC/PHY drivers and example code, just like another [1] comment describes. that's where a lot of the instability and bugs come in. it's not lwip, it's the port that sucks.
My experience comes from actually writing the ports as opposed to using it in other places. I’ve gotten issues like the UDP checksum generation breaking in the raw API at higher speeds or DHCP packets managing to come out corrupted, and in both cases I fixed it by just replacing the code that’s responsible. I’m not claiming this is representative of anything in general however, these are all for somewhat esoteric networking analysis in an academic setting. It definitely works well when you just use it as intended on microcontrollers however and I’ve never had issues when I’m not doing awful things to it :)
It is more like the busybox of embedded networking, but with a much more convenient license.