My implementation is also buffered in this way, and writes to a full buffer are thrown away to prevent blocking. I would imagine that the sprintf I'm using, although a more lightweight version than most C libs, just takes some time to execute. Also I've noticed there are some heavy-duty debug outputs in tcp_input.c I should just comment out since it doesn't seem to help in my debugging.
I'm sure once I figure out the problem, it'll be one of those "Duh" moments. --- On Mon, 8/17/09, Chris Strahm <[email protected]> wrote: From: Chris Strahm <[email protected]> Subject: Re: [lwip-users] Duplicate sequence numbers To: "Mailing list for lwIP users" <[email protected]> Date: Monday, August 17, 2009, 11:57 AM Handling UART debug output can be tricky, especially so it does not impact other running code. I have mine setup so printf dumps it's output into a memory buffer fast, no waiting, and then an INT picks up the strs later and sends them out the UART. That is important so that the printf does not cause a major delay in code execution hanging at UART speeds. However if you have a bunch of the LWIP debug sections turned on, you will need about 16K buffer space. I see LWIP dump out 14K of str data very fast into the buffer, before the UART even begins to send the first byte out. I ended up using the 16K USBRAM memory block on my MCU as the UART string buffer area. Chris. ----- Original Message ----- From: JM To: [email protected] Sent: Monday, August 17, 2009 4:05 AM Subject: Re: [lwip-users] Duplicate sequence numbers I have the UART setup for debugging output. The kicker with this is that introducing enough delay by enabling enough debugging, or even if I define the debug output as a delay, makes some of the problems disappear. I've also enabled stats and have studied that. The driver, yeah, my guess is that's where the problem is. It's the driver provided by Luminary, so I assumed it was well tested, but I'm questioning this since the actual lwIP code should be stable enough for what I'm doing. I have been studying ethernet and TCP/IP for awhile now, so I have the basics down but am not too fluent in the fine details. Not using an RTOS. I believe the driver is using lwIP pbufs, and setting pointers to them....lately I'm realizing I'll have to learn how the code works better to debug effectively. However, it is nice to know I'm not the only one who has spent great amounts of time on this! --- On Sun, 8/16/09, Chris Strahm <[email protected]> wrote: From: Chris Strahm <[email protected]> Subject: Re: [lwip-users] Duplicate sequence numbers To: "Mailing list for lwIP users" <[email protected]> Date: Sunday, August 16, 2009, 11:24 PM The descriptions you have given leave too many possibilities. Ethernet is very complex. There are a zillion potential issues between the driver, the lwIP configuration, options, and potential RTOS. Not much anyone can do for you without a lot more details on what your setup is and some debugging data. For example, do you have a console/uart setup to output DEBUG strings? You really need that. Without that you are blind. lwIP has a lot of stats and debug info that will help you figure out what is going on inside lwIP. You will need to get fully aquainted with the debug facilities of lwIP. You mentioned before setting your pbuf size to 256 bytes. What is the size of your driver/DMA/MAC buffers? They should probably be set the same to 256 bytes. Depending on how the driver is writtem, it may or may not support mixed sizes and full fragmentation. Just the driver alone is a really big Black Box full of potential headaches. Troubleshooting skills here are a really big plus. Getting lwIP up and running is not trivial. You have to start at the bottom and build your way up from there. I found it hard to get very far on this kind of code until I developed enough understanding of what makes Ethernet tic from top to bottom. There is a learning curve. You may be on this longer than you expected. I sure have been. Hope this helps. Chris. -----Inline Attachment Follows----- _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users -----Inline Attachment Follows----- _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
