[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-users] TCP send problem
From: |
Noam weissman |
Subject: |
Re: [lwip-users] TCP send problem |
Date: |
Mon, 18 Aug 2014 23:23:13 +0300 |
Hi,
As a continuation to my last mail. I wrote volatile memory but I meant none
volatile
memory, sorry for that error !
BR,
Noam.
-----Original Message-----
From: address@hidden on behalf of Noam weissman
Sent: Mon 8/18/2014 11:21 PM
To: Mailing list for lwIP users; Mailing list for lwIP users
Subject: Re: [lwip-users] TCP send problem
Hi,
When you put ZERO in the lat argument of tcp_write that means that the buffer
you use
to send the data from should be static.
Putting ZERO as the last parameter means data is from volatile memory, normally
from
FLASH or a static buffer. The reason is that the TCP stack will not copy the
data to
its one buffer but rather send it from the supplied pointer.
Sending can be delayed considerably and if the buffer is allocated on stack
that explains
the reason you get bad data.
using the copy flag means that tcp_write will copy the data from the supplied
pointer
to an internal buffer.
As for using LwIP. I strongly recommend upgrading to 1.41 and use FreeRTOS. You
have
examples from ST for that.
One very important note !
If you use FreeRTOS you must properly set your interrupt levels. TCP and every
code that
uses FreeRTOS functions should define their interrupts to be lower priority
then the OS.
Avoiding this will cause unpredictable results and even causing the TCP stack
to hang.
Hope that helps.
BR,
Noam
-----Original Message-----
From: address@hidden on behalf of Paul Webber
Sent: Mon 8/18/2014 7:30 PM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] TCP send problem
Dominik,
I am doing about the same thing as you. Try the tcp_write
(tpcb,&buff[flag],sendLen, TCP_WRITE_FLAG_COPY); TCP_WRITE_FLAG_COPY is defined
as 0x01. I did not have success sending with 0. I am however using 1.4.1
Hope this helps,
Paul
From: address@hidden [mailto:address@hidden On Behalf Of Dominik Wybranczyk
Sent: Monday, August 18, 2014 4:46 AM
To: address@hidden
Subject: [lwip-users] TCP send problem
Hello, my name is Dominik and this is my first post to lwip mailing list. I am
working on stm32f4 IOT project where I want to use RAW lwip. I am basing on
standalone tcp echo example made for STM32F4DIS-BB (Embest). I have already
designed some drivers, and they are working great (like connection accpet,
connection close, receiving handler, parser etc). But I have some problems with
sending data. Everything works well when I am sending messages up to 38B, but
if I send more than they are corrupted.
Here is how it works:
My device is server, and I connect as clinet with my PC. I am sending some data
from PC to my device. Than when I have received some information form PC, I
parse it and want to respond with another data.
Firstly I am checking "freespace" in sending container by using tbp_sndbuf()
like:
freespace = tcp_sndbuf(tpcb);
Usually there are a lot of space (like 2500B, but I also have handler for the
situation when there are more data to send than container can handle...) so
after that I am passing message to tcp_write like this:
wr_err = tcp_write(tpcb,&buff[flag], sendLen,0);
Variable wr_err is always 0, so "mem write" is OK. After that to make sure the
message will be send now I call:
tcp_output(tpcb);
Sadly, the information I am receivng on PC is wrong every time when I am
sending more than 38B. Usually its shorter and the message is like:
corrupted_data + SMALL_PART_THAT_IS_OK + other_corrupted_data.
To be honest I am not getting the idea with the tcp_send() callback, but I
assume that I dont need it in this simple example.
I am using lwip_v1.3.2 as in example. Should I update it?
What should I look at? Am I doing something wrong?
Kind Regards
Dominik
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer
viruses.
************************************************************************************
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer
viruses.
************************************************************************************
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer
viruses.
************************************************************************************
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer
viruses.
************************************************************************************
<<winmail.dat>>