TM4C1294NCPDT: Does anyone have any experience with LWIP 2.0.2

Hello Allan & Charles

What I did was to just first take a backup copy of the lwip-1.4.1 directory under the third_party directory of my TIVAWARE _213156 installation and then I replaced the  src subdir with that of 2.0.2. The apps dir in 1.4.1 and 2.0.2 are in different paths but not a big deal (just change the #include paths where and when needed in your source if you use that examples). I did this mainly to tackle with some problems I had with the buffers's handling in tcp_in.c and tcp_out.c of 1.4.1. You can try these 2.0.2 libs, after you have take a backup copy of 1.4.1 and check for any differences in your bin's behavior.  It is a very tedious process to run in notepad++ with compare plugin activated the different libs of the two version side-by-side to spot where differences exist and understand them. Since it's not our code, I didn't find any other method to check the differences of these two versions, at least for the issues I was looking for. And as always, in case you get to many pink/red lines during compiling and you have no time for tedious debugging, you can just replace and overwrite with the original 1.4.1 version's dirs. That always works :-)

All the best and have a nice weekend

John

P.S. Here http://www.nongnu.org/lwip/2_0_x/upgrading.html one can check on the differences of 2.0.2 in relation to the older versions. Very helpful when compiler ejects "mysterious" messages".

John - most excellent - highly detailed - much appreciated - thank you.   (my (129 avoiding ) group cannot use - but your "care/effort" must be recognized...)
Do check your PM here - you are a great addition to this forum...

Hi John,

great insight!

However, it's not clear to me how you actually compared the two version side-by-side as lwip-1.4.1 is completely different to lwip-2.0.2.

Also, does it work with CCS compiler?

Thanks!

Hello Manuel and all at the forum.

1) For Notepad++ there is a plugin that allows one to have two different sources side-by-side and compare them.

2) I had spot some differences in the lwip 1.4.1 and 2.0.2 versions that I can't recall them in detail now because it's 

already 1:30 in the morning here. Tomorrow I can reply again on some of the differences I had spot.

3) One  'defect' in 1.4.1 is that one can't redefine the server's port in main() or at run-time. You need to define the

server's listening port once, either in your whatever.h file or in the definitions/declarations area before main(), or

before setup() in case of use of the ENERGIA ide.

4) A method was added in the EthernetServer class that seems it works OK so far, I'll post it again here tomorrow,

that allows one to dynamically create listeners at run-time. No big deal but there are cases that turns to be very

useful.

All the best,

John

Hello Manuel.

Indeed, lwip-2.0.2 is in many aspects quite different from lwip-1.4.1. If one just compares the tcp.c blocks of the two versions may see many improvements in 2.0.2 over 1.4.1. in packet blocks handling for example. However, if one uses CCS these changes do not seriously affect any existing code. Not likely the case with ENERGIA. The version 17 of ENERGIA is based on lwip-1.4.1 and between the two tcp.c blocks, (the one that ENEGIA uses is in lm4f\libraries\Ethernet\utility\tcp.c)  as well as between others, there are almost negligible differences. However, because ENERGIA offers an out of the box set of Ethernet utilization libraries ( in lm4f\libraries\Ethernet) so that one may quickly start coding using Ethernet, if one decides to update the lwip directory of ENERGIA-17 with lwip-2.0.2 code blocks then he/she is also obliged to review and update the Ethernet, EthernetUdp, EthernetServer, EthernetClient source. No big deal but also not a task that should be taken lightly.

In my last night's post I mentioned about a 'bug' -mostly a missing piece of code, in ENERGIA's  EthernetServer.h/c source. If one wants to be free to raise TCP listeners at run-time and also in setup() on different ports then needs to add the following code:

In Ethernet.c --> void EthernetServer::SetPort(uint16_t iPort) { _port = iPort; } and in class EthernetServer of EthernetServer.h in 'private:' sector the uint16_t _port; and in the 'public:' sector of the class --> void SetPort(uint16_t iPort);

Hope the above helps. In case Manuel you need any more clarifications regarding differences between lwip-2.0.2 & lwip-1.4.1 I'll be happy to assist if I know.

John

John,

thank you very much for you comprehensive replies. All your input is very much appreciated. 

To be honest, I wasn't aware of the existence of the Energia environment. It looks very much like the Arduino IDE (but much more powerful for sure) so thank you for bringing it to my attention. 

Regarding the actual upgrade, I am working on CCS so, as far as I understand, I won't have to worry about updating the Ethernet, EthernetUdp, EthernetServer, EthernetClient source code. 

I now have "only" ~50 errors to clear up (I started with around 200) so I'm slowly getting closer. 

Thank you again. 

John,

thank you very much. I am now much closed to have it compiling error-free. 

The last bit that is giving me some grief is the makefsdata.c file as I am getting this error: 

#1965 cannot open source file "sys/stat.h"	makefsdata.c	/M6400 - TIVA/Platform/Network/lwip-2.0.2/src/apps/httpd/makefsdata	line 23	C/C++ Problem

It seems like the sys/stat.h file is not part of the compiler library (I am using ti-cgt-arm_5.2.2 compiler). 

Have you come across this? 

Thank you again. 

Manuel 

Hello Manuel.

In CCS6 & CCS7 the stat.h file is under the [ \ccs7_install_dir\tools\compiler\gcc-arm-eabi-4_9-2015q3\arm-none-eabi\include\sys ] path. A mess!!!! Just manage to reflect its path into your production code and that's about all.

John

Hi John,

thank you once more for your helpful reply. I have finally managed to get the code base built :-)

The only bit is that, in order to do so, I've had to comment out the occurrences of sys_now() in timeouts.c because, otherwise, I would get a link error stating that the symbol is unresolved. Does it ring a bell to you? 

I am using FREE_RTOS here which means that #NO_SYS flag is 0 and, as far as I understand, that should automatically remove all references of sys_now().

Warm regards. 

Manuel 

Hello Manuel.

As far as I can recall at the moment, the problem regards to some static libraries definitions of which CCSx is not aware. Let me check it later tomorrow and I'll get back. 

John

p.s. Seems that you are boldly go, from the very beginning, where no one....e.t.c.,  e.t.c. . Why μC/OS-xyz ? Have you already exposed your embedded coding and RT understanding to the edge? RTOS is NOT difficult but needs some very well understanding of the processor's architecture and problem's schema  before one decides to engage it.  That's not an advice, it's  just a mere incitement. Because I'v been burned, NO RTOS is even 10% capable of delivering what bare-metal-code can deliver. That, is NOT true in the multi-core processors realm. THERE, one is obliged to use RTOSs. 

In this forum, wise people, can be of more valuable help to you on those issues. All the best.............