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 <address@hidden> wrote:
From: Chris Strahm <address@hidden>
Subject: Re: [lwip-users] Duplicate sequence numbers
To: "Mailing list for lwIP users" <address@hidden>
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 -----
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 <address@hidden>
wrote:
From:
Chris Strahm <address@hidden>
Subject: Re: [lwip-users]
Duplicate sequence numbers
To: "Mailing list for lwIP users"
<address@hidden>
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
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users
-----Inline Attachment Follows-----
|