[INFO] lwIP version 2.0 Topic is solved

[steved]

Do demos require adjustments after implementing this change?

Definitely. Certainly the lwipopts.h file.

As an absolute minimum, LWIP_NETIF_API==1 is required as part of the fix to bug #729. And there may be other changes as part of a major version update.

The sample configuration file is the one that's currently working for me on an F429; so it should 'just work' on the Olimex E407 demo. I have also run my code on one of the 32F7XX family (32F767, probably) without any networking changes there.

The configuration file has no specific processor dependencies, so should work on the F107 as well (although I guess some memory-related allocations might need to be tightened up on a smaller processor).

There's also now a web server as an option within the lwip addons. IIRC very simple to enable; just two lines in main.c:

Code: Select all

#include "httpd.h"

// Add in main(), after lwip initialised
httpd_init();                             // Initialise lwip-based web server

[rasm]

Hi,

Any news regarding this integration ? I've been using lwIP 2.0.2 and these patches for some time now with good results and I can help with the integration if needed.

[Giovanni]

Patches addressing lwIP bindings and all lwIP demos would help (over 17.6.0 or trunk).

Giovanni

[rasm]

Hi Giovanni,

I attach 5 patches to cleanup the lwip_bindings for the 2.x upgrade changing as little as possible. These patches should apply cleanly on top of the stable_17.6.x branch with patch -p1

Most of what was changed is based on steved patches and he deserves the credit. The next batch of patches will include iggarpe's changes and the actual upgrade to lwIP 2.0.3.

All lwIP based demos compile and I have tested the STATIC, AUTOIP, and DHCP startup addressing modes in a OLIMEX STM32-E407 board.

[Giovanni]

Hi,

I added the patches to trunk. I will back-port the whole thing to 17.6.2 when the migration to lwIP is done and confirmed functional.

Giovanni

[rasm]

Thank you Giovanni.

I attach the second part of this patchset and the patched sources of lwip-2.0.3. I also included a patch showing what was changed in lwip. All the
ChibiOS demos using lwIP are functional. This patch should be applied against trunk.

[Giovanni]

Hi,

I integrated the latest patches into trunk but I have a question: do the configuration files into the various demos need to be replaced with newer versions?

Giovanni

[Giovanni]

Hi,

I updated the arch file because mailbox function names changes, now everything compiles.

I noticed there is an http server in lwIP now, it would be nice to update demos to use that one, it looks very complete for a small server, it also includes a ROM file system (it would be interesting to make it use a FatFS directory, imagine that).

Giovanni

[steved]

I noticed there is an http server in lwIP now, it would be nice to update demos to use that one, it looks very complete for a small server, it also includes a ROM file system (it would be interesting to make it use a FatFS directory, imagine that).

I looked at this http server, and IIRC using it is just a matter of possibly including some more files, and calling httpd_init() from main. However it seemed pretty closely coupled to their version of a ROM file system, and porting to use fatFS in a generic way didn't look trivial. It could maybe be added using SSI (Server Side Includes) or CGI, but I didn't pursue that.

[Giovanni]

Hi,

Isn't it matter of just rewiting fs.c to use FatFS inside? asynchronous functions are not mandatory and, anyway, could be simulated with a worker thread

I will look more closely.

Edit: It seems there is no need to rewrite anything, fs.c can redirect calls to functions postfixed with "_costom", apparently they planned for plug-in file systems.

Edit 2: Apparently it has already been done: https://community.st.com/thread/40997-s ... om-sd-card It needs to be cleaned and added as an httpd-fatfs binding. Adding asynchronous support could improve performance because SD calls are "slow". The problem is that the callbacks have to be invoked from the same httpd thread context I think.

Giovanni