Karl Karpfen wrote:
OK, so let me ask this in an different way:
Currently I do have data to be sent available in main loop only.
How can I enqueue these data into the lwIP-ISR-context correctly
so that it can be transmitted without problems?
To do that you'd either need to lock interrupts
2014-09-17 9:08 GMT+02:00 Simon Goldschmidt goldsi...@gmx.de:
Currently I'm doing it as described at
http://lwip.wikia.com/wiki/Raw/TCPin section
Sending TCP data which seems to be wrong for my case...
I only get an empty page with this link: This page needs content. You can
help by
Karl Karpfen wrote:
Currently I'm doing it as described at http://lwip.wikia.com/wiki/Raw/TCPin
section
Sending TCP data which seems to be wrong for my case...
There's nothing wrong with what's described at
http://lwip.wikia.com/wiki/Raw/TCP.
What's wrong is that your lwIP calls into lwIP
Hi,
this is a follow-up to How to check send state? but I start a new
discussion since it is a new question:
I'm trying to enqueue some data into lwIP's send queue that are generated
from within my applications main-loop (which is not allowed). Now my
solution is to just set a flag and then
OK, got it - thanks :-)
2014-09-17 11:10 GMT+02:00 Simon Goldschmidt goldsi...@gmx.de:
Karl Karpfen wrote:
Currently I'm doing it as described at
http://lwip.wikia.com/wiki/Raw/TCPin section
Sending TCP data which seems to be wrong for my case...
There's nothing wrong with what's
goldsi...@gmx.de wrote
Which version of lwIP are you using? Do you know that we support TCP
window scaling by now (LWIP_WND_SCALE)?
Indeed, i forgot this one. Its the version provided by the STM32CubeMX tool.
Diff shows its identical to LWIP 1.4.1. I didn't knew that. I guess you
refer to
Karl Karpfen wrote:
[..]
My question: are both running in same IRQ-context or are they triggered
by different ones so that filling the send buffer this way would lead to
troubles too? A check if previously enqueued data are fully send of course is
implemented.
That *totally* depends on your
Great, thanks! :-) :-) :-)
2014-09-17 12:16 GMT+02:00 Simon Goldschmidt goldsi...@gmx.de:
Karl Karpfen wrote:
[..]
My question: are both running in same IRQ-context or are they triggered
by different ones so that filling the send buffer this way would lead to
troubles too? A check if
There's nothing wrong with what's described at
http://lwip.wikia.com/wiki/Raw/TCP.
What's wrong is that your lwIP calls into lwIP from interrupt context and you
call it from your main loop. This is not allowed, that's all.
Thank you Simon
Wiki 1
users 0
Your code is too long for me to try to figure out which API you are
using and follow your approach.
In case you are using the raw API, please check the wiki, and then your
code, and if something is not clear then come back to us. I'll try to help
http://lwip.wikia.com/wiki/Raw/TCP
Is this the (in)famous ST-lost-frames bug again ?
Translation: is your port running on an RTOS with an Rx task fired from
Eth interrupt and taking only the first frame out of the chip ?
___
lwip-users mailing list
lwip-users@nongnu.org
Hi Karl,
I'm not trying to teach you how to do things, but I need to ask you if
there is any reason why you can't rise a flag in your eth rx interrupt
and run all lwIP code from the main loop ? (zero latency ?)
Mine (sort of):
void eth_input(ifc)
{
do {
if(!flag)
break;
Sergio,
Michael Steinecke wrote:
The FW Library bug in the Ethernet IRQ, eating fast packets is fixed.
So no, this does not seem to be the standard STM issue...
Simon
___
lwip-users mailing list
lwip-users@nongnu.org
/ The FW Library bug in the Ethernet IRQ, eating fast packets is fixed./
So no, this does not seem to be the standard STM issue...
Oh, I see, missed that part. Should we believe the vendor ? (terrified face)
Anyway, here are my 2 cents:
- Frame 16: bad FCS on ARP response from MCU to PC, why ?
14 matches
Mail list logo
