Re: [lwip-users] lwip with fatfs on a STM32 speed problem

Thanks I will try that, is it a serial / printf output?

What am I looking for in the debug?

Dave

Date: Wed, 29 Jan 2014 15:23:13 -0500
From: address@hidden
To: address@hidden
Subject: Re: [lwip-users] lwip with fatfs on a STM32 speed problem

HI,

Le 2014-01-29 12:11, Dave Sandl a écrit :

I am not sure what Nagle's Algorithm is or where to check for it.

Can you explain some?

I think I might have some problems with my lwipopts.h settings as well.

I don't really know how high I should be setting these but I was working on a upload function and was missing part of the packets but got it working playing with these settings a bit. I still do not really know what I am doing with this part.

You should really activate the stats debug info of lwip to be able to debug the lwipopts.h.

Jonathan

Dave

Date: Wed, 29 Jan 2014 11:14:36 -0500
From: address@hidden
To: address@hidden
Subject: Re: [lwip-users] lwip with fatfs on a STM32 speed problem

Yeah, the problem is not lwIP! I'm using an M3 at 120MHz, and have megabit performance. So optimizing how you fill buffers is a waste of time. As Krzysztof pointed out, you need to find the real cause of the slow behavior and fix that. Try sending a pre-packaged chunk from flash or sram.

Have you verified that Nagle's Algorithm is not hindering? If Nagle is on (at the non-lwIP end), it throttles back to like five packets per second. Put Wireshark on the wire somewhere and see the spacing of the packets.

I'm pretty sure Nagle's Algorithm is off by default in lwIP. I don't recall actively turning it off, but it is not happening in our lwIP stack.

Marty

From: address@hidden [mailto:address@hidden] On Behalf Of Dave Sandl
Sent: Tuesday, January 28, 2014 10:37 AM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] lwip with fatfs on a STM32 speed problem

I do not currently have my code / project in front of me, but I was reading some of the lwip docs and I had a question on the tcp_write usage.

Is it OK to loop a function with tcp_write and tcp_sndbuf (to check when full) in order to fill the write buffer with data from the SD card?

Could I run a loop like this every time the tcp_sent callback is called?
Would this increase speed?

Thanks
Dave

From: address@hidden
Date: Tue, 28 Jan 2014 09:41:34 +0100
To: address@hidden
Subject: Re: [lwip-users] lwip with fatfs on a STM32 speed problem

What performance do you achieve when sending random data from flash instead of reading it from FAT FS? Have you measured which module is responsible for this speed?

Regards,
Krzysztof Wesołowski

On Tue, Jan 28, 2014 at 8:23 AM, Noam weissman <address@hidden> wrote:

Hi Dave,

Attached please find the low level driver I used. This is a bit modified
driver
based on inputs I found over the net.

Try to use it and see if it is better for you.

BR,
Noam.

-----Original Message-----
From: lwip-users-bounces+noam=address@hidden
[mailto:lwip-users-bounces+noam=address@hidden] On Behalf Of Dave
Sandl
Sent: Tuesday, January 28, 2014 5:10 AM
To: address@hidden
Subject: [lwip-users] lwip with fatfs on a STM32 speed problem

Hi,

I am having problems getting good speed results on sending files using a
stm32 with fatfs files system.
I can only get max of around 2.5kBs on a image download.

My server and file system seem to work fine, here are the specs
STM32F4discovery with the ethernet/sdcard baseboard from element14

I used the ST supplied drivers for both lwip and fatfs to create a raw
api basic server.

Here is the relevant code sections, any help would be appreciated.
If I increase the sd_read_buff to 1024 or higher is does not send the
file correctly (not sure what to do here or if it should be bigger?)

#define sd_read_buff 512

struct http_state
{
FIL fileFS;
char *file;
u32_t left;
uint8_t buff[sd_read_buff];
};

