Hi,
When you wrote “if I receive one character i will immediately wait for more after 50 ms
it quits waiting”
Did you mean when TCP part gets a byte from UART ?
If this is what you do than its OK… You are working with a micro with limited RAM. If you define large MSS (1500 bytes)
Unless I am mistaken every time you allocate a buffer it will allocate a fixed size MSS buffer. So for every chunk you a
Allocate a large buffer. You are limited by the number of buffers and if you send lots of small chunks TCP may get to a
Point you will be out of buffers.
Also do you use netcon or Socket API ?
If you use netcon it is not thread safe. That means that when you send data from UART you must either protect the
Code by critical section:
taskENTER_CRITICAL();
{
AvailableSpace = tcp_sndbuf(ts->pcb);
}
taskEXIT_CRITICAL();
OR put the data in a buffer and init a sys_timeout call and let the TCP read the data and send it from within the TCP stack
Context.
If you do not do one of the above (In RAW or netcon API) you may get memory leaks or strange handling. It seems to work
But after some time it starts to get slower and may stop… I have been there.
BR,
Noam.
From: Erkan Ersoy [mailto:address@hidden
Sent: Sunday, September 18, 2016 4:15 PM
To: Noam Weissman
Subject: Re: [lwip-users] long time tcp receive lwip packets lost
My question was about tcp to serial code is like below:
if(FD_ISSET(clientSocket, &readset)){
readCount = lwip_read(clientSocket, &buffer, 200);
printf("close connection\n");
lwip_close(clientSocket);
//printf("rc: %u\n",readCount);
I will add buffer to this side (DMA based); but in spite of there is plenty time to send data to serial port, there is a memory problem somewhere.
And I think even I add buffer it will become problem after a long up time. It feels like there is a memory leak but I can't see in stats.
About serial buffering; if I feed data to tcp socket fast enough lwip buffers it for me. So my code is like below (I checked with wireshark and it doesn't
send one character in a TCP packet.)
if(FD_ISSET(clientSocket, &writeset)){
if(xQueueReceive(rs232QueueHandle,&serialData,0)){
lwip_send(clientSocket,&serialData, 1, NULL);
while(xQueueReceive(rs232QueueHandle,&serialData,50)){
//printf("gelen: %c\n",serialData);
//lwip_write(socket, &serialData, 1);
lwip_send(clientSocket,&serialData, 1, NULL);
if I receive one character i will immediately wait for more after 50 ms it quits waiting. that doesn't send one char per packet. But if you say it
isn't a good practice I should change it too
On Sunday, September 18, 2016 3:45 PM, Noam Weissman <address@hidden> wrote:
1.
You must add buffering
2.
RS232 is character based but TCP is packet based.
As a result of the different data handling if you do not buffer data it means that for every byte you send from
RS232 you send a TCP packet that has one data byte. That means you have a huge overhead on every byte.
This is very un-efficient and causes the system to get very slow.
I have implemented a Bridge, used a 255 byte buffer and set two parameters: size and time.
Size: If you reach a predefined number of bytes you send them in one TCP packet.
Time: If you do not get any new data into the TCP buffer after a predefined time you send what you have.
This way you collect data from UART and send it in chunks/packets.
For example you define 100 bytes as threshold or 30ms as time threshold. Every byte added from UART
To the send buffer is counted. Once the counter reaches 100 or if no new byte is added after 30ms the
TCP buffer is sent and parameters are cleared.
I also suggest using a small MSS size (I use 536 bytes).
From: lwip-users [mailto:address@hidden]
On Behalf Of Erkan Ersoy
Sent: Saturday, September 17, 2016 1:42 PM
To: Mailing List for LwIP Users
Subject: [lwip-users] long time tcp receive lwip packets lost
I am making a serial tcp bridge device. it works in server mode I have freeRTOS 9, lwip 1.4.1 and STM32F107 device
I wrote the bridging part and for testing purposes I didn't implement buffer to TCP to serial. So Some while receiving data some data piles up in somewhere
in tcp thread (I think).
I wrote a python script that sends 2096 characters every second (some lorem ipsum text). serial speed is 115200. So there is enough time to send data
and free memory.
But after couple of hours (it is random. sometimes 2 hours sometimes 4 and yesterday it was 12 hours) device cant receive whole data somewhat it is
80 byte parts.and it piles up in tcp part. And after I stop my script I continue to get data from my serial window a few seconds. After memory is empty if I start my script again still same problem.
I enabled stats to see if I am getting out of memory but it looks fine. I couldn't find where my problem is.
There is a web server and an udp server running in device (I didnt send request both server while testing)
my stats before running test (it sends stat to seperate uart every 10 seconds)
accept_function: newpcb->state: ESTABLISHED
And after the problem (Nothing seems suspicious except cachehit I could't figure out what it is)