This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

tcp_send function acting weird

Hello,

I use TCPNet for my ethernet connection. I have a buffer wich I pass through via the function tcp_send, when I change the values of this buffer right after I called the function, then I receive the new values instead of the original ones.
I change the values to show what I have sent on my display, so I add 48 with my original byte.

It's not always that this new value is being sent but around 1/10 to 1/100 times that the new value is sent.

Could it be that this function activates some sort of new thread wich operates next to mine???

Here's some of my code:

Eth_TapTeller_Frame = (ETH_TAPTELLER_FRAME *) tcp_get_buf(sizeof(ETH_TAPTELLER_FRAME));
                                Eth_TapTeller_Frame->Header.Versie = 1;
   ...
tcp_send (tcp_soc, (U8 *)Eth_TapTeller_Frame, 19);

P_Tekst = (U8 *)Eth_TapTeller_Frame;
for (y=0;y<19;y++){
   *(U8*)P_Tekst++ +=48;
}
*P_Tekst=0;             //end of string toevoegen
LCD_gotoxy(1,4);
LCD_puts((U8 *)Eth_TapTeller_Frame);

Anyone got an idea???

Parents
  • But my function returns __TRUE when sending was succesfull. So this would mean that the function operates immediatly, or will not return untill it is succesfull??

    So if it isn't succesfull it will not send anything in the function... So how could it then send when it has returned from the function. Then their return value isn't placed on the right spot, i think?

Reply
  • But my function returns __TRUE when sending was succesfull. So this would mean that the function operates immediatly, or will not return untill it is succesfull??

    So if it isn't succesfull it will not send anything in the function... So how could it then send when it has returned from the function. Then their return value isn't placed on the right spot, i think?

Children
  • Send operations normally only report that the TCP stack has accepted data for transmission, and that the connection is still believed to work. It isn't until you close the connection - or sometimes later on future send() commands that you get any feedback about errors.

    Networks are slow. If TCP/IP was implemented so that the sender gets a full-transfer result for every send, then applications would in some situations manage less than one send()/s.