static void send_data(struct tcp_pcb *pcb, struct http_state *hs)
{
err_t err;
FRESULT ret;
u16_t len;
uint br;
uint temp1 = tcp_sndbuf(pcb);

if(tcp_sndbuf(pcb) < sd_read_buff)
len = tcp_sndbuf(pcb);
else
{
if(hs->left < sd_read_buff)
len = hs->left;
else
len = sd_read_buff;
}

ret = f_read(&hs->fileFS, hs->buff, len, &br);
if(ret == FR_OK){
err = tcp_write(pcb, hs->buff, br, 0);
if (err == ERR_OK)
{
if(br < len)
hs->left = 0;
else
hs->left -= br;

}
}
}

static err_t http_sent(void *arg, struct tcp_pcb *pcb, u16_t len)
{

struct http_state *hs;
hs = arg;
if (hs->left > 0)
{
send_data(pcb, hs);
}
else
{
f_close(&hs->fileFS);
close_conn(pcb, hs);
}
return ERR_OK;
}

static err_t http_recv(void *arg, struct tcp_pcb *pcb, struct pbuf *p,
err_t err)
{
int32_t len=0;
char *data;
struct http_state *hs;

hs = arg;

if (err == ERR_OK && p != NULL)
{
/* Inform TCP that we have taken the data */
tcp_recved(pcb, p->tot_len);

if (hs->file == NULL)
{
data = ""> len = p->tot_len;

/* process HTTP GET requests*/
if (strncmp(data, "GET /index.htm", 10) == 0)
{

FIL file;
FRESULT ret;
hs->fileFS = file;

ret = f_open(&hs->fileFS, "index.htm", FA_READ);
if(ret == FR_OK)
{
pbuf_free(p); // Free the receive data
hs->left = f_size(&hs->fileFS);
send_data(pcb, hs);
tcp_sent(pcb, http_sent);
}
else
{
tcp_write(pcb, file_error, sizeof(file_error), 0);
pbuf_free(p);
close_conn(pcb, hs);
}

}

else if (strncmp(data, "GET /pic.jpg", 12) == 0)
{

FIL file;
FRESULT ret;
hs->fileFS = file;

ret = f_open(&hs->fileFS, "pic.jpg", FA_READ);
if(ret == FR_OK)
{
pbuf_free(p); // Free the receive data
hs->left = f_size(&hs->fileFS);
send_data(pcb, hs);
tcp_sent(pcb, http_sent);
}
else
{
tcp_write(pcb, file_error, sizeof(file_error), 0);
pbuf_free(p);
close_conn(pcb, hs);
}

}

else
{
tcp_write(pcb, http_index_html, sizeof(http_index_html), 0);
pbuf_free(p);
close_conn(pcb, hs);
}
}
else
{
pbuf_free(p);
close_conn(pcb,hs);
}
}
if (err == ERR_OK && p == NULL)
{
close_conn(pcb, hs);
}
return ERR_OK;
}

void IAP_httpd_init(void)
{
struct tcp_pcb *pcb;
/*create new pcb*/
pcb = tcp_new();

if (!pcb)
{
return ;
}
/* bind HTTP traffic to pcb */
tcp_bind(pcb, IP_ADDR_ANY, 80);
/* start listening on port 80 */
pcb = tcp_listen(pcb);
/* define callback function for TCP connection setup */
tcp_accept(pcb, http_accept);
}

_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users

************************************************************************
************
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.
************************************************************************************

_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________ lwip-users mailing list address@hidden https://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________ lwip-users mailing list address@hidden https://lists.nongnu.org/mailman/listinfo/lwip-users

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users

Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection Antivirus avast! est active.

_______________________________________________ lwip-users mailing list address@hidden https://lists.nongnu.org/mailman/listinfo/lwip-users

From:	east3
Subject:	Re: [lwip-users] lwip with fatfs on a STM32 speed problem
Date:	Sat, 1 Feb 2014 12:08:45 +0800