Hi Noam,

I would probably call it a data server. Is it not possible to start writing
in either direction once the connection is established? Thank you for the
code I shall look at it today.  I'm not quite with you. If the data I wish
to send is the maximum size of the payload of a packet, there should be
nothing to queue so it should just be sent immediately??

Lee.

On Fri, Dec 19, 2014 at 1:37 AM, Noam weissman <[email protected]> wrote:
>
> Hi Lee,
>
> You are talking on a client application. That's a bit different.
>
> Yes you are correct you do not need to use recvd but you must use the
> tcp_sent callback to be able to know when to send more.
> You can also check the amount of RAM left in the sent queue so you can
> send and send until you are on the limit, then wait for
> the tcp_sent to fire...
>
> All my code are servers so I do not have something on hand that can
> help.
>
> Here is one of my functions that I use. Instead of calling tcp_write
> directly I took something from one of the examples I so:
>
> static err_t  my_write(struct tcp_pcb *pcb, const void* ptr, u16_t
> *length, u8_t apiflags)
> {
>    u16_t len;
>    err_t err;
>    len = *length;
>
>    do
>    {
>      err = tcp_write(pcb, ptr, len, apiflags);
>
>      if(err == ERR_MEM)
>      {
>        if((tcp_sndbuf(pcb) == 0) || (pcb->snd_queuelen >=
> TCP_SND_QUEUELEN))
>        {
>          /* no need to try smaller sizes */
>          len = 1;
>        }
>        else
>        {
>          len /= 2;
>        }
>      }
>     else
>     {
>        // if we are here it means that we have a timeout or
>        // network error and need to abort
>     }
>
>    }  while ((err == ERR_MEM) && (len > 1));
>
>    *length = len;
>
>    return err;
> }
>
>
> In the above code you try to send as much as you can and if tcp send
> buff is too small you try to send less and less, until you are
> successful or not.
> If you are not able to send everything you must wait for data buffers to
> get freed. This is done by calling the above code inside the tcp_sent
> call back
>
> Do not expect high throughput from LwIP. It is small but not very fast.
> I have read people are able to run it at about 1Mb, maybe I am wrong.
>
> BR,
> Noam.
>
>
>
>
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Lee
> Sent: Thursday, December 18, 2014 11:40 AM
> To: [email protected]
> Subject: Re: [lwip-users] TM4C1294 LWIP Usage
>
> Hi Noam,
>
> No I am not using an RTOS. I managed to echo characters today so that
> was a step forward. I was using a fairly simple and easy to understand
> tcp_echo code. tcp_echo_2.c
> <http://lwip.100.n7.nabble.com/file/n23627/tcp_echo_2.c>
>
> However my goal is not to receive but only to send. So  i won't need to
> use the recvd function and  then tcp_write(),tcp_sent() to loopback.
> Once I have a connection I will only need to write. I should be able to
> DMA in my data into 2 large buffers (maybe 1400 Bytes each) and then
> call a tcp_write with a pointer to this buffer. Then when my other
> buffer is full, call a tcp_write with a pointer to this buffer.
>
> I understand what you are saying about the code getting held up with
> lack of acks and freeing of buffers but I'm hoping the data will be fed
> out the ethernet faster than the data is coming in.
>
> The data will be coming in at 2.4MB/s so I'm not hopeful I can achieve
> the throughput with 100Mb/s ethernet.
>
>
> First problem though is using the tcp_write() outside of the recvd
> callback.
> Hopefully I can just go something like that which is attached but in a
> write function.
>
> tcp_write( pcb, my_buffer, 1400, 0 );
> tcp_sent( pcb, NULL );
>
> I'm not sure that I can use the pcb that I accepted with though.
>
>
>
>
>
>
> --
> View this message in context:
> http://lwip.100.n7.nabble.com/TM4C1294-LWIP-Usage-tp23623p23627.html
> Sent from the lwip-users mailing list archive at Nabble.com.
>
> _______________________________________________
> lwip-users mailing list
> [email protected]
> 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
> [email protected]
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>
_______________________________________________
lwip-users mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/lwip-users

Reply via email to