Re: [lwip-users] Porting 2.1.2 to Atmel Studio 7... dirent.h?
Am 8. Februar 2019 20:18:23 MEZ schrieb Stephen Cowell : > >On 2/7/2019 11:39 PM, goldsimon wrote: >> Am 8. Februar 2019 00:27:58 MEZ schrieb Stephen Cowell >> : >> ... > >> > Does everyone have to go through and edit >> >the >> >header file includes to reflect the new structure? I can't see why >> >this >> >is not fixed in the release. >> >> That should not be required. Can you give an example? >> > >In my example, I have replaced the lwIP folder lwip-1.4.1 with >lwip-2.1.2 as I received it. > >OK... I'm compiling along, and I get this error: > >"Error lwip/apps/lwiperf.h: No such file or directory " > >This request lies in lwiperf.c, which resides in > >lwip/lwip-2.1.2/src/apps/lwiperf > >. The file it wants resides in > >lwip/lwip-2.1.2/src/include/lwip/apps > >. Every instance of this (there are dozens) requires me to change the >header include from > >#include "lwip/apps/lwiperf.h" > >to > >#include "../../include/lwip/apps/lwiperf.h" > >Am I doing something wrong? Yes, obviously. You need to add 'include' to your include path. Regards, Simon ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Porting 2.1.2 to Atmel Studio 7... dirent.h?
On 2/7/2019 11:39 PM, goldsimon wrote: Am 8. Februar 2019 00:27:58 MEZ schrieb Stephen Cowell : ... > Does everyone have to go through and edit >the >header file includes to reflect the new structure? I can't see why >this >is not fixed in the release. That should not be required. Can you give an example? In my example, I have replaced the lwIP folder lwip-1.4.1 with lwip-2.1.2 as I received it. OK... I'm compiling along, and I get this error: "Error lwip/apps/lwiperf.h: No such file or directory " This request lies in lwiperf.c, which resides in lwip/lwip-2.1.2/src/apps/lwiperf . The file it wants resides in lwip/lwip-2.1.2/src/include/lwip/apps . Every instance of this (there are dozens) requires me to change the header include from #include "lwip/apps/lwiperf.h" to #include "../../include/lwip/apps/lwiperf.h" Am I doing something wrong? The Atmel community link below cites the same issue... "When compiling, some files needed to change slightly, such as knowing where the header files are and such, but nothing major.". __ Steve . ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Porting 2.1.2 to Atmel Studio 7... dirent.h?
Hi Steve - While not exactly your challenge, I recently had to update an LwIP 2.x to the latest, on an ST project (easier change than from 1.x). I've attached my notes below; perhaps they will help, Best Regards, Dave ST distributes a lwip 2.x version which is not up-to-date and cleverly has all version notes and change logs stripped. To use the latest distributed lwip safe release: 1. Download latest lwip 2. Copy into project using different directory name lwip-2.1.2 so CubeMX does not over-write it. 3. Copy the lwip\system tree into lwip-2.1.2 4. In project, mark Resouce Configurations → Exclude From Build (for all configurations): 1. CubeMX-generated lwip tree 2. lwip-2.1.2\src\apps\http\fsdata.c (this C file is included in fs.c) 3. lwip-2.1.2\src\apps\http\makefsdata tree (utility needs to be built in Visual Studio) 4. lwip-2.1.2\src\apps any unused apps (SMTP, etc.) 5. lwip-2.1.2\src\test tree 5. Update, for all configurations, change C compiler include paths from lwip to lwip-2.1.2 On 2/8/2019 12:39 AM, goldsimon wrote: Am 8. Februar 2019 00:27:58 MEZ schrieb Stephen Cowell : >I'm attempting to update the SAM4E example project >THIRDPARTY_LWIP_BASIC_HTTP_EXAMPLE1 from 1.4.1 to 2.1.2. The dev >system is Atmel Studio 7 using ARM/GNU Common toolchain. I have NO_SYS =1 >this is the bare-metal implementation. > >I've partway through the directory problems... it seems that the >directory structure has changed, but the files I have have not been >updated. Is this normal? Does everyone have to go through and edit >the header file includes to reflect the new structure? I can't see why >this is not fixed in the release. > >Now I'm getting #error " not supported". Does this mean that >I'll have to go to a different toolchain? Do I have to have tinydir for >the stack to work? My eventual target (we've been selling our product >with lwip 1.4.1 for years) has FatFS already, I'd rather not do the >filesystem over as well. Also getting "#error makefsdata not supported > >on this platform"... how do I carve up lwIP? I've already deleted the >'api' folder, referring to this link: > >https://www.nongnu.org/lwip/2_0_x/group__lwip__opts__nosys.html > >This link was a great help, but I'm not sure if these guys are running >bare-metal or not... > >https://community.atmel.com/forum/upgrading-lwip-141-200-pbuf-issue > >Perhaps someone could throw me a bone? Do I need an RTOS to move >forward? Do I need a different toolchain? >__ >Steve >-- > >Stephen Cowell >Project Manager/Engineer >Plasmability LLC >Office (512) 267-7087 >Cell (512) 632-8593 >www.plasmability.com > >___ >lwip-users mailing list >lwip-users@nongnu.org >https://lists.nongnu.org/mailman/listinfo/lwip-users -- Dave Nadler, USA East Coast voice (978) 263-0097, d...@nadler.com, Skype Dave.Nadler1 ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] retransmission in lwip2.0
What I see is that the slave seems to respond but its response is not in the capture. This means that the frame is not getting there, it is getting lost somewhere in between. If the slave is an lwIP device, then it is quite likely your driver+port are losing frames. Vague questions usually get vague answers, if any. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
[lwip-users] TCP snd_queuelen issue (Jasper)
Hi Simon,
I don't think they directly influence snd_queuelen but they do influence the
function where this assert is triggered. I thought maybe bug #51447 could have
something to do with it because it influences the while loop around the assert
(TCP_SEQ_LEQ). I thought maybe bug #48839 because the assert is triggered
inside a the function that handles the acknowledgements. It can be a bit far
fetched though. Another reason I'm looking at these boundary cases is that I
cannot find something that triggers it. There is no sequence in the crashing
behavior. It can be that the communication works for hours without an issue but
it can as well crash after 5 minutes if we hook up a few webapp's to the device.
The TCP module is a big one, that's why some guidance in my search would help
me a lot.
Kind regards,
Jasper
> Am 07.02.2019 um 16:36 schrieb Jasper Verschueren:
> > Hi,
> >
> > I'm running the?lwIP latest master on a NXP -? K64F without operating
> > system and I'm having some troubles with TCP.
> >
> > I'm using a stripped down version of the httpd and added a simple HTTP
> > POST command protocol to it. This command protocol is keeping the device
> > and webapp in sync.
> >
> > A webapp is sending POST messages to my device with the webapp state in
> > it every +-60ms. The httpd sets a flag when it receives such a message.
> > In main loop we evaluate the flag, if true we evaluate the received
> > webapp state and send a HTTP OK with the latest device state in it. From
> > this main loop flag check we?construct the message, we call http_send
> > and directly after tcp_output.
> >
> > (I know this polling method is far from ideal but it was a quick
> > implementation before we continue with websockets.)
> >
> > It works great except that?on completely random moments lwIP crashes and
> > the complete MCU is halted.
> >
> > From time to time I get following assert when that happens:
> >
> > ? ? LWIP_ASSERT("pcb->snd_queuelen >= pbuf_clen(next->p)",
> > (pcb->snd_queuelen >= clen));
> >
> > There are also moments were no assert is triggered and it just crashes
> > (or maybe the assert message is not printed on these occasions i'm not
> > sure).
> >
> > I have been evaluating the code that influences snd_queuelen and I
> > noticed that there are some open tcp bugs at the moment that can have
> > influence on sequence numbers and ack's.
>
> I'm not aware of any having an effect on snd_queuelen. Could you point
> me at the ones you mean?
>
> Regards,
> Simon
>
> >
> > It would really help if someone could point me in the right direction.
> >
> > Thanks!
> > Jasper
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
