... or maybe it should be optimized a bit for speed performance
--8<------------
#if MEM_ALIGNMENT >= 2
if( (int)dataptr & 1 ) { /* odd address */
for(acc = 0; len > 1; len -= 2) {
/* acc = acc + *((u16_t *)dataptr)++;*/
acc += htons( ((u16_t)(((u8_t *)dataptr)[0])<<8) | ((u8_t *)dataptr)[1] );
dataptr += 2;
}
} else
#endif
for(acc = 0; len > 1; len -= 2) {
/* acc = acc + *((u16_t *)dataptr)++;*/
acc += *(u16_t *)dataptr;
dataptr = (void *)((u16_t *)dataptr + 1);
}
--8<------------
On 6/8/05, Peter Jolasson <address@hidden> wrote:
Hi,
My problem was the lwip_standard_chksum() routine in the inet.c module.
I wasn't aware that it might need to be rewritten/ported. (I don't
remember seeing it in any documentation.)
I just included a compile directive when MEM_ALIGNMENT >= 2.
Maybe this could/should be put into the code repository?
//Peter
static u16_t
lwip_standard_chksum(void *dataptr, int len)
{
u32_t acc;
LWIP_DEBUGF(INET_DEBUG, ("lwip_chksum(%p, %d)\n", (void *)dataptr, len));
for(acc = 0; len > 1; len -= 2) {
/* acc = acc + *((u16_t *)dataptr)++;*/
#if MEM_ALIGNMENT >= 2
acc += htons( ((u16_t)(((u8_t *)dataptr)[0])<<8) | ((u8_t *)dataptr)[1] );
dataptr += 2;
#else
acc += *(u16_t *)dataptr;
dataptr = (void *)((u16_t *)dataptr + 1);
#endif
}
/* add up any odd byte */
if (len == 1) {
acc += htons((u16_t)((*(u8_t *)dataptr) & 0xff) << 8);
LWIP_DEBUGF(INET_DEBUG, ("inet: chksum: odd byte %d\n", (unsigned
int)(*(u8_t *)dataptr)));
} else {
LWIP_DEBUGF(INET_DEBUG, ("inet: chksum: no odd byte\n"));
}
acc = (acc >> 16) + (acc & 0xffffUL);
if ((acc & 0xffff0000) != 0) {
acc = (acc >> 16) + (acc & 0xffffUL);
}
return (u16_t)acc;
}
On 6/8/05, Bill Knight <address@hidden> wrote:
This is possibly a problem with the ip checksum routine running
on a 16 or 32 bit cpu.
Regards
-Bill Knight
R O SOftWare &
http://www.theARMPatch.com
On Wed, 8 Jun 2005 10:46:29 +0200, Peter Jolasson wrote:
Hi again,
To correct myself.
It's not when there is an odd number of bytes to transfer that it fails.
It fails when the data is located at an odd address.
But as said before my workaround is to set "copy" to 1 and then it works OK.
My target cpu is ARM and I've set MEM_ALIGNMENT to 4.
//Peter
On 6/8/05, Peter Jolasson <address@hidden> wrote:
Hi,
I dont have a solution to your problem but I can describe a 'funny' behavior
that I've noticed with tcp_write().
When I send an even number of bytes I can set "copy" to 0.
But when sending an odd number of bytes I must set "copy" to 1 otherwise
it will fail.
I'm using lwIP 1.1.0
//Peter
On 6/7/05, Sathya Thammanur <address@hidden> wrote:
Hi all,
I have a client program that connects to a server on PC. The client is
a simple program that sends data to PC. What I notice is that when I
call tcp_write() with "copy" argument 1, then my program works
without any issues. However, if I change "copy" to 0 then I notice
that the TCP connection is not established completely. The following
happens :
Client Server
SYN ---------->
<--------- SYN, ACK
Junk packet sent from client. The Server resends the SYN, ACK and then
closes the connection. TCP client sends a lost ACK with incorrect
sequence number after couple of junk packets.
I do notice that my application call back that is registered with
tcp_connected() is called. Here is where I start to send data. I am
using lwip version 0.7.2. Am I using the tcp_write() in the right way
as intended ? Any correct usage of this function will be very useful.
Any help would be greatly appreciated.
Thanks,
Sathya
_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